Fix Plex watchlist retained series processing - #484
Conversation
|
Thanks — PR #484 fixes the original early-continue issue, and reloading the current version configuration is a useful addition.\n\nOne database-level case may be worth testing before merge. The current diff allows the retained show to continue through normal metadata processing, but it does not carry any retained-series or missing-only context into metadata.py or wanted_items.py.\n\nWith granular versions enabled, consider this setup:\n1. A retained partial show has 1080p and 2160p enabled.\n2. An existing episode already has only its 1080p row.\n3. Another episode is genuinely absent.\n\nThe desired retained-series result, if this path is meant only to discover missing episodes and new seasons, would be zero new rows for the existing episode and the configured rows only for the absent episode. Under the existing wanted_items.py granular-version branch, the already-present episode may instead receive a new 2160p row.\n\nA local implementation avoided that by propagating a monitor_missing_episodes_only marker from both Plex ingestion paths through metadata expansion, then treating any existing episode key as satisfied for that background pass while still assigning all configured versions to genuinely absent episodes.\n\nCould you add a database-level regression test for that scenario? I can share the clean four-file reference patch if useful. |
… ingestion Manual/debug re-runs of a content source were still cache-skipped before reaching add_wanted_items, so flipping unblacklist_on_source_run and re-running had no effect on already-blacklisted items. The separate debug/manual ingestion route (get_and_add_wanted_content) also never read or passed unblacklist_on_source_run at all. Also logs source/unblacklist/ granular state at the start of each content source run for diagnosis. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
I checked the latest PR head. It now covers the missing-only retained-series flow we discussed, including propagation through both Plex ingestion paths and metadata, the granular-version database guard, and regression coverage for existing versus genuinely missing episodes. This matches the intended behavior of our local patch. Thanks for incorporating it! |
The in-flight sibling lookup matched only on imdb_id/season_number/state, so an episode requesting version 2160p could inherit a season-pack job another episode had already bound under version 1080p. Add a normalized version equality check (stripping the '*' upgrade-pending marker) to the sibling query so only same-version jobs are reused. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…klist create_and_add_item_to_wanted_queue()'s ghostlist/blacklist guard matched on imdb_id/season/episode only, with no version filter. The fallback-version flow in blacklisted_queue.py always blacklists the original item (e.g. 'Preferred') for that same episode immediately before creating the fallback (e.g. '480'), so the guard always found that just-created row and refused to create the fallback -- logging "QueueManager reported failure in creating/queuing fallback item". This made fallback versions a no-op for every user who configured one. Scope the 'Blacklisted' half of the check to the same normalized version being created; a genuine permanent ghostlist still blocks at any version. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…Save enable_task()/disable_task() only paused/resumed the in-memory scheduler job and updated ProgramRunner.enabled_tasks -- neither wrote task_toggles.json to disk. Persistence only happened via a separate 'Save' button (save_task_toggles). Any later settings save restarts ProgramRunner, which rebuilds enabled_tasks from the stale on-disk file, silently re-enabling a source the user believed they'd disabled minutes earlier. This is almost certainly the root cause behind widespread "I disabled Trakt/a content source and it's still running" reports: flipping the toggle looks like it worked (immediate UI update, immediate schedule pause) but isn't durable across the frequent restarts that follow other settings saves. Factor the persistence logic into _persist_task_toggles_from_runner() and call it from /enable_task and /disable_task, not just /save_task_toggles. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 participants
Summary
unblacklist_on_source_run, so re-running a source after enabling that setting actually reachesadd_wanted_itemsinstead of being cache-skippedsource,unblacklist,granular, andbypass_cachestate at the start of every content source run for diagnosis2160pepisode could previously inherit an in-flight1080pseason-pack job because the sibling lookup ignored versioncreate_and_add_item_to_wanted_queue()'s ghostlist/blacklist guard matched on imdb_id/season/episode with no version filter, so it always found the original item's own just-setBlacklistedrow and refused to create the fallback-version replacement — a no-op bug affecting every user with a fallback version configured since it was introduced in Januaryenable_task/disable_taskonly paused/resumed the in-memory scheduler job, never writingtask_toggles.json, so a source a user "disabled" would silently re-enable itself on the next restart triggered by an unrelated settings save — the likely root cause behind widespread "I disabled it and it's still running" reports (e.g. Trakt sources still firing after being toggled off)Tests