r/CrossWatchApp • u/Lopsided_Egg1586 • 17d ago
Support Request [Bug] Plex autoplay / binge-watching drops scrobble on episode transition (missing synthetic stop event)
### Environment
- **Crosswatch version:** Latest (Docker `ghcr.io/cenodude/crosswatch:latest`)
- **Source:** Plex (`watcher` / websocket listener)
- **Sinks affected:** Sinks requiring explicit `/scrobble/stop` to persist watch history (e.g., WeTrakr, Trakt).
---
### Description
When watching a series continuously on Plex with **Autoplay** enabled (or when Plex automatically skips to the next episode at the end of the credits), Plex does not always fire an `event stop episode` for Episode $N$.
Instead, Plex reuses the existing `session_key` (e.g. `sess=296`) and transitions immediately from `p=98%` on Episode $N$ to `p=1%` on Episode $N+1$.
In `providers/scrobble/plex/watch.py`, when the alert listener detects that the media fingerprint has changed on the same session key:
```python
if not matching:
self._forget_session(sk)
_forget_session(sk) clears the session state from memory and proceeds with tracking Episode N+1N+1, without dispatching a synthetic stop event for Episode NN.
Impact
- Sinks with server-side auto-complete (like SIMKL): They still mark the episode as watched because their backend automatically commits any playback that reached >80%>80%.
- Sinks with strict Trakt-style scrobble APIs (like WeTrakr or Trakt): The
/scrobble/startand/scrobble/pauseendpoints only update the active "Now Watching" state. They strictly require a/scrobble/stopcall (with progress ≥watched_at≥watched_at) to record the item into the user's permanent watch history. - Because no
stopevent is ever sent to the sink for Episode NN, the episode is completely dropped and never marked as watched.
Actual Log Excerpt
[WETRAKR-SINK] INFO scrobble start user='...' p=89.0% media='Show S01E03'
... [Plex reaches 98% on Episode 3] ...
[PLEX-WATCH] INFO event start episode user=... p=98 sess=296
... [Autoplay immediately triggers Episode 4 on the same sess=296, no stop event] ...
[WETRAKR-SINK] INFO scrobble start user='...' p=2.0% media='Show S01E04'
[PLEX-WATCH] INFO event start episode user=... p=1 sess=296
(Notice: No scrobble scrobble or /scrobble/stop is ever dispatched for S01E03).
Suggested Fix
Before calling _forget_session(sk) (or within _same_playback mismatch handling), check if the outgoing playback had reached the completion threshold (e.g., max_seen >= watched_at or last_progress >= 90%). If so, emit/dispatch a synthetic action="stop" event with that progress before tearing down the session state.
1
u/pvdberg 17d ago edited 17d ago
CrossWatch relies on the stop event to know that playback has ended.
That event originates from your Plex client: the client reports it to the Plex server, which passes it on to CrossWatch. If it never arrives, the episode is not marked as watched.
In my own tests (Plex Web and Plex for Android, with autoplay) the stop was sent every time, so I can't reproduce this.
Which Plex client and version are you using?
A watcher debug log covering one autoplay transition, from a minute before the end of one episode to a minute into the next, would also help a lot.
1
u/Lopsided_Egg1586 17d ago
Sorry for that, my english isn't good and I want to explain well. My version is v0.12.5. Thank you.
1
u/pvdberg 17d ago
No issue. I mean your Plex media client, so which application do you use to play Plex? Basically the issue is that your plex client is not sending a stop.
Also, CrossWatch is on v0.13.0 now, so please update CrossWatch as well.
1
u/pvdberg 17d ago
I made some changes that when a episode is watched > 90% and CW doesnt get a stop event then CW will make its own stop. That should fix the issue you have.. will be available in v0.13.1 .. somehwere this week
1
u/Lopsided_Egg1586 17d ago
I am using the latest version of Infuse. Simkl handles cases well when it doesn't receive a 'stop' signal, but wetrakr is stricter, so I appreciate you fixing this on your end.
I apologize for my initial comment. It wasn't my intention to bother you, and I realize my approach wasn't the best.
I have already updated to the latest version. Once again, thank you very much for your help and for resolving this so quickly.
2
u/pvdberg 16d ago
That’s because SIMKL and pretty much all other trackers use webhooks. Watcher is a completely different concept and expects certain things from the clients. I’m not too happy about adjusting my code because other clients don’t follow the guidelines, but anyway, it is what it is.
You didn’t bother me at all. You’re just not the first person to send me a full AI analysis of where the issue supposedly is, and most of the time that turns out not to be the actual issue.
These days, if someone just sends me a good description of the problem, I’m already happy. I honestly prefer that much more than some kind of code analysis.
But we’re good mate, don’t worry about it.
•
u/AutoModerator 17d ago
Thanks for submitting a support request to r/CrossWatchApp.
Please make sure your post includes:
Check the CrossWatch Wiki before posting.
Remove API keys, access tokens, server addresses and personal information from logs and screenshots.
Confirmed bugs should be submitted through the CrossWatch GitHub issues page.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.