mirror of
https://github.com/plexguide/Huntarr.git
synced 2026-02-05 01:58:47 -06:00
Remove GitHub Pages workflows and docs directory
This commit is contained in:
Admin9705
50
.github/workflows/deploy-docs.yml
vendored
50
.github/workflows/deploy-docs.yml
vendored
@@ -1,50 +0,0 @@
|
||||
name: Deploy Docs
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
concurrency:
|
||||
group: "pages"
|
||||
cancel-in-progress: false
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Pages
|
||||
uses: actions/configure-pages@v4
|
||||
|
||||
- name: Build docs
|
||||
run: |
|
||||
# Create .nojekyll file
|
||||
touch docs/.nojekyll
|
||||
|
||||
# Force using upload-artifact@v4 for all artifact operations
|
||||
- name: Setup Dependencies
|
||||
run: |
|
||||
echo "Using upload-artifact@v4 explicitly"
|
||||
echo "ACTIONS_RUNTIME_URL=https://pipelines.actions.githubusercontent.com/${{ github.run_id}}" >> $GITHUB_ENV
|
||||
|
||||
- name: Upload artifact
|
||||
uses: actions/upload-pages-artifact@v2
|
||||
with:
|
||||
path: ./docs
|
||||
# Make sure we use v4 internally
|
||||
artifact_name: github-pages
|
||||
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deployment
|
||||
uses: actions/deploy-pages@v2
|
||||
58
.github/workflows/pages.yml
vendored
58
.github/workflows/pages.yml
vendored
@@ -1,58 +0,0 @@
|
||||
name: Deploy GitHub Pages
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
workflow_dispatch:
|
||||
|
||||
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
|
||||
permissions:
|
||||
contents: read
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
concurrency:
|
||||
group: "pages"
|
||||
cancel-in-progress: false
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Pages
|
||||
uses: actions/configure-pages@v4
|
||||
|
||||
- name: Build docs
|
||||
run: |
|
||||
# Create .nojekyll file to disable Jekyll
|
||||
touch docs/.nojekyll
|
||||
|
||||
# Use upload-artifact@v4 explicitly
|
||||
- name: Create artifact
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: github-pages
|
||||
path: docs
|
||||
retention-days: 1
|
||||
|
||||
# Download the same artifact for deployment
|
||||
- name: Download artifact
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: github-pages
|
||||
path: _site
|
||||
|
||||
- name: Upload Pages artifact
|
||||
uses: actions/upload-pages-artifact@v2
|
||||
with:
|
||||
path: _site
|
||||
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deployment
|
||||
uses: actions/deploy-pages@v2
|
||||
@@ -1 +0,0 @@
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
# Huntarr Documentation
|
||||
|
||||
> The Intelligent Media Hunter for your *arr Stack
|
||||
|
||||
|
||||
|
||||
|
||||
## What is Huntarr?
|
||||
|
||||
Huntarr is an intelligent media hunting tool designed to work with your existing *arr stack (Sonarr, Radarr, Lidarr, Readarr, and Whisparr). It automatically searches for missing and upgradable media in your libraries, substantially improving your media collection without manual intervention.
|
||||
|
||||
<div class="app-icon-grid">
|
||||
<div class="app-icon-card">
|
||||
<img src="assets/img/sonarr.png" alt="Sonarr">
|
||||
<h4>Sonarr</h4>
|
||||
<p>TV Series</p>
|
||||
</div>
|
||||
<div class="app-icon-card">
|
||||
<img src="assets/img/radarr.png" alt="Radarr">
|
||||
<h4>Radarr</h4>
|
||||
<p>Movies</p>
|
||||
</div>
|
||||
<div class="app-icon-card">
|
||||
<img src="assets/img/lidarr.png" alt="Lidarr">
|
||||
<h4>Lidarr</h4>
|
||||
<p>Music</p>
|
||||
</div>
|
||||
<div class="app-icon-card">
|
||||
<img src="assets/img/readarr.png" alt="Readarr">
|
||||
<h4>Readarr</h4>
|
||||
<p>Books</p>
|
||||
</div>
|
||||
<div class="app-icon-card">
|
||||
<img src="assets/img/whisparr.png" alt="Whisparr">
|
||||
<h4>Whisparr</h4>
|
||||
<p>Adult Content</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Key Features
|
||||
|
||||
<ul class="feature-list">
|
||||
<li>Automated hunting for missing media items</li>
|
||||
<li>Quality upgrades for existing content</li>
|
||||
<li>Multi-instance support for each app</li>
|
||||
<li>Advanced scheduling with calendar view</li>
|
||||
<li>Intelligent API rate limiting to prevent bans</li>
|
||||
<li>Stateful management to track processed media</li>
|
||||
<li>Easy to use web interface</li>
|
||||
<li>Docker and native installation support</li>
|
||||
<li>Detailed logging and media tracking</li>
|
||||
</ul>
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
# Pull the Docker image
|
||||
docker pull plexguide/huntarr:latest
|
||||
|
||||
# Create and run container
|
||||
docker run -d \
|
||||
--name=huntarr \
|
||||
-p 8123:8123 \
|
||||
-v /path/to/config:/config \
|
||||
--restart unless-stopped \
|
||||
plexguide/huntarr:latest
|
||||
```
|
||||
|
||||
After installation, access the web interface at `http://your-ip:8123` and follow the setup wizard to connect your media applications.
|
||||
|
||||
## Why Huntarr?
|
||||
|
||||
Traditional *arr applications rely on RSS feeds and manual searches. Huntarr changes the game by:
|
||||
|
||||
- Automatically identifying and filling gaps in your media library
|
||||
- Proactively searching for quality upgrades based on your profile settings
|
||||
- Intelligently managing API requests to avoid rate limits
|
||||
- Providing a unified interface to manage all your *arr apps
|
||||
|
||||
Whether you're a casual media collector or a serious data hoarder, Huntarr makes maintaining a complete, high-quality media library effortless.
|
||||
|
||||
<div class="card">
|
||||
<h3>💡 Pro Tips</h3>
|
||||
<ul>
|
||||
<li>Set up higher API rate limits for your local *arr instances than external ones</li>
|
||||
<li>Use the scheduling feature to run intensive tasks during off-hours</li>
|
||||
<li>Configure monitored-only option to focus on content you care about</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
Ready to elevate your media management? Check out the [Installation](installation.md) guide to get started.
|
||||
@@ -1,14 +0,0 @@
|
||||
* [Home](README.md)
|
||||
* [Installation](installation.md)
|
||||
* [Configuration](configuration.md)
|
||||
* [Usage](usage.md)
|
||||
* [FAQ](faq.md)
|
||||
* **Guides**
|
||||
* [Multi-Instance Setup](guides/multi-instance.md)
|
||||
* [Scheduling](guides/scheduling.md)
|
||||
* [API Rate Limiting](guides/api-rate-limiting.md)
|
||||
* [Swaparr Integration](guides/swaparr.md)
|
||||
* **Advanced Topics**
|
||||
* [Stateful Management](advanced/stateful-management.md)
|
||||
* [Performance Tuning](advanced/performance-tuning.md)
|
||||
* [Changelog](changelog.md)
|
||||
@@ -1,258 +0,0 @@
|
||||
# Performance Tuning
|
||||
|
||||
> Optimize Huntarr for your specific environment and usage patterns
|
||||
|
||||
## Understanding Performance Factors
|
||||
|
||||
Huntarr's performance is influenced by several key factors:
|
||||
|
||||
1. **System Resources**: CPU, memory, and disk I/O available to Huntarr
|
||||
2. **Network Conditions**: Latency and bandwidth to your *arr applications
|
||||
3. ***Arr Application Performance**: How quickly your *arr applications respond to API requests
|
||||
4. **Library Size**: Total number of media items being managed
|
||||
5. **Concurrent Operations**: Number of simultaneous searches and connections
|
||||
|
||||
This guide will help you optimize these factors for your specific environment.
|
||||
|
||||
## Resource Optimization
|
||||
|
||||
### System Requirements
|
||||
|
||||
Huntarr's requirements vary based on your library size and activity level:
|
||||
|
||||
| Library Size | Recommended CPU | Recommended RAM | Storage |
|
||||
|--------------|----------------|-----------------|---------|
|
||||
| Small (<1000 items) | 1 CPU core | 512MB | 1GB |
|
||||
| Medium (1000-5000 items) | 2 CPU cores | 1GB | 2GB |
|
||||
| Large (5000+ items) | 4 CPU cores | 2GB+ | 5GB+ |
|
||||
|
||||
### Docker Resource Allocation
|
||||
|
||||
If running in Docker, consider setting explicit resource limits:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
services:
|
||||
huntarr:
|
||||
# ... other configuration ...
|
||||
deploy:
|
||||
resources:
|
||||
limits:
|
||||
cpus: '2'
|
||||
memory: 1G
|
||||
reservations:
|
||||
cpus: '0.5'
|
||||
memory: 512M
|
||||
```
|
||||
|
||||
This ensures Huntarr has enough resources while preventing it from consuming everything.
|
||||
|
||||
## Search Configuration Optimization
|
||||
|
||||
### Search Volume Settings
|
||||
|
||||
Adjust the number of items searched per cycle based on your system capabilities:
|
||||
|
||||
| System Capability | Missing Items | Upgrade Items | Sleep Duration |
|
||||
|-------------------|---------------|---------------|----------------|
|
||||
| Low-end (e.g., Raspberry Pi) | 1-2 | 0-1 | 15-30 minutes |
|
||||
| Mid-range (e.g., NAS) | 3-5 | 1-3 | 10-15 minutes |
|
||||
| High-end (e.g., Server) | 5-10 | 3-5 | 5-10 minutes |
|
||||
|
||||
### Processing Order
|
||||
|
||||
Prioritize your most important applications:
|
||||
|
||||
1. Set higher search counts for important apps
|
||||
2. Set lower search counts for less critical apps
|
||||
3. Consider using scheduling to allocate dedicated time slots
|
||||
|
||||
## API Rate Limiting
|
||||
|
||||
### Optimal API Cap Settings
|
||||
|
||||
Balance between performance and rate-limiting risks:
|
||||
|
||||
| Scenario | Recommended API Cap |
|
||||
|----------|---------------------|
|
||||
| Self-hosted *arr applications | 30-60 per hour |
|
||||
| Remote/shared *arr instances | 15-30 per hour |
|
||||
| Public/restricted instances | 5-15 per hour |
|
||||
|
||||
### Connection Timeouts
|
||||
|
||||
Adjust timeout settings based on network conditions:
|
||||
|
||||
- **Fast local network**: 30-60 seconds
|
||||
- **Average internet connection**: 90-120 seconds
|
||||
- **Slow/unreliable connection**: 180+ seconds
|
||||
|
||||
## Database and State Optimization
|
||||
|
||||
### Stateful Management Tuning
|
||||
|
||||
Optimize how Huntarr tracks processed media:
|
||||
|
||||
- **High performance systems**: 3-5 days reset interval
|
||||
- **Balanced systems**: 7 days reset interval
|
||||
- **Resource-constrained systems**: 10-14 days reset interval
|
||||
|
||||
### Database Maintenance
|
||||
|
||||
For long-term performance:
|
||||
|
||||
1. Periodically restart Huntarr to clear cached data
|
||||
2. Consider regular database vacuum operations
|
||||
3. Monitor disk space for log growth
|
||||
|
||||
## Scheduling Strategies
|
||||
|
||||
### Time-Based Resource Allocation
|
||||
|
||||
Create schedules that optimize resource usage:
|
||||
|
||||
| Time Period | Suggested Activity |
|
||||
|-------------|-------------------|
|
||||
| Off-peak hours (night) | Heavy searching (missing + upgrades) |
|
||||
| Medium usage hours | Moderate searching (missing only) |
|
||||
| Peak usage hours | Minimal activity or paused |
|
||||
|
||||
### Device-Specific Scheduling
|
||||
|
||||
Adapt scheduling to your device type:
|
||||
|
||||
- **Always-on servers**: Distribute load throughout the day
|
||||
- **NAS devices**: Run intensive tasks during low-usage hours
|
||||
- **Desktop/part-time systems**: Concentrate activity during powered-on hours
|
||||
|
||||
## Network Optimization
|
||||
|
||||
### Reducing Network Overhead
|
||||
|
||||
Minimize network impact:
|
||||
|
||||
1. Run Huntarr on the same network as your *arr applications
|
||||
2. Consider running everything on the same machine when possible
|
||||
3. Adjust sleep durations based on network latency
|
||||
|
||||
### SSL Considerations
|
||||
|
||||
Balance security with performance:
|
||||
|
||||
- Enable SSL verification for internet-exposed services
|
||||
- Consider disabling SSL verification for local network services if using self-signed certificates
|
||||
- Implement proper certificates rather than disabling verification when possible
|
||||
|
||||
## Advanced Techniques
|
||||
|
||||
### Docker Compose Network Optimization
|
||||
|
||||
For Docker setups, use internal networks:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
services:
|
||||
huntarr:
|
||||
# ... other configuration ...
|
||||
networks:
|
||||
- arr_network
|
||||
|
||||
# Define the other services in the same docker-compose
|
||||
sonarr:
|
||||
# ... sonarr configuration ...
|
||||
networks:
|
||||
- arr_network
|
||||
|
||||
networks:
|
||||
arr_network:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
This keeps traffic between containers on an internal network for better performance.
|
||||
|
||||
### Multi-Threading Configuration
|
||||
|
||||
For systems with many CPU cores:
|
||||
|
||||
- Increase the number of items processed per cycle
|
||||
- Reduce sleep durations
|
||||
- Consider running multiple cycles in parallel (advanced users only)
|
||||
|
||||
## Monitoring Performance
|
||||
|
||||
### Key Metrics to Watch
|
||||
|
||||
Track these indicators to assess performance:
|
||||
|
||||
1. **CPU and Memory Usage**: Should remain stable
|
||||
2. **API Usage**: Monitor the API counters in the dashboard
|
||||
3. **Successful Searches**: Track "Searches Triggered" vs error rates
|
||||
4. **Processing Time**: Check logs for search duration patterns
|
||||
|
||||
### Log Level Adjustment
|
||||
|
||||
Optimize logging for your needs:
|
||||
|
||||
- **Debug Mode OFF**: Better performance, less detail
|
||||
- **Debug Mode ON**: More detailed logging, slightly higher resource usage
|
||||
|
||||
## Troubleshooting Performance Issues
|
||||
|
||||
### High CPU Usage
|
||||
|
||||
If CPU usage is excessive:
|
||||
|
||||
1. Reduce items searched per cycle
|
||||
2. Increase sleep duration
|
||||
3. Check for network issues causing retries
|
||||
|
||||
### Memory Leaks
|
||||
|
||||
If memory usage grows continuously:
|
||||
|
||||
1. Restart Huntarr regularly
|
||||
2. Update to the latest version
|
||||
3. Consider running in a container with memory limits
|
||||
|
||||
## Real-World Configurations
|
||||
|
||||
### Raspberry Pi Setup
|
||||
|
||||
```yaml
|
||||
# Config for resource-limited devices
|
||||
sonarr:
|
||||
hunt_missing_items: 1
|
||||
hunt_upgrade_items: 0
|
||||
sleep_duration: 1800 # 30 minutes
|
||||
hourly_cap: 15
|
||||
```
|
||||
|
||||
### NAS Configuration
|
||||
|
||||
```yaml
|
||||
# Balanced config for NAS devices
|
||||
radarr:
|
||||
hunt_missing_movies: 3
|
||||
hunt_upgrade_movies: 1
|
||||
sleep_duration: 900 # 15 minutes
|
||||
hourly_cap: 30
|
||||
```
|
||||
|
||||
### High-Performance Server
|
||||
|
||||
```yaml
|
||||
# Performance config for dedicated servers
|
||||
sonarr:
|
||||
hunt_missing_items: 10
|
||||
hunt_upgrade_items: 5
|
||||
sleep_duration: 300 # 5 minutes
|
||||
hourly_cap: 60
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
After optimizing performance, consider exploring:
|
||||
|
||||
- [Scheduling](../guides/scheduling.md) for more advanced time management
|
||||
- [Multi-Instance Setup](../guides/multi-instance.md) for specialized configurations
|
||||
- [Swaparr Integration](../guides/swaparr.md) for managing stalled downloads
|
||||
@@ -1,140 +0,0 @@
|
||||
# Stateful Management
|
||||
|
||||
> Understanding how Huntarr tracks processed media to optimize performance and prevent redundant searches
|
||||
|
||||
## What is Stateful Management?
|
||||
|
||||
Stateful management is a core feature of Huntarr that tracks which media items have already been processed during search operations. It maintains a persistent record of:
|
||||
|
||||
- Media items that have been searched for missing content
|
||||
- Media items that have been checked for quality upgrades
|
||||
- The timestamp when each item was last processed
|
||||
|
||||
This tracking system prevents Huntarr from repeatedly searching for the same items, which helps:
|
||||
|
||||
- Reduce unnecessary API requests to your *arr applications
|
||||
- Prevent potential API rate limiting
|
||||
- Improve overall system performance
|
||||
- Ensure all media gets fair attention over time
|
||||
|
||||
## How Stateful Management Works
|
||||
|
||||
### State Creation and Storage
|
||||
|
||||
When Huntarr processes media items, it creates and maintains several important states:
|
||||
|
||||
1. **Initial State Creation**: The first time Huntarr runs, it creates a new state file
|
||||
2. **State Persistence**: This information is stored in the Huntarr database
|
||||
3. **Automatic Resets**: States are automatically cleared after the configured reset interval
|
||||
|
||||
### Item Tracking Workflow
|
||||
|
||||
The typical workflow for state tracking is:
|
||||
|
||||
1. Before processing an item, Huntarr checks if it's in the state database
|
||||
2. If found and the processing time is within the reset interval, the item is skipped
|
||||
3. If not found or the reset interval has passed, the item is processed
|
||||
4. After processing, the item is added or updated in the state database with the current timestamp
|
||||
|
||||
## Configuring Stateful Management
|
||||
|
||||
### State Reset Interval
|
||||
|
||||
The most important setting for stateful management is the **State Reset Interval**:
|
||||
|
||||
- Found under **Settings > General > Stateful Management**
|
||||
- Measured in hours (default: 168 hours / 7 days)
|
||||
- Determines how long Huntarr remembers processed items
|
||||
|
||||
Setting this value involves balancing thoroughness with efficiency:
|
||||
|
||||
- **Shorter intervals** (24-72 hours): More frequent rescanning, useful for active libraries
|
||||
- **Medium intervals** (3-7 days): Good balance for most users
|
||||
- **Longer intervals** (7+ days): Less frequent rescanning, useful for stable libraries
|
||||
|
||||
### Manual State Reset
|
||||
|
||||
For certain situations, you might want to perform a manual reset:
|
||||
|
||||
1. Go to **Settings > General > Stateful Management**
|
||||
2. Click the **Emergency Reset** button
|
||||
3. Confirm the action when prompted
|
||||
|
||||
Common reasons for manual resets include:
|
||||
|
||||
- After significant changes to your media library
|
||||
- When troubleshooting search issues
|
||||
- When you want to force a complete reprocessing of all media
|
||||
- After upgrading to a new version of Huntarr
|
||||
|
||||
## Monitoring Stateful Data
|
||||
|
||||
Huntarr provides visibility into its stateful management system:
|
||||
|
||||
- **Initial State Created**: When the state tracking first began
|
||||
- **State Reset Date**: When the next automatic reset will occur
|
||||
|
||||
These are shown in the **Settings > General > Stateful Management** section.
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Optimal State Reset Intervals
|
||||
|
||||
Choose your reset interval based on your media management style:
|
||||
|
||||
| Usage Pattern | Recommended Interval | Rationale |
|
||||
|---------------|----------------------|-----------|
|
||||
| Active Hunter | 24-72 hours | Frequent checking for new content and upgrades |
|
||||
| Balanced | 3-7 days | Good compromise between thoroughness and efficiency |
|
||||
| Stable Library | 7-14 days | Less frequent checks for established libraries |
|
||||
|
||||
### When to Manually Reset
|
||||
|
||||
Consider manually resetting the state when:
|
||||
|
||||
- Adding a large batch of new content to your *arr applications
|
||||
- Making significant changes to quality profiles
|
||||
- After fixing connectivity issues with your applications
|
||||
- When you suspect searches aren't being performed as expected
|
||||
|
||||
### Resource Considerations
|
||||
|
||||
Stateful management directly impacts resource usage:
|
||||
|
||||
- Shorter reset intervals increase CPU, memory, and network usage
|
||||
- Longer intervals reduce resource consumption but might miss some upgrades
|
||||
- For resource-constrained systems, consider longer intervals (7+ days)
|
||||
|
||||
## Advanced Topics
|
||||
|
||||
### State File Location
|
||||
|
||||
The stateful management data is stored in:
|
||||
|
||||
- Docker installations: `/config/db/stateful.db`
|
||||
- Native installations: In the Huntarr application data directory
|
||||
|
||||
### Troubleshooting State Issues
|
||||
|
||||
If you experience problems with stateful management:
|
||||
|
||||
1. Check the logs for any errors related to state tracking
|
||||
2. Verify that the database is not corrupted
|
||||
3. Perform a manual reset as a troubleshooting step
|
||||
4. If problems persist, consider rebuilding the state database
|
||||
|
||||
### Custom Stateful Management
|
||||
|
||||
For advanced users, Huntarr supports individualized state tracking for different applications:
|
||||
|
||||
- Each *arr application maintains its own state records
|
||||
- Reset intervals affect all applications equally
|
||||
- Manual resets clear state for all applications
|
||||
|
||||
## Next Steps
|
||||
|
||||
With a good understanding of stateful management, you may want to explore:
|
||||
|
||||
- [Performance Tuning](performance-tuning.md) for optimizing Huntarr
|
||||
- [API Rate Limiting](../guides/api-rate-limiting.md) to avoid throttling
|
||||
- [Scheduling](../guides/scheduling.md) to control when Huntarr runs
|
||||
@@ -1,295 +0,0 @@
|
||||
:root {
|
||||
--background-color: #181c25;
|
||||
--text-color: #e0e6ed;
|
||||
--accent-color: #3498db;
|
||||
--accent-hover: #2980b9;
|
||||
--secondary-color: #2c3e50;
|
||||
--border-color: rgba(90, 109, 137, 0.2);
|
||||
--sidebar-background: #10151f;
|
||||
--search-background: #263244;
|
||||
--code-background: #0f1620;
|
||||
--blockquote-border: #3498db;
|
||||
--section-border: rgba(79, 93, 115, 0.2);
|
||||
--section-background: rgba(15, 20, 30, 0.5);
|
||||
--link-color: #5acdff;
|
||||
--link-hover-color: #00aef0;
|
||||
}
|
||||
|
||||
/* Base styles */
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
|
||||
color: var(--text-color);
|
||||
background-color: var(--background-color);
|
||||
}
|
||||
|
||||
/* Sidebar */
|
||||
.sidebar {
|
||||
background-color: var(--sidebar-background);
|
||||
border-right: 1px solid var(--border-color);
|
||||
color: var(--text-color);
|
||||
}
|
||||
|
||||
.sidebar-toggle {
|
||||
background-color: var(--sidebar-background);
|
||||
}
|
||||
|
||||
.sidebar ul li a {
|
||||
color: var(--text-color);
|
||||
}
|
||||
|
||||
.sidebar ul li.active > a {
|
||||
color: var(--accent-color);
|
||||
border-right: 2px solid var(--accent-color);
|
||||
}
|
||||
|
||||
.sidebar ul li a:hover {
|
||||
text-decoration: none;
|
||||
color: var(--accent-hover);
|
||||
}
|
||||
|
||||
/* Content area */
|
||||
.content {
|
||||
padding-top: 40px;
|
||||
}
|
||||
|
||||
/* Links */
|
||||
a {
|
||||
color: var(--link-color);
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
color: var(--link-hover-color);
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
/* Headings */
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
color: var(--text-color);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2.2rem;
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 1.8rem;
|
||||
padding-bottom: 0.3rem;
|
||||
border-bottom: 1px solid var(--border-color);
|
||||
margin-top: 2rem;
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.5rem;
|
||||
margin-top: 1.5rem;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
/* Code blocks */
|
||||
pre {
|
||||
background-color: var(--code-background);
|
||||
border-radius: 5px;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
code {
|
||||
background-color: var(--code-background);
|
||||
border-radius: 3px;
|
||||
font-family: source-code-pro, Menlo, Monaco, Consolas, Courier New, monospace;
|
||||
padding: 0.2rem 0.4rem;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
|
||||
/* Blockquotes */
|
||||
blockquote {
|
||||
border-left: 4px solid var(--blockquote-border);
|
||||
padding-left: 20px;
|
||||
margin-left: 0;
|
||||
background-color: rgba(52, 152, 219, 0.1);
|
||||
border-radius: 0 4px 4px 0;
|
||||
padding: 1rem 1rem 1rem 20px;
|
||||
}
|
||||
|
||||
blockquote p {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
/* Tables */
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
width: 100%;
|
||||
margin: 1rem 0;
|
||||
display: table;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
table thead {
|
||||
background-color: var(--secondary-color);
|
||||
}
|
||||
|
||||
table th, table td {
|
||||
border: 1px solid var(--border-color);
|
||||
padding: 0.6rem;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
table tr:nth-child(even) {
|
||||
background-color: rgba(255, 255, 255, 0.05);
|
||||
}
|
||||
|
||||
/* Search box */
|
||||
.search {
|
||||
margin-bottom: 20px;
|
||||
padding: 6px;
|
||||
border-bottom: 1px solid var(--border-color);
|
||||
}
|
||||
|
||||
.search input {
|
||||
background-color: var(--search-background);
|
||||
color: var(--text-color);
|
||||
border: 1px solid var(--border-color);
|
||||
border-radius: 4px;
|
||||
padding: 0.5rem;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.search input:focus {
|
||||
outline: none;
|
||||
border-color: var(--accent-color);
|
||||
}
|
||||
|
||||
/* Cards for special sections */
|
||||
.card {
|
||||
background-color: var(--section-background);
|
||||
border: 1px solid var(--section-border);
|
||||
border-radius: 10px;
|
||||
padding: 20px;
|
||||
margin: 20px 0;
|
||||
box-shadow: 0 10px 30px rgba(0, 0, 0, 0.2);
|
||||
}
|
||||
|
||||
.card h3 {
|
||||
margin-top: 0;
|
||||
border-bottom: 1px solid var(--border-color);
|
||||
padding-bottom: 10px;
|
||||
}
|
||||
|
||||
/* Buttons */
|
||||
.btn {
|
||||
display: inline-block;
|
||||
padding: 8px 16px;
|
||||
border-radius: 4px;
|
||||
background-color: var(--accent-color);
|
||||
color: white;
|
||||
text-decoration: none;
|
||||
transition: background-color 0.3s;
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.btn:hover {
|
||||
background-color: var(--accent-hover);
|
||||
text-decoration: none;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Docsify overrides */
|
||||
.app-name-link img {
|
||||
max-width: 150px;
|
||||
}
|
||||
|
||||
.markdown-section {
|
||||
max-width: 900px;
|
||||
padding: 30px 15px 40px;
|
||||
}
|
||||
|
||||
.markdown-section code {
|
||||
color: #e06c75;
|
||||
}
|
||||
|
||||
.markdown-section pre>code {
|
||||
color: var(--text-color);
|
||||
}
|
||||
|
||||
/* Custom Huntarr styles */
|
||||
.app-icon-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
|
||||
gap: 20px;
|
||||
margin: 30px 0;
|
||||
}
|
||||
|
||||
.app-icon-card {
|
||||
background: rgba(24, 28, 37, 0.8);
|
||||
border-radius: 12px;
|
||||
padding: 20px;
|
||||
text-align: center;
|
||||
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
|
||||
transition: all 0.3s ease;
|
||||
border: 1px solid rgba(120, 140, 180, 0.15);
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.app-icon-card img {
|
||||
width: 60px;
|
||||
height: 60px;
|
||||
border-radius: 10px;
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
|
||||
.app-icon-card h4 {
|
||||
margin: 0 0 10px 0;
|
||||
font-size: 18px;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.app-icon-card p {
|
||||
margin: 0;
|
||||
color: rgba(224, 230, 237, 0.7);
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
/* Feature list */
|
||||
.feature-list {
|
||||
list-style-type: none;
|
||||
padding: 0;
|
||||
margin: 20px 0;
|
||||
}
|
||||
|
||||
.feature-list li {
|
||||
padding: 10px 0 10px 30px;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.feature-list li:before {
|
||||
content: "✓";
|
||||
position: absolute;
|
||||
left: 0;
|
||||
color: var(--accent-color);
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
/* Responsive adjustments */
|
||||
@media screen and (max-width: 768px) {
|
||||
.markdown-section {
|
||||
padding: 20px 15px;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 1.8rem;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.3rem;
|
||||
}
|
||||
}
|
||||
@@ -1 +0,0 @@
|
||||
placeholder
|
||||
@@ -1,5 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
|
||||
<circle cx="50" cy="50" r="45" fill="#1a2233" />
|
||||
<text x="50" y="60" font-family="Arial" font-size="40" font-weight="bold" fill="#3d80e4" text-anchor="middle">H</text>
|
||||
<path d="M80 50 A 30 30 0 1 0 20 50" stroke="#3d80e4" stroke-width="5" fill="none" />
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 355 B |
@@ -1,5 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
|
||||
<circle cx="50" cy="50" r="45" fill="#1a2233" />
|
||||
<text x="50" y="60" font-family="Arial" font-size="40" font-weight="bold" fill="#3d80e4" text-anchor="middle">H</text>
|
||||
<path d="M80 50 A 30 30 0 1 0 20 50" stroke="#3d80e4" stroke-width="5" fill="none" />
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 355 B |
@@ -1,174 +0,0 @@
|
||||
# Configuration Guide
|
||||
|
||||
This guide will help you configure Huntarr to work with your media applications and set up optimal media hunting parameters.
|
||||
|
||||
## Initial Setup
|
||||
|
||||
After installation, access the Huntarr web interface at `http://your-ip:8123` and follow these steps:
|
||||
|
||||
1. **Create an admin account** on the first launch
|
||||
2. **Log in** to access the dashboard
|
||||
3. **Configure your *arr applications** in the Settings section
|
||||
|
||||
## Connecting Media Applications
|
||||
|
||||
Huntarr works with the following media applications:
|
||||
|
||||
- Sonarr (TV shows)
|
||||
- Radarr (Movies)
|
||||
- Lidarr (Music)
|
||||
- Readarr (Books)
|
||||
- Whisparr (Adult content)
|
||||
|
||||
### Adding an Application Instance
|
||||
|
||||
1. Go to **Settings** and select the appropriate tab (Sonarr, Radarr, etc.)
|
||||
2. Fill in the following details:
|
||||
- **Name**: A friendly name for this instance
|
||||
- **URL**: The full URL to your instance (e.g., `http://192.168.1.100:8989`)
|
||||
- **API Key**: Your instance's API key (found in Settings > General in your *arr application)
|
||||
- **Enabled**: Toggle to enable/disable this instance
|
||||
|
||||
|
||||
|
||||
### Multi-Instance Support
|
||||
|
||||
Huntarr supports multiple instances of each application. For example, you can have:
|
||||
|
||||
- Sonarr for TV shows and another for anime
|
||||
- Radarr for movies and another for documentaries
|
||||
|
||||
To add additional instances, click the **Add Instance** button in the respective application's settings tab.
|
||||
|
||||
## Hunting Configuration
|
||||
|
||||
### Global Hunting Options {#global-hunting-options}
|
||||
|
||||
Under the **General** tab in Settings, you can configure:
|
||||
|
||||
- **Debug Mode** {#debug-mode}: Enable for verbose logging
|
||||
- **Display Resources**: Show/hide the Resources section on the home page
|
||||
- **API Timeout**: Timeout for API requests in seconds
|
||||
- **Maximum Download Queue Size**: Limit downloads to prevent overwhelming your system
|
||||
|
||||
### Application-Specific Options
|
||||
|
||||
Each media app has its own configuration options:
|
||||
|
||||
#### Sonarr Options
|
||||
|
||||
- **Missing Search Mode**:
|
||||
- Episodes: Search for individual episodes
|
||||
- Seasons/Packs: Search for entire seasons at once
|
||||
- Shows: Search for entire shows
|
||||
- **Upgrade Mode**: Set how upgrades are searched
|
||||
- **Missing Items to Search**: Number of missing items to search per cycle
|
||||
- **Upgrade Items to Search**: Number of upgrades to search per cycle
|
||||
- **Sleep Duration**: Time between processing cycles
|
||||
- **API Cap - Hourly**: Maximum API requests per hour
|
||||
- **Monitored Only**: Only search for monitored items
|
||||
- **Skip Future Episodes**: Skip searching for episodes with future air dates
|
||||
|
||||
#### Radarr Options
|
||||
|
||||
- **Missing Movies to Search**: Number of missing movies to search per cycle
|
||||
- **Movies to Upgrade**: Number of movies to upgrade per cycle
|
||||
- **API Cap - Hourly**: Maximum API requests per hour
|
||||
- **Skip Future Releases**: Skip searching for movies not yet released
|
||||
- **Release Type for Future Status**: Which release type to use for determining if a movie is released
|
||||
|
||||
Similar options are available for Lidarr, Readarr, and Whisparr, tailored to the specific media types.
|
||||
|
||||
## Stateful Management {#stateful-management}
|
||||
|
||||
Huntarr maintains a record of processed media to avoid re-searching for the same items repeatedly.
|
||||
|
||||
- **State Reset Interval**: Controls how long Huntarr remembers processed media
|
||||
- **Emergency Reset**: Button to clear all processed items if you want to start fresh
|
||||
|
||||
To customize this:
|
||||
|
||||
1. Go to **Settings > General > Stateful Management**
|
||||
2. Adjust the **State Reset Interval** (in hours)
|
||||
3. Monitor the **State Reset Date** to know when your state will be cleared
|
||||
|
||||
## Scheduling
|
||||
|
||||
Huntarr includes a scheduling feature that lets you control when media hunting occurs.
|
||||
|
||||
1. Navigate to the **Scheduling** section
|
||||
2. Use the calendar interface to set active and inactive periods
|
||||
3. Create rules for specific days or time ranges
|
||||
|
||||
Example schedules:
|
||||
|
||||
- Run only during overnight hours (1 AM - 6 AM)
|
||||
- Disable on weekends
|
||||
- Run at reduced capacity during peak Internet usage times
|
||||
|
||||
## Advanced Features {#advanced-features}
|
||||
|
||||
### Swaparr Integration
|
||||
|
||||
Huntarr includes Swaparr integration to manage stalled downloads:
|
||||
|
||||
1. Go to **Settings > Swaparr**
|
||||
2. Enable Swaparr and configure:
|
||||
- **Maximum Strikes**: Number of strikes before removing a stalled download
|
||||
- **Max Download Time**: How long a download can stall before getting a strike
|
||||
- **Ignore Above Size**: Skip large files that might take longer to download
|
||||
- **Dry Run Mode**: Test without actually removing downloads
|
||||
|
||||
### Security Settings {#security-settings}
|
||||
|
||||
To secure your Huntarr instance:
|
||||
|
||||
1. Go to **Settings > General > Security**
|
||||
2. Configure **Local Network Auth Bypass** to allow access without login when connecting from local IPs
|
||||
3. Toggle **SSL Verification** for your API connections
|
||||
|
||||
## Saving Your Configuration
|
||||
|
||||
After making changes to any settings page, be sure to:
|
||||
|
||||
1. Click the **Save** button at the bottom of the page
|
||||
2. Wait for the "Settings saved successfully" confirmation message
|
||||
|
||||
## Testing Your Configuration
|
||||
|
||||
After configuring each application:
|
||||
|
||||
1. Click the **Test Connection** button next to each instance
|
||||
2. Verify that the status shows "Connected"
|
||||
3. Check your home page to see all connected instances
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Connection Issues
|
||||
|
||||
If you see "Not Connected" status:
|
||||
|
||||
- Verify the URL is correct and includes http:// or https://
|
||||
- Ensure the API key is correct
|
||||
- Check that the application is running and accessible from Huntarr
|
||||
- Verify any firewall settings that might block connections
|
||||
|
||||
### API Rate Limiting
|
||||
|
||||
If you notice API rate limit warnings:
|
||||
|
||||
- Reduce the hourly cap for affected applications
|
||||
- Increase the sleep duration between cycles
|
||||
- Prioritize applications based on importance
|
||||
|
||||
### Performance Tuning
|
||||
|
||||
For optimal performance:
|
||||
|
||||
- Adjust the number of items to search based on your system capabilities
|
||||
- Use longer sleep durations for less critical media types
|
||||
- Consider running Huntarr on the same machine as your *arr applications to reduce network latency
|
||||
|
||||
## Next Steps
|
||||
|
||||
Once you've configured your applications, check out the [Usage Guide](usage.md) to learn how to monitor Huntarr's progress and interpret its logs.
|
||||
173
docs/faq.md
173
docs/faq.md
@@ -1,173 +0,0 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
## General Questions
|
||||
|
||||
### What is Huntarr?
|
||||
|
||||
Huntarr is an intelligent media hunting tool that works with your existing *arr applications (Sonarr, Radarr, Lidarr, Readarr, and Whisparr) to automatically search for missing and upgradable media in your libraries.
|
||||
|
||||
### How is Huntarr different from my existing *arr applications?
|
||||
|
||||
While the *arr applications monitor RSS feeds for new releases, they don't actively search for missing or upgradable content without manual intervention. Huntarr fills this gap by automating the search process, ensuring your library stays complete and high-quality.
|
||||
|
||||
### Does Huntarr download content directly?
|
||||
|
||||
No, Huntarr works as a coordinator that initiates searches in your existing *arr applications. The actual downloading is still handled by your *arr apps through their configured download clients (torrent clients or usenet downloaders).
|
||||
|
||||
### Which media applications are supported?
|
||||
|
||||
Huntarr currently supports:
|
||||
|
||||
- Sonarr (TV shows)
|
||||
- Radarr (Movies)
|
||||
- Lidarr (Music)
|
||||
- Readarr (Books)
|
||||
- Whisparr (Adult content)
|
||||
|
||||
### Does Huntarr support multiple instances of each application?
|
||||
|
||||
Yes, Huntarr supports up to 9 instances of each application type. This allows for specialized setups like separate Radarr instances for movies and documentaries, or different Sonarr instances for TV shows and anime.
|
||||
|
||||
## Configuration
|
||||
|
||||
### What are the recommended settings for a new user?
|
||||
|
||||
For new users, we recommend starting with conservative settings:
|
||||
|
||||
- **Missing Items to Search**: 1
|
||||
- **Upgrade Items to Search**: 0 (until all missing content is found)
|
||||
- **Sleep Duration**: 900 seconds (15 minutes)
|
||||
- **API Cap - Hourly**: 20
|
||||
|
||||
After monitoring system performance and API usage, you can gradually adjust these settings.
|
||||
|
||||
### How do I determine the right API rate limits?
|
||||
|
||||
Most *arr applications don't have clearly documented API limits. As a general guideline:
|
||||
|
||||
- Start with 20 requests per hour
|
||||
- Monitor for any rate-limiting errors in the logs
|
||||
- Gradually increase if no issues occur
|
||||
|
||||
Self-hosted instances can typically handle higher limits than remotely hosted ones.
|
||||
|
||||
### What is stateful management and why is it important?
|
||||
|
||||
Stateful management tracks which media items Huntarr has already processed. This prevents the system from repeatedly searching for the same items, which would waste resources and potentially trigger API rate limits.
|
||||
|
||||
### Should I enable "Skip Future Releases"?
|
||||
|
||||
Yes, enabling "Skip Future Releases" is recommended for most users. This prevents Huntarr from searching for media that isn't available yet, such as movies still in theaters or TV episodes that haven't aired.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Why am I seeing "API connection error" messages?
|
||||
|
||||
API connection errors typically occur when:
|
||||
- The URL is incorrect or inaccessible
|
||||
- The API key is invalid
|
||||
- The *arr application is not running
|
||||
- There are network connectivity issues between Huntarr and the *arr application
|
||||
|
||||
Verify your connection settings and ensure the *arr application is accessible from the Huntarr container/system.
|
||||
|
||||
### How can I reduce API usage?
|
||||
|
||||
To reduce API usage:
|
||||
- Increase the **Sleep Duration** between cycles
|
||||
- Decrease the number of **Missing/Upgrade Items to Search**
|
||||
- Use the scheduling feature to run searches during limited time periods
|
||||
- Enable **Monitored Only** to focus only on content you care about
|
||||
|
||||
### Why are my statistics not updating?
|
||||
|
||||
If your statistics aren't updating, check:
|
||||
- If the application is properly connected (status shows "Connected")
|
||||
- If there are any error messages in the logs
|
||||
- If the application has any missing content to process
|
||||
- If your API limits have been reached
|
||||
|
||||
### What should I do if Huntarr is consuming too many resources?
|
||||
|
||||
If Huntarr is using excessive system resources:
|
||||
- Increase the **Sleep Duration** between cycles
|
||||
- Decrease the number of items searched per cycle
|
||||
- Use scheduling to limit active hours
|
||||
- Make sure only one instance of Huntarr is running
|
||||
|
||||
### How do I completely reset Huntarr?
|
||||
|
||||
To completely reset Huntarr:
|
||||
1. Go to **Settings > General > Stateful Management**
|
||||
2. Use the **Emergency Reset** button to clear processed items
|
||||
3. Restart the Huntarr container or service
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Can I prioritize certain applications over others?
|
||||
|
||||
Yes, you can prioritize by:
|
||||
- Setting different **Missing Items to Search** values for each app
|
||||
- Configuring different **Sleep Duration** periods
|
||||
- Using the scheduling feature to allocate specific time slots to different apps
|
||||
|
||||
### How can I optimize Huntarr for a large media library?
|
||||
|
||||
For large libraries:
|
||||
1. Start with the most important app and get it caught up first
|
||||
2. Use higher search values initially to clear backlogs
|
||||
3. Once caught up, reduce to maintenance levels
|
||||
4. Consider running Huntarr on more powerful hardware
|
||||
|
||||
### Can Huntarr run in a low-resource environment?
|
||||
|
||||
Yes, Huntarr can run on systems with limited resources by:
|
||||
- Setting longer sleep durations
|
||||
- Searching fewer items per cycle
|
||||
- Using scheduling to limit active hours
|
||||
- Disabling apps you don't need to prioritize
|
||||
|
||||
### How do download limits work?
|
||||
|
||||
The **Maximum Download Queue Size** setting prevents Huntarr from initiating new downloads when your download client queue is full. Set this to a value that your system can comfortably handle to prevent overwhelming your download client.
|
||||
|
||||
### What is Swaparr and how does it integrate with Huntarr?
|
||||
|
||||
Swaparr is a companion tool that monitors and manages stalled downloads. It's integrated into Huntarr to help clean up stuck downloads by:
|
||||
1. Monitoring downloads for stalled progress
|
||||
2. Assigning "strikes" to downloads that remain stalled
|
||||
3. Removing downloads that reach the maximum strike count
|
||||
|
||||
This helps maintain a healthy download queue without manual intervention.
|
||||
|
||||
## Misc Questions
|
||||
|
||||
### Is there a mobile app for Huntarr?
|
||||
|
||||
Currently, there is no dedicated mobile app for Huntarr. However, the web interface is mobile-responsive and works well on smartphone browsers.
|
||||
|
||||
### How often is Huntarr updated?
|
||||
|
||||
Huntarr follows a regular update schedule with:
|
||||
- Bug fixes as needed
|
||||
- Minor feature updates approximately monthly
|
||||
- Major version updates several times a year
|
||||
|
||||
### How can I contribute to Huntarr?
|
||||
|
||||
You can contribute to the project by:
|
||||
- Reporting bugs on the [GitHub issues page](https://github.com/plexguide/Huntarr.io/issues)
|
||||
- Submitting feature requests
|
||||
- Contributing code via pull requests
|
||||
- Helping other users in the community forums
|
||||
|
||||
### Where can I get more help?
|
||||
|
||||
If you need additional assistance:
|
||||
- Check the [GitHub discussions](https://github.com/plexguide/Huntarr.io/discussions)
|
||||
- Join the [Discord server](https://discord.com/invite/PGJJjR5Cww)
|
||||
- Post on the [Reddit community](https://www.reddit.com/r/huntarr/)
|
||||
|
||||
### Is Huntarr open source?
|
||||
|
||||
Yes, Huntarr is open source software released under the MIT License. You can view and contribute to the code on [GitHub](https://github.com/plexguide/Huntarr.io).
|
||||
@@ -1,204 +0,0 @@
|
||||
# API Rate Limiting Guide
|
||||
|
||||
> Understand and configure API rate limiting to protect your *arr applications while maximizing Huntarr's effectiveness
|
||||
|
||||
## Understanding API Rate Limiting
|
||||
|
||||
API rate limiting is a critical feature in Huntarr that controls how frequently Huntarr can make requests to your *arr applications. This feature:
|
||||
|
||||
- Prevents overwhelming your *arr applications with too many requests
|
||||
- Helps avoid being rate-limited or blocked by external services
|
||||
- Ensures sustainable, long-term operation of your media automation stack
|
||||
- Balances performance with system stability
|
||||
|
||||
## How API Rate Limiting Works in Huntarr
|
||||
|
||||
Huntarr implements a "rolling window" approach to rate limiting:
|
||||
|
||||
1. **Hourly Caps**: Each *arr application has a configurable maximum number of API requests per hour
|
||||
2. **Rolling Window**: Limits are calculated based on the last 60 minutes, not fixed clock hours
|
||||
3. **Real-time Monitoring**: Current API usage is displayed on the dashboard
|
||||
4. **Adaptive Behavior**: Huntarr automatically pauses when approaching limits
|
||||
|
||||
### Visual Indicators
|
||||
|
||||
On the Huntarr dashboard, each application displays its current API usage status:
|
||||
|
||||
- **Green**: API usage is within safe limits (< 70% of cap)
|
||||
- **Yellow**: API usage is approaching limits (70-90% of cap)
|
||||
- **Red**: API usage is at or near limits (> 90% of cap)
|
||||
|
||||
## Configuring API Rate Limits
|
||||
|
||||
### Accessing API Rate Limit Settings
|
||||
|
||||
For each application:
|
||||
|
||||
1. Go to **Settings**
|
||||
2. Select the appropriate tab (Sonarr, Radarr, etc.)
|
||||
3. Find the **API Cap - Hourly** setting
|
||||
4. Adjust the value based on your needs
|
||||
|
||||
### Recommended Starting Values
|
||||
|
||||
| Application Type | Self-Hosted | Shared/Remote | Critical/Public |
|
||||
|------------------|-------------|--------------|-----------------|
|
||||
| Sonarr | 30-60 | 15-30 | 5-15 |
|
||||
| Radarr | 30-60 | 15-30 | 5-15 |
|
||||
| Lidarr | 20-40 | 10-20 | 5-10 |
|
||||
| Readarr | 20-40 | 10-20 | 5-10 |
|
||||
| Whisparr | 15-30 | 8-15 | 3-8 |
|
||||
|
||||
### Understanding API Request Types
|
||||
|
||||
Not all operations consume the same number of API requests:
|
||||
|
||||
| Operation Type | Typical API Requests |
|
||||
|-------------------------|----------------------|
|
||||
| Checking missing status | 1-2 per item |
|
||||
| Searching for upgrades | 2-3 per item |
|
||||
| Triggering a search | 1 per search |
|
||||
| Monitoring search | 1-5 per search |
|
||||
|
||||
This means a single "Missing Items to Search" setting of 10 might result in 30-40 API requests during one cycle.
|
||||
|
||||
## Advanced API Management
|
||||
|
||||
### Multi-Instance Rate Management
|
||||
|
||||
When using multiple instances of the same application (e.g., several Radarr instances):
|
||||
|
||||
1. Each instance gets its own API cap
|
||||
2. Consider setting different caps based on priority
|
||||
3. Use scheduling to distribute API usage across time
|
||||
|
||||
### Dynamic Rate Limiting
|
||||
|
||||
Huntarr supports dynamic or "adaptive" rate limiting:
|
||||
|
||||
- API usage is spread over time to avoid bursts
|
||||
- If approaching the limit, Huntarr slows down request frequency
|
||||
- When limits are reached, requests are deferred to the next cycle
|
||||
|
||||
### API Efficiency Strategies
|
||||
|
||||
To maximize efficiency with limited API requests:
|
||||
|
||||
1. **Prioritization**: Focus on missing content before upgrades
|
||||
2. **Batching**: Process multiple items during lower-activity periods
|
||||
3. **Strategic Scheduling**: Align with your *arr applications' own scheduled tasks
|
||||
4. **Progressive Caps**: Start with conservative limits and increase gradually
|
||||
|
||||
## Preventing Rate Limit Issues
|
||||
|
||||
### Warning Signs of API Overuse
|
||||
|
||||
Watch for these indicators that your API limits may be too high:
|
||||
|
||||
- Error messages in logs about rate limiting
|
||||
- Inconsistent/slow responses from your *arr applications
|
||||
- Increased CPU/memory usage in your *arr applications
|
||||
- Applications becoming unresponsive to manual actions
|
||||
|
||||
### Remedial Actions
|
||||
|
||||
If you encounter rate limiting issues:
|
||||
|
||||
1. **Immediate Action**: Temporarily pause Huntarr
|
||||
2. **Short-term Fix**: Reduce API caps by 50%
|
||||
3. **Medium-term Solution**: Implement more strategic scheduling
|
||||
4. **Long-term Strategy**: Balance Huntarr settings with your hardware capabilities
|
||||
|
||||
## Real-World Rate Limiting Scenarios
|
||||
|
||||
### Small Home Server
|
||||
|
||||
For a Raspberry Pi or low-power NAS:
|
||||
|
||||
```yaml
|
||||
# Conservative settings for low-power devices
|
||||
sonarr:
|
||||
hourly_cap: 15
|
||||
sleep_duration: 1800 # 30 minutes
|
||||
hunt_missing_items: 1
|
||||
hunt_upgrade_items: 0
|
||||
```
|
||||
|
||||
### Shared Seedbox
|
||||
|
||||
For shared hosting environments:
|
||||
|
||||
```yaml
|
||||
# Respectful settings for shared environments
|
||||
radarr:
|
||||
hourly_cap: 20
|
||||
sleep_duration: 1200 # 20 minutes
|
||||
hunt_missing_movies: 2
|
||||
hunt_upgrade_movies: 1
|
||||
```
|
||||
|
||||
### High-Performance Dedicated Server
|
||||
|
||||
For powerful home servers or dedicated machines:
|
||||
|
||||
```yaml
|
||||
# Higher performance settings for dedicated hardware
|
||||
sonarr:
|
||||
hourly_cap: 60
|
||||
sleep_duration: 600 # 10 minutes
|
||||
hunt_missing_items: 5
|
||||
hunt_upgrade_items: 3
|
||||
```
|
||||
|
||||
## API Usage Monitoring
|
||||
|
||||
### Reading API Usage Stats
|
||||
|
||||
The dashboard provides real-time API statistics:
|
||||
|
||||
- **Current Usage**: How many requests have been made in the past hour
|
||||
- **API Limit**: Your configured maximum
|
||||
- **Usage Ratio**: Current usage as a percentage of your limit
|
||||
|
||||
### Log Monitoring
|
||||
|
||||
Check logs for API-related entries:
|
||||
|
||||
- **INFO**: Normal API operations
|
||||
- **WARNING**: Approaching rate limits
|
||||
- **ERROR**: Rate limit reached or API errors
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common API Issues
|
||||
|
||||
| Issue | Possible Causes | Solutions |
|
||||
|-------|----------------|-----------|
|
||||
| Rate limit errors | API cap too low for activity level | Increase cap or reduce activity |
|
||||
| Connection timeouts | Network issues or *arr app overload | Extend timeout settings, reduce API load |
|
||||
| Inconsistent behavior | Competing processes using the API | Coordinate schedules with other tools |
|
||||
| API authentication errors | Incorrect API key or URL | Verify credentials and test connection |
|
||||
|
||||
### How to Reset API Counters
|
||||
|
||||
If you need to reset the API counters:
|
||||
|
||||
1. Restart the Huntarr service
|
||||
2. This will clear the current rolling window counters
|
||||
3. Note that this should only be done if absolutely necessary
|
||||
|
||||
## Best Practices Summary
|
||||
|
||||
1. **Start Conservative**: Begin with lower limits and increase gradually
|
||||
2. **Monitor Regularly**: Check API usage patterns over several days
|
||||
3. **Adjust Strategically**: Make small, incremental changes
|
||||
4. **Balance Settings**: Coordinate API caps with processing amounts and sleep durations
|
||||
5. **Respect Shared Resources**: Use lower caps when on shared hosting or seedboxes
|
||||
|
||||
## Next Steps
|
||||
|
||||
With a good understanding of API rate limiting, consider exploring:
|
||||
|
||||
- [Scheduling](scheduling.md) to distribute API usage strategically
|
||||
- [Performance Tuning](../advanced/performance-tuning.md) for overall optimization
|
||||
- [Stateful Management](../advanced/stateful-management.md) to reduce unnecessary API calls
|
||||
@@ -1,83 +0,0 @@
|
||||
# Multi-Instance Setup Guide
|
||||
|
||||
> This guide covers how to effectively configure and manage multiple instances of the same *arr application in Huntarr.
|
||||
|
||||
## Why Use Multiple Instances?
|
||||
|
||||
There are several reasons you might want to set up multiple instances of the same application:
|
||||
|
||||
- **Specialized Content**: Separate TV shows from anime, movies from documentaries
|
||||
- **Different Quality Profiles**: One instance for 4K content, another for 1080p
|
||||
- **Testing vs. Production**: Test new settings on one instance before applying to your main instance
|
||||
- **Different Media Libraries**: Manage content for different users or locations
|
||||
|
||||
## Adding Multiple Instances
|
||||
|
||||
Huntarr supports up to 9 instances of each application type. Here's how to set them up:
|
||||
|
||||
1. Go to **Settings** and select the appropriate tab (Sonarr, Radarr, etc.)
|
||||
2. Configure your first instance with all required details
|
||||
3. Click the **Add Instance** button at the bottom of the form
|
||||
4. Fill in the details for the new instance:
|
||||
- Give it a descriptive name that clearly identifies its purpose
|
||||
- Enter the URL and API key
|
||||
- Enable it if you want it to start processing immediately
|
||||
|
||||
|
||||
|
||||
## Configuration Strategies
|
||||
|
||||
### Scenario: TV Shows and Anime
|
||||
|
||||
For Sonarr, you might set up:
|
||||
|
||||
- **Instance 1: TV Shows**
|
||||
- Name: "Sonarr - TV Shows"
|
||||
- Standard TV show quality profiles
|
||||
- Higher search priority for current shows
|
||||
|
||||
- **Instance 2: Anime**
|
||||
- Name: "Sonarr - Anime"
|
||||
- Anime-specific quality profiles
|
||||
- Different search parameters for anime content
|
||||
|
||||
### Scenario: Movie Categories
|
||||
|
||||
For Radarr, consider:
|
||||
|
||||
- **Instance 1: General Movies**
|
||||
- Name: "Radarr - Movies"
|
||||
- Standard movie quality profiles
|
||||
|
||||
- **Instance 2: 4K Movies**
|
||||
- Name: "Radarr - 4K"
|
||||
- 4K-specific quality profiles
|
||||
- Higher resource allocation
|
||||
|
||||
## Balancing Resources
|
||||
|
||||
When running multiple instances, consider these tips for optimal performance:
|
||||
|
||||
- **Stagger Processing**: Set different sleep durations to avoid simultaneous searches
|
||||
- **API Caps**: Distribute API caps based on priority and importance
|
||||
- **Schedule Strategically**: Use scheduling to run less critical instances during off-hours
|
||||
|
||||
## Monitoring Multiple Instances
|
||||
|
||||
The Huntarr dashboard displays all configured instances, allowing you to:
|
||||
|
||||
- View connection status for each instance
|
||||
- Monitor API usage per instance
|
||||
- Track search and upgrade statistics independently
|
||||
|
||||
## Advanced Multi-Instance Setup
|
||||
|
||||
For more advanced setups, consider using:
|
||||
|
||||
- **Scheduling**: Different schedules for different instances
|
||||
- **Stateful Management**: Shared tracking to prevent redundant searches
|
||||
- **Specialized Settings**: Tailored settings for each instance's specific needs
|
||||
|
||||
## Next Steps
|
||||
|
||||
After setting up multiple instances, check out the [Scheduling Guide](scheduling.md) to learn how to optimize when each instance runs.
|
||||
@@ -1,195 +0,0 @@
|
||||
# Scheduling Guide
|
||||
|
||||
> Control when Huntarr runs searches to optimize resource usage and media hunting efficiency
|
||||
|
||||
## Understanding Huntarr Scheduling
|
||||
|
||||
The scheduling system in Huntarr gives you precise control over when media searches and upgrades happen. This capability allows you to:
|
||||
|
||||
- Run intensive operations during off-peak hours
|
||||
- Reduce system resource contention
|
||||
- Avoid network congestion
|
||||
- Align media hunting with when new content is typically released
|
||||
- Divide workloads across different time periods
|
||||
|
||||
## The Scheduling Interface
|
||||
|
||||
Huntarr's scheduling interface provides a visual calendar where you can:
|
||||
|
||||
- Set active/inactive periods by clicking time slots
|
||||
- Create rules for different days of the week
|
||||
- Apply global or app-specific schedules
|
||||
- See scheduling conflicts and overlaps
|
||||
|
||||
### Accessing Scheduling
|
||||
|
||||
To access the scheduling interface:
|
||||
|
||||
1. Navigate to the main menu
|
||||
2. Select **Scheduling**
|
||||
3. The default view shows the weekly schedule grid
|
||||
|
||||
### Understanding the Schedule Grid
|
||||
|
||||
The schedule grid displays:
|
||||
|
||||
- Rows for each day of the week
|
||||
- Columns for each hour of the day
|
||||
- Colored blocks indicating active periods
|
||||
- White/empty blocks indicating inactive periods
|
||||
|
||||
## Creating and Managing Schedules
|
||||
|
||||
### Basic Scheduling
|
||||
|
||||
To set up a basic schedule:
|
||||
|
||||
1. Click on any time slot in the grid to toggle it active/inactive
|
||||
2. Active slots will be colored, indicating Huntarr will run during these times
|
||||
3. Click and drag to select multiple time slots at once
|
||||
|
||||
### Creating Schedule Rules
|
||||
|
||||
For more advanced control:
|
||||
|
||||
1. Click the **Add Rule** button
|
||||
2. Configure the rule options:
|
||||
- **Days**: Select which days this rule applies to
|
||||
- **Start Time**: When the activity period begins
|
||||
- **End Time**: When the activity period ends
|
||||
- **Active**: Whether Huntarr should be active or inactive during this period
|
||||
- **Applications**: Which apps this rule applies to (All or specific apps)
|
||||
3. Click **Save** to apply the rule
|
||||
|
||||
### Schedule Rule Examples
|
||||
|
||||
**Example 1: Overnight Processing**
|
||||
- Days: All
|
||||
- Time: 1:00 AM - 6:00 AM
|
||||
- Active: Yes
|
||||
- Applications: All
|
||||
|
||||
**Example 2: Weekend-Only Upgrades**
|
||||
- Days: Saturday, Sunday
|
||||
- Time: 9:00 AM - 5:00 PM
|
||||
- Active: Yes
|
||||
- Applications: All
|
||||
- Mode: Upgrades Only
|
||||
|
||||
**Example 3: Disable During Peak Hours**
|
||||
- Days: Monday-Friday
|
||||
- Time: 6:00 PM - 10:00 PM
|
||||
- Active: No
|
||||
- Applications: All
|
||||
|
||||
### Editing and Removing Rules
|
||||
|
||||
To manage existing rules:
|
||||
|
||||
1. Find the rule in the **Active Rules** section
|
||||
2. Click the **Edit** (pencil) icon to modify the rule
|
||||
3. Click the **Delete** (trash) icon to remove the rule
|
||||
4. Confirm any deletion when prompted
|
||||
|
||||
## Advanced Scheduling Strategies
|
||||
|
||||
### Time-Based Activity Types
|
||||
|
||||
Optimize different types of activities at different times:
|
||||
|
||||
1. **Missing Content Focus**: Schedule specific periods just for finding missing content
|
||||
2. **Upgrade Focus**: Schedule specific periods focused on quality upgrades
|
||||
3. **Mixed Operations**: Allow both operations during less restricted time periods
|
||||
|
||||
### App-Specific Scheduling
|
||||
|
||||
Create dedicated schedules for each application:
|
||||
|
||||
1. Navigate to the **App-Specific Rules** tab
|
||||
2. Select the application you want to schedule
|
||||
3. Create rules that apply only to that application
|
||||
4. This allows prioritizing more important apps during prime time
|
||||
|
||||
### Importing and Exporting Schedules
|
||||
|
||||
Share or backup your schedules:
|
||||
|
||||
1. Click the **Export** button to download your current schedule configuration
|
||||
2. Use **Import** to load a previously exported schedule
|
||||
3. This is useful when setting up multiple instances of Huntarr
|
||||
|
||||
## Real-World Scheduling Scenarios
|
||||
|
||||
### Work/Home Schedule
|
||||
|
||||
For a home server used during evenings and weekends:
|
||||
|
||||
- **Weekday Days (7:00 AM - 5:00 PM)**: Full activity (while you're at work)
|
||||
- **Weekday Evenings (5:00 PM - 11:00 PM)**: Limited activity (using minimal resources)
|
||||
- **Weekday Nights (11:00 PM - 7:00 AM)**: Full activity
|
||||
- **Weekends**: Reduced activity during daytime, full activity overnight
|
||||
|
||||
### Download Speed Management
|
||||
|
||||
For users with bandwidth caps or slower connections:
|
||||
|
||||
- **Peak Hours (6:00 PM - 12:00 AM)**: Minimal or no activity
|
||||
- **Off-Peak Hours (12:00 AM - 6:00 AM)**: Full activity
|
||||
- **Daytime Hours (6:00 AM - 6:00 PM)**: Moderate activity
|
||||
|
||||
### Media Release Alignment
|
||||
|
||||
Align with typical media release schedules:
|
||||
|
||||
- **TV Show Night (Sundays, 8:00 PM - 12:00 AM)**: Increased Sonarr activity
|
||||
- **Movie Release Days (Tuesdays)**: Increased Radarr activity
|
||||
- **Music Release Day (Fridays)**: Increased Lidarr activity
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Scheduling for Efficiency
|
||||
|
||||
- **Stagger App Activity**: Avoid running all apps simultaneously
|
||||
- **Align with Media Releases**: Schedule Sonarr activity to run shortly after popular show air times
|
||||
- **Respect Sleep/Wake**: For devices that sleep, ensure schedules align with awake periods
|
||||
|
||||
### Common Scheduling Mistakes to Avoid
|
||||
|
||||
- **Over-scheduling**: Creating too many short active periods creates inefficient search patterns
|
||||
- **No Down-time**: Always allow some inactive periods to reduce system and network load
|
||||
- **Too Restrictive**: Schedules that are too limited may miss important content
|
||||
|
||||
### Monitoring Schedule Effectiveness
|
||||
|
||||
After setting up a schedule:
|
||||
|
||||
1. Monitor Huntarr's statistics to verify it's running during expected periods
|
||||
2. Check logs for any timing issues or missed opportunities
|
||||
3. Adjust schedules based on observed performance
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Schedule Not Being Applied
|
||||
|
||||
If your schedule doesn't seem to be working:
|
||||
|
||||
1. Verify the schedule has been saved correctly
|
||||
2. Check that Huntarr's system time is correct
|
||||
3. Look for conflicting rules that might be overriding each other
|
||||
4. Restart Huntarr to ensure the schedule is loaded properly
|
||||
|
||||
### Conflicting Rules
|
||||
|
||||
When rules conflict:
|
||||
|
||||
1. More specific rules generally take precedence over general ones
|
||||
2. App-specific rules override global rules
|
||||
3. The most recently created rule wins in case of identical conflicts
|
||||
|
||||
## Next Steps
|
||||
|
||||
With a solid understanding of scheduling, consider exploring:
|
||||
|
||||
- [API Rate Limiting](api-rate-limiting.md) to prevent overloading your *arr applications
|
||||
- [Performance Tuning](../advanced/performance-tuning.md) to optimize Huntarr further
|
||||
- [Multi-Instance Setup](multi-instance.md) for complex media library management
|
||||
@@ -1,241 +0,0 @@
|
||||
# Swaparr Integration Guide
|
||||
|
||||
> Manage stalled and stuck downloads automatically using Huntarr's integration with Swaparr
|
||||
|
||||
## What is Swaparr?
|
||||
|
||||
Swaparr is a complementary tool integrated into Huntarr that addresses a common issue in media automation: stalled downloads. Specifically designed for torrent users, Swaparr:
|
||||
|
||||
- Identifies downloads that have stopped progressing
|
||||
- Applies a "strikes" system to monitor problematic downloads
|
||||
- Automatically removes stalled downloads after defined thresholds
|
||||
- Helps maintain a clean, efficient download queue
|
||||
|
||||
Originally a standalone project, Swaparr has been fully integrated into Huntarr to provide a seamless experience for managing problematic downloads.
|
||||
|
||||
## Why Swaparr is Valuable
|
||||
|
||||
Without Swaparr, stalled downloads can:
|
||||
|
||||
- Consume slots in your download client
|
||||
- Prevent new downloads from starting
|
||||
- Require manual intervention to clear
|
||||
- Lead to media items remaining in a perpetual "searching" state
|
||||
|
||||
Swaparr solves these problems by automatically monitoring and managing these problematic downloads, ensuring your download queue remains healthy and active.
|
||||
|
||||
## How Swaparr Works
|
||||
|
||||
Swaparr follows a systematic approach to managing stalled downloads:
|
||||
|
||||
1. **Detection**: Identifies downloads that haven't progressed for a specified period
|
||||
2. **Strike System**: Assigns "strikes" to downloads that consistently fail to progress
|
||||
3. **Removal**: Removes downloads that reach the maximum strike count
|
||||
4. **Reporting**: Logs all actions for your review
|
||||
|
||||
### The Strike System Explained
|
||||
|
||||
The strike system works as follows:
|
||||
|
||||
1. A download is detected as stalled when it meets these criteria:
|
||||
- Has been downloading longer than the defined maximum download time
|
||||
- Has made no progress during the checking period
|
||||
- Is below the "ignore above size" threshold
|
||||
|
||||
2. When a stalled download is identified:
|
||||
- It receives a strike
|
||||
- It remains in the download queue
|
||||
- Its strike count is stored in Huntarr's database
|
||||
|
||||
3. During subsequent checks:
|
||||
- If the download has resumed progress, strikes are maintained (not increased)
|
||||
- If the download remains stalled, it receives another strike
|
||||
- If strikes reach the maximum limit, the download is removed
|
||||
|
||||
## Configuring Swaparr in Huntarr
|
||||
|
||||
### Accessing Swaparr Settings
|
||||
|
||||
1. Go to **Settings**
|
||||
2. Select the **Swaparr** tab
|
||||
3. Enable or disable the Swaparr integration using the toggle
|
||||
|
||||
### Available Settings
|
||||
|
||||
| Setting | Description | Recommended Value |
|
||||
|---------|-------------|-------------------|
|
||||
| **Enable Swaparr** | Turn Swaparr functionality on/off | Enabled |
|
||||
| **Maximum Strikes** | Number of strikes before removing a download | 3-5 |
|
||||
| **Max Download Time** | How long a download can be active before being eligible for strikes | 2h-12h |
|
||||
| **Ignore Above Size** | Skip large files that might legitimately take longer | 25GB |
|
||||
| **Remove From Client** | Whether to remove the download from the torrent/usenet client | Enabled |
|
||||
| **Dry Run Mode** | Log actions but don't actually remove downloads | Enable initially |
|
||||
|
||||
### Setting Up For the First Time
|
||||
|
||||
When setting up Swaparr for the first time, we recommend:
|
||||
|
||||
1. Enable **Dry Run Mode** initially
|
||||
2. Set **Maximum Strikes** to 3
|
||||
3. Set **Max Download Time** to a reasonable value based on your connection (e.g., 2h)
|
||||
4. Monitor the logs for a few days to see what would be removed
|
||||
5. Once comfortable with the identified stalled downloads, disable Dry Run Mode
|
||||
|
||||
## Advanced Swaparr Configuration
|
||||
|
||||
### Download Client Considerations
|
||||
|
||||
Swaparr works with various download clients through your *arr applications:
|
||||
|
||||
- **qBittorrent**: Fully compatible
|
||||
- **Transmission**: Fully compatible
|
||||
- **Deluge**: Fully compatible
|
||||
- **rTorrent**: Fully compatible
|
||||
- **SABnzbd**: Compatible for usenet downloads
|
||||
- **NZBGet**: Compatible for usenet downloads
|
||||
|
||||
### Size Thresholds
|
||||
|
||||
The **Ignore Above Size** setting is particularly important:
|
||||
|
||||
- **Smaller value** (e.g., 5GB): More aggressive management, might remove large legitimate downloads
|
||||
- **Medium value** (e.g., 25GB): Good balance for most users
|
||||
- **Larger value** (e.g., 100GB): Only the largest downloads will be ignored
|
||||
- **Extreme value** (e.g., 1TB): Effectively disables the size filter
|
||||
|
||||
### Client-Specific Recommendations
|
||||
|
||||
Depending on your download client, consider these adjustments:
|
||||
|
||||
**qBittorrent**:
|
||||
```yaml
|
||||
swaparr:
|
||||
max_strikes: 3
|
||||
max_download_time: 2h
|
||||
ignore_above_size: 25GB
|
||||
```
|
||||
|
||||
**Transmission** (tends to handle stalled torrents differently):
|
||||
```yaml
|
||||
swaparr:
|
||||
max_strikes: 4
|
||||
max_download_time: 3h
|
||||
ignore_above_size: 30GB
|
||||
```
|
||||
|
||||
## Monitoring and Maintenance
|
||||
|
||||
### Viewing Swaparr Status
|
||||
|
||||
To monitor Swaparr's activity:
|
||||
|
||||
1. Go to **Settings > Swaparr**
|
||||
2. The status display shows:
|
||||
- Currently striked downloads per application
|
||||
- Total downloads removed
|
||||
- Total downloads being tracked
|
||||
|
||||
### Resetting Strikes
|
||||
|
||||
If you need to reset the strike system:
|
||||
|
||||
1. Go to **Settings > Swaparr**
|
||||
2. Click the **Reset** button in the status section
|
||||
3. This will clear all tracked downloads and strikes
|
||||
4. Confirm the action when prompted
|
||||
|
||||
### Understanding Logs
|
||||
|
||||
Swaparr-related log entries include:
|
||||
|
||||
- **INFO**: Normal operations like checks and strike assignments
|
||||
- **WARNING**: Approaching strike limits
|
||||
- **ACTION**: Removal of downloads that reached maximum strikes
|
||||
- **ERROR**: Issues with download client communication
|
||||
|
||||
## Common Scenarios and Solutions
|
||||
|
||||
### Scenario: Too Many Removals
|
||||
|
||||
If Swaparr is removing too many downloads:
|
||||
|
||||
1. Enable **Dry Run Mode** temporarily
|
||||
2. Increase **Maximum Strikes** (e.g., from 3 to 5)
|
||||
3. Increase **Max Download Time** (e.g., from 2h to 4h)
|
||||
4. Increase **Ignore Above Size** threshold
|
||||
|
||||
### Scenario: Not Removing Obvious Stalls
|
||||
|
||||
If Swaparr isn't removing clearly stalled downloads:
|
||||
|
||||
1. Decrease **Maximum Strikes** (e.g., from 5 to 3)
|
||||
2. Decrease **Max Download Time** (e.g., from 4h to 2h)
|
||||
3. Check logs for any errors in communication with download clients
|
||||
|
||||
### Scenario: Large Downloads Being Removed
|
||||
|
||||
If legitimate large downloads are being removed:
|
||||
|
||||
1. Significantly increase the **Ignore Above Size** setting
|
||||
2. Consider your typical download sizes when setting this threshold
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Finding the Right Balance
|
||||
|
||||
The ideal Swaparr configuration balances:
|
||||
|
||||
- Being aggressive enough to remove genuinely stuck downloads
|
||||
- Being lenient enough to not interfere with legitimate slow downloads
|
||||
- Accounting for your specific network conditions and media types
|
||||
|
||||
### Recommended for Most Users
|
||||
|
||||
For most users, these settings work well:
|
||||
|
||||
```yaml
|
||||
swaparr:
|
||||
enabled: true
|
||||
max_strikes: 3
|
||||
max_download_time: 2h
|
||||
ignore_above_size: 25GB
|
||||
remove_from_client: true
|
||||
dry_run: false # After initial testing period
|
||||
```
|
||||
|
||||
### When to Enable Dry Run Mode
|
||||
|
||||
Enable Dry Run Mode when:
|
||||
|
||||
- First setting up Swaparr
|
||||
- Making significant changes to Swaparr settings
|
||||
- Troubleshooting issues with removals
|
||||
- After changes to your download client configuration
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
| Issue | Possible Causes | Solutions |
|
||||
|-------|----------------|-----------|
|
||||
| No stalled downloads detected | Criteria too lenient | Reduce max_download_time |
|
||||
| Too many removals | Criteria too strict | Increase max_strikes or max_download_time |
|
||||
| Legitimate downloads removed | Size threshold too low | Increase ignore_above_size |
|
||||
| Not removing from client | Client communication issue | Check *arr application download settings |
|
||||
|
||||
### Fixing Client Connection Issues
|
||||
|
||||
If Swaparr isn't properly interacting with your download client:
|
||||
|
||||
1. Verify the download client settings in your *arr applications
|
||||
2. Ensure the client is accessible from Huntarr
|
||||
3. Check if the API or RPC interface of your client is enabled
|
||||
4. Look for authentication issues in the logs
|
||||
|
||||
## Next Steps
|
||||
|
||||
With a properly configured Swaparr integration, consider exploring:
|
||||
|
||||
- [Multi-Instance Setup](multi-instance.md) to manage multiple download clients
|
||||
- [Performance Tuning](../advanced/performance-tuning.md) for overall Huntarr optimization
|
||||
- [API Rate Limiting](api-rate-limiting.md) to ensure stable operation
|
||||
@@ -1,54 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>Huntarr Documentation</title>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
|
||||
<meta name="description" content="Documentation for Huntarr - The Intelligent Media Hunter">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0">
|
||||
<link rel="stylesheet" href="//cdn.jsdelivr.net/npm/docsify@4/lib/themes/dark.css">
|
||||
<link rel="stylesheet" href="assets/css/docs.css">
|
||||
<link rel="stylesheet" href="//cdn.jsdelivr.net/npm/@fortawesome/fontawesome-free@5/css/all.min.css">
|
||||
</head>
|
||||
<body>
|
||||
<div id="app"></div>
|
||||
<script>
|
||||
window.$docsify = {
|
||||
name: 'Huntarr',
|
||||
repo: 'plexguide/Huntarr.io',
|
||||
loadSidebar: true,
|
||||
subMaxLevel: 3,
|
||||
auto2top: true,
|
||||
homepage: 'README.md',
|
||||
themeColor: '#3498db',
|
||||
basePath: '/',
|
||||
search: {
|
||||
maxAge: 86400000,
|
||||
paths: 'auto',
|
||||
placeholder: 'Search documentation',
|
||||
noData: 'No results found',
|
||||
depth: 6
|
||||
},
|
||||
copyCode: {
|
||||
buttonText: 'Copy',
|
||||
errorText: 'Error',
|
||||
successText: 'Copied!'
|
||||
},
|
||||
pagination: {
|
||||
previousText: 'Previous',
|
||||
nextText: 'Next',
|
||||
crossChapter: true
|
||||
}
|
||||
}
|
||||
</script>
|
||||
<!-- Docsify v4 -->
|
||||
<script src="//cdn.jsdelivr.net/npm/docsify@4"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/docsify/lib/plugins/search.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/docsify-copy-code/dist/docsify-copy-code.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/docsify-pagination/dist/docsify-pagination.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/prismjs/components/prism-bash.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/prismjs/components/prism-python.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/prismjs/components/prism-json.min.js"></script>
|
||||
<script src="//cdn.jsdelivr.net/npm/prismjs/components/prism-yaml.min.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,176 +0,0 @@
|
||||
# Installation Guide
|
||||
|
||||
There are several ways to install Huntarr depending on your preferences and system setup.
|
||||
|
||||
## Docker Installation (Recommended)
|
||||
|
||||
Docker is the simplest way to get Huntarr up and running without worrying about dependencies.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Docker installed on your system
|
||||
- Access to Docker Hub
|
||||
|
||||
### Basic Docker Run Command
|
||||
|
||||
```bash
|
||||
docker run -d \
|
||||
--name=huntarr \
|
||||
-p 8123:8123 \
|
||||
-v /path/to/config:/config \
|
||||
--restart unless-stopped \
|
||||
plexguide/huntarr:latest
|
||||
```
|
||||
|
||||
Replace `/path/to/config` with the path where you want to store Huntarr's configuration files.
|
||||
|
||||
### Docker Compose
|
||||
|
||||
For more advanced setups, you can use Docker Compose:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
services:
|
||||
huntarr:
|
||||
container_name: huntarr
|
||||
image: plexguide/huntarr:latest
|
||||
ports:
|
||||
- 8123:8123
|
||||
volumes:
|
||||
- /path/to/config:/config
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- TZ=Your/Timezone
|
||||
```
|
||||
|
||||
Save this to a file named `docker-compose.yml` and run:
|
||||
|
||||
```bash
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## Native Installation
|
||||
|
||||
For users who prefer not to use Docker, you can install Huntarr directly on your system.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Python 3.7 or higher
|
||||
- pip (Python package manager)
|
||||
- Git (for cloning the repository)
|
||||
|
||||
### Installation Steps
|
||||
|
||||
1. Clone the repository:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/plexguide/Huntarr.io.git
|
||||
cd Huntarr.io
|
||||
```
|
||||
|
||||
2. Install the required dependencies:
|
||||
|
||||
```bash
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
3. Start Huntarr:
|
||||
|
||||
```bash
|
||||
python main.py
|
||||
```
|
||||
|
||||
By default, Huntarr will be available at `http://localhost:8123`.
|
||||
|
||||
## Unraid Installation
|
||||
|
||||
Huntarr can be easily installed on Unraid using the Community Applications plugin.
|
||||
|
||||
1. Open the Unraid web interface
|
||||
2. Navigate to the "Apps" tab
|
||||
3. Search for "Huntarr"
|
||||
4. Click "Install"
|
||||
5. Configure the container settings as needed
|
||||
6. Click "Apply"
|
||||
|
||||
## First-Time Setup
|
||||
|
||||
After installing Huntarr, you'll need to complete the initial setup:
|
||||
|
||||
1. Access the web interface at `http://your-ip:8123`
|
||||
2. Create an admin account for secure access
|
||||
3. Configure your *arr applications (Sonarr, Radarr, etc.)
|
||||
4. Set up your hunting preferences and scheduling
|
||||
|
||||
## Updating Huntarr
|
||||
|
||||
### Docker Update
|
||||
|
||||
To update the Docker container:
|
||||
|
||||
```bash
|
||||
# Pull the latest image
|
||||
docker pull plexguide/huntarr:latest
|
||||
|
||||
# Stop and remove the current container
|
||||
docker stop huntarr
|
||||
docker rm huntarr
|
||||
|
||||
# Run a new container with the updated image
|
||||
docker run -d \
|
||||
--name=huntarr \
|
||||
-p 8123:8123 \
|
||||
-v /path/to/config:/config \
|
||||
--restart unless-stopped \
|
||||
plexguide/huntarr:latest
|
||||
```
|
||||
|
||||
With Docker Compose:
|
||||
|
||||
```bash
|
||||
docker-compose pull
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
### Native Update
|
||||
|
||||
For native installations:
|
||||
|
||||
```bash
|
||||
cd Huntarr.io
|
||||
git pull
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
## System Requirements
|
||||
|
||||
- **Minimum**: 1GB RAM, 1 CPU core, 1GB disk space
|
||||
- **Recommended**: 2GB RAM, 2 CPU cores, 5GB disk space
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Container won't start
|
||||
|
||||
Check the logs:
|
||||
|
||||
```bash
|
||||
docker logs huntarr
|
||||
```
|
||||
|
||||
### Connection issues
|
||||
|
||||
- Verify the port mappings are correct
|
||||
- Check that your firewall isn't blocking the Huntarr port
|
||||
- Ensure your *arr applications are accessible from the Huntarr container
|
||||
|
||||
### Permission issues
|
||||
|
||||
If you're having permission problems with the config directory:
|
||||
|
||||
```bash
|
||||
sudo chown -R 1000:1000 /path/to/config
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
Once you have Huntarr installed, head over to the [Configuration](configuration.md) guide to learn how to set up your media hunting preferences.
|
||||
187
docs/usage.md
187
docs/usage.md
@@ -1,187 +0,0 @@
|
||||
# Usage Guide
|
||||
|
||||
This guide covers the day-to-day usage of Huntarr, including monitoring media hunting, interpreting logs, and managing your hunt cycles.
|
||||
|
||||
## Dashboard Overview
|
||||
|
||||
The Huntarr dashboard provides a quick overview of your media hunting status:
|
||||
|
||||
|
||||
|
||||
Key elements include:
|
||||
|
||||
- **Connection Status**: Shows which media applications are connected
|
||||
- **Live Hunts Executed**: Statistics on searches and upgrades triggered for each application
|
||||
- **API Usage**: Real-time monitoring of API request rates to prevent rate limiting
|
||||
|
||||
## Media Hunting Status
|
||||
|
||||
### Starting and Stopping Hunts
|
||||
|
||||
To manually control the hunting process:
|
||||
|
||||
1. From the home screen, use the control buttons in the app cards
|
||||
2. Click **Reset Cycle** to restart the hunting cycle for a specific application
|
||||
3. The hunts will automatically run based on your configured schedule
|
||||
|
||||
### Monitoring Progress
|
||||
|
||||
The statistics cards on the home page provide real-time information:
|
||||
|
||||
- **Searches Triggered**: Count of missing media searches initiated
|
||||
- **Upgrades Triggered**: Count of quality upgrade searches initiated
|
||||
|
||||
These counters reset automatically based on your stateful management settings or when you manually reset them using the **Reset** button in the Statistics card header.
|
||||
|
||||
## Logs
|
||||
|
||||
The Logs section provides detailed information about Huntarr's activities:
|
||||
|
||||
1. Navigate to the **Logs** section from the sidebar
|
||||
2. Use the dropdown to select which application's logs to view
|
||||
|
||||
### Log Filtering
|
||||
|
||||
To filter logs:
|
||||
|
||||
1. Use the search box at the top of the logs view
|
||||
2. Enter keywords to find specific events (e.g., "search", "upgrade", "error")
|
||||
3. Click **Clear** to reset the filter
|
||||
|
||||
### Log Levels
|
||||
|
||||
Logs are color-coded by severity:
|
||||
|
||||
- <span style="color:#e74c3c">**ERROR**</span>: Critical issues that need attention
|
||||
- <span style="color:#f39c12">**WARNING**</span>: Potential issues that might need attention
|
||||
- <span style="color:#3498db">**INFO**</span>: General information about normal operations
|
||||
- <span style="color:#7f8c8d">**DEBUG**</span>: Detailed information for troubleshooting (only visible with Debug Mode enabled)
|
||||
|
||||
### Common Log Messages
|
||||
|
||||
#### Normal Operation Messages
|
||||
|
||||
- `Processing missing items for [app]`: Huntarr is searching for missing media
|
||||
- `Processing upgradable items for [app]`: Huntarr is searching for quality upgrades
|
||||
- `Searching for [media item]`: A specific item is being searched
|
||||
- `Command sent to [app], waiting for completion`: A search command was initiated
|
||||
- `Search completed successfully for [media item]`: Item was successfully searched
|
||||
- `Sleep cycle started`: Huntarr is in sleep mode between processing cycles
|
||||
|
||||
#### Warning Messages
|
||||
|
||||
- `API rate limit approaching for [app]`: API requests are getting close to the configured limit
|
||||
- `Maximum download queue size reached`: Downloads are paused due to queue size limit
|
||||
- `Item is not monitored, skipping`: An item was skipped because it isn't monitored
|
||||
- `Item has future release date, skipping`: Item skipped due to future release date
|
||||
|
||||
#### Error Messages
|
||||
|
||||
- `API connection error for [app]`: Connection to the media app failed
|
||||
- `API key invalid for [app]`: API key authentication failed
|
||||
- `Command timeout`: A search command took too long to complete
|
||||
- `Failed to process [media item]`: Processing of a specific item failed
|
||||
|
||||
## History
|
||||
|
||||
The History section shows a record of all processed media:
|
||||
|
||||
1. Navigate to the **History** section from the sidebar
|
||||
2. Use the dropdown to filter by application
|
||||
3. Use the search box to find specific media items
|
||||
|
||||
History entries include:
|
||||
|
||||
- Media name
|
||||
- Action taken (search or upgrade)
|
||||
- Result (found, not found, error)
|
||||
- Date and time processed
|
||||
|
||||
## Scheduling
|
||||
|
||||
The Scheduling section allows you to visually manage when hunting occurs:
|
||||
|
||||
1. Navigate to the **Scheduling** section
|
||||
2. Click on time slots in the calendar to toggle activity
|
||||
3. Use the controls to:
|
||||
- Add specific schedule rules
|
||||
- Copy schedules between days
|
||||
- Clear schedules
|
||||
|
||||
## Managing Apps
|
||||
|
||||
### Resetting App Cycles
|
||||
|
||||
If you want to restart the hunting process for a specific app:
|
||||
|
||||
1. From the home screen, locate the app card
|
||||
2. Click the **Reset Cycle** button
|
||||
3. The app will restart its hunting cycle from the beginning
|
||||
|
||||
### Viewing API Usage
|
||||
|
||||
To monitor API usage and avoid rate limiting:
|
||||
|
||||
1. Check the API counts in each app card on the dashboard
|
||||
2. The format shows: `API: [current count] / [limit]`
|
||||
3. The color indicates status:
|
||||
- Green: Safe usage level
|
||||
- Yellow: Approaching limit
|
||||
- Red: At or near limit
|
||||
|
||||
## Stateful Management
|
||||
|
||||
Huntarr uses stateful management to track which media items have been processed:
|
||||
|
||||
- **Initial State Created**: When the state was first created
|
||||
- **State Reset Date**: When the state will automatically reset
|
||||
|
||||
To manually reset the state:
|
||||
|
||||
1. Go to **Settings > General > Stateful Management**
|
||||
2. Click the **Emergency Reset** button
|
||||
3. Confirm to clear all processed media IDs
|
||||
|
||||
## Managing Settings
|
||||
|
||||
### When to Adjust Settings
|
||||
|
||||
Consider adjusting your settings when:
|
||||
|
||||
1. You see frequent API rate limit warnings
|
||||
2. Media searches are too aggressive or not aggressive enough
|
||||
3. Your download queue is consistently full
|
||||
4. You need to prioritize certain media types
|
||||
|
||||
### Recommended Workflow
|
||||
|
||||
For an optimal Huntarr experience:
|
||||
|
||||
1. Start with conservative settings (low search counts, high sleep durations)
|
||||
2. Monitor logs and API usage for a few days
|
||||
3. Gradually increase search intensity if your system and APIs can handle it
|
||||
4. Use scheduling to run more intensive searches during off-peak hours
|
||||
|
||||
## Practical Examples
|
||||
|
||||
### Scenario: Initial Library Population
|
||||
|
||||
When first setting up Huntarr with a large backlog of missing media:
|
||||
|
||||
1. Set higher values for **Missing Items to Search**
|
||||
2. Set **Upgrade Items to Search** to 0 temporarily
|
||||
3. Use scheduling to run 24/7 until the initial backlog is cleared
|
||||
4. Monitor API usage closely to avoid hitting limits
|
||||
|
||||
### Scenario: Maintenance Mode
|
||||
|
||||
For ongoing maintenance once your library is well-populated:
|
||||
|
||||
1. Reduce **Missing Items to Search** to lower values
|
||||
2. Increase **Upgrade Items to Search** to improve quality over time
|
||||
3. Set longer **Sleep Duration** values
|
||||
4. Schedule intensive searches for overnight hours only
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand how to use Huntarr, check out the [FAQ](faq.md) for answers to common questions and advanced usage tips.
|
||||
Reference in New Issue
Block a user