Root cause: We were blindly calling createCategory (409 if exists) then
editCategory (409 for unknown reason), but editCategory was failing and
the category kept its old save path, causing downloads to wrong location.
The 409 from editCategory doesn't mean 'already has this path', it means
the operation failed. Without checking first, we don't know why.
New approach:
1. GET /torrents/categories first to check current state
2. If category doesn't exist: create it with correct save path
3. If category exists with wrong path: edit to update save path
4. If category exists with correct path: skip (no API call needed)
Benefits:
- Avoids unnecessary 409 errors
- Only calls editCategory when actually needed
- Logs show exactly what's happening (create/update/skip)
- Handles both savePath and save_path response formats (v4.4.0+ compat)
- Better error logging with full response details
This ensures category save path is ACTUALLY updated when user changes
download_dir setting, fixing downloads going to wrong location.
References:
- qBittorrent API docs: https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1)
- Issue #15969: save_path vs savePath inconsistency in API v2.8.4+
qBittorrent's /torrents/editCategory endpoint returns 409 (Conflict) when
the category already has the specified save path (no change needed).
This is expected behavior when:
- User hasn't changed download_dir setting since last torrent
- Category already has correct save path
Previously logged as warning with full error stack trace, making it look
like an error when it's actually normal operation.
Changes:
- Check for 409 status code from editCategory
- Log friendly message: 'Category already has save path: /path'
- Only log unexpected errors with console.warn
Now both createCategory and editCategory handle 409 gracefully:
- createCategory 409 = category exists
- editCategory 409 = category already has this path
Both are expected, not errors.
The 409 (Conflict) status code from qBittorrent's createCategory endpoint
means 'category already exists', which is expected behavior, not an error.
Previously, the full error object was logged with console.log(), making it
look like an error in the logs when it's actually normal operation.
Changes:
- Check for 409 status code specifically
- Log friendly message: 'Category already exists' for 409
- Only log unexpected errors with console.warn
- Cleaner logs that don't alarm users
The flow still works correctly:
1. Try createCategory (succeeds if new, 409 if exists)
2. Always editCategory to update save path to match current config
3. Both operations complete successfully
Previously, when a user changed the download_dir setting after initial
setup, the qBittorrent category "readmeabook" would retain the old save
path. This could cause torrents to download to the wrong location,
depending on qBittorrent's Automatic Torrent Management (ATM) settings.
Root cause:
- ensureCategory() only created the category if it didn't exist
- createCategory API is idempotent but doesn't update existing categories
- If download_dir changed from /downloads to /downloads/RMAB, category
would still have savePath=/downloads
qBittorrent behavior:
- If ATM enabled: category savePath overrides per-torrent savepath
- If ATM disabled: per-torrent savepath takes precedence
Fix:
- ensureCategory() now calls both createCategory AND editCategory
- createCategory: ensures category exists (idempotent)
- editCategory: updates save path to match current download_dir config
- This guarantees category path is always synced with database config
Benefits:
- Users can change download_dir setting and it takes effect immediately
- Works regardless of ATM settings in qBittorrent
- No manual qBittorrent category management needed
Updated documentation/phase3/qbittorrent.md to explain category
management and save path synchronization.
Claude