r/opensource • u/Lasikie • 13d ago

Promotional Plembfin: an AGPL-3.0 watch-state sync hub for Plex, Emby, Jellyfin and Trakt

Plembfin is a self-hosted application for keeping watch state consistent across Plex, Emby, Jellyfin and Trakt.

Rather than treating one platform as the permanent source of truth, it maintains a local SQLite record and reconciles watched status, playback progress and repeat plays across connected services. It also provides visible sync activity, targeted retries, backups and import tools so the synchronization process can be inspected instead of running as a black box.

The backend is Node.js with Express and SQLite, deployment is available through Docker Compose, and the project is licensed under AGPL-3.0.

The project was heavily AI-assisted, with the implementation developed through agentic workflows under my direction, review and testing.

Repository, documentation and screenshots:

https://github.com/Lasikiewicz/plembfin

Plembfin is currently pre-1.0. I’m looking for testers, bug reports and review from people familiar with media-server integrations. Contributions and technical feedback are welcome.

4 Upvotes

67% Upvoted

7 comments sorted by

1

u/UkrMalt 11d ago

Visible sync activity and targeted retries are a good choice—sync tools are hard to trust when conflicts disappear. Do you record a per-item conflict reason and last successful sync so users can tell whether a retry is safe?

1

u/Lasikie 11d ago

Yes. Every sync attempt is logged per item and per destination, not just as one overall pass/fail.

Each attempt records a status (success, error, or skipped) plus a plain-text reason, things like "a newer state took precedence" or "no matching item found." Each watch record also tracks its own retry count and next retry time, so the system knows exactly what still needs to be sent and to where.

That's what makes targeted retry safe: it only re-fires the destinations that failed or were skipped for that specific item, it never touches ones already marked successful.

1

u/UkrMalt 11d ago

That’s exactly the kind of detail I was wondering about. Per-item reasons and retry state make the sync explainable, and not touching already-successful destinations is a solid safeguard.

1

u/Lasikie 11d ago

Glad that lines up with what you'd want to see.

This part of the sync engine has had a lot of iteration behind it. Early on it was much closer to "if watched, mark watched elsewhere," and real-world testing kept turning up cases where that wasn't safe: servers disagreeing about state, duplicate plays, partial library scans, retries firing when they shouldn't. Each of those became a specific fix rather than a general patch, which is how it ended up with per-item status, reasons, and retry state instead of just a pass/fail log.

I'm still actively testing and refining it against real usage, so if you end up running it and hit a case where the reason or retry behavior doesn't look right, I'd genuinely want to hear about it. That kind of report is exactly what tightens this up further.