In my earlier post about designing an explainable sync ledger, I argued that one synced or failed flag hides too much. The implementation raises another question: after recording a result, can someone tell what to do safely?
One title, several outcomes
A movie or episode may succeed on two destinations and need attention on a third. A single global result loses that detail.
Plekt's Sync Activity groups history by movie or show while keeping each destination's result available behind the group. It records reasons for skipped destinations, exposes Fix match for unresolved cross-platform matches, and targets retries at failed destinations. Expected missing-library skips are excluded from retries. Group logs can be downloaded for investigation.
Those outcomes need different recovery paths:
- An unresolved identity needs a match decision.
- A failed destination may be retried.
- An expected missing-library skip should remain a skip.
Treating each as the same kind of failure would repeat work without resolving the underlying cause.
Fresh evidence before changing watch state
Some problems start before delivery. In v2.1.1, the Plex watch-state path preserves completed state across stale resume data and protects against unwatch races. Suspected Plex unwatches are rechecked against live metadata, and cached episode state is kept aligned so stale reports do not reach manual watch review.
These are targeted safeguards, not a claim that every provider-history edge case is solved. They address one important boundary: check that a signal is current before interpreting it as a change to watch history.
The question I keep asking
For each item, can someone see what happened, which destination received it or why it did not, and whether the safe next step is to retry, fix a match, review, or leave it alone?
That is the difference between a history table and an operational tool. The row is not the goal. A clear explanation and a safe recovery path are.
This follows the original design post. The v2.1.1 release notes include the Plex changes and the current known limitations.
I'd be interested in how other media integrations distinguish a real unwatch from stale resume data.
Try Plekt
Plekt is open source and self-hosted: project and source, website, live demo, Discord community, and r/plekt.
Disclosure: I maintain Plekt. I used AI assistance to draft this post under my direction, checked the technical details against the current release notes and project docs, and AI is not part of the application at runtime.
Top comments (0)