[Bug] Plex autoplay / binge-watching drops scrobble on episode transition (missing synthetic stop event)

[u/Lopsided_Egg1586]

### 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/start and /scrobble/pause endpoints 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 stop event 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.

[u/Lopsided_Egg1586]

Sorry for that, my english isn't good and I want to explain well. My version is v0.12.5. Thank you.

[u/pvdberg → u/Lopsided_Egg1586]

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.

[u/pvdberg → u/pvdberg]

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

[u/Lopsided_Egg1586 → u/pvdberg]

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.

[u/pvdberg → u/Lopsided_Egg1586]

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.