[Bug] Trakt pull in v1.39.0 creates duplicates and writes incorrect events back to Trakt

[Danavans]

Hello,

I believe there is a serious regression in Scrob v1.39.0 affecting Trakt imports.

Until this update, Trakt pulls had always worked perfectly. After updating to v1.39.0, I ran a normal Trakt → Scrob pull and immediately noticed many duplicate entries in Scrob for July 20 and July 21, 2026.

I deleted the entire Scrob database and performed several fresh pulls, but every pull recreated the duplicates.

When I later checked Trakt, I discovered that my actual watch history had also been massively modified:

• +1,175 events on July 20
• +122 events on July 21

The legitimate activity was only:

• July 20: 7 episodes of Curb Your Enthusiasm
• July 21: 1 movie and 2 episodes of Curb Your Enthusiasm

This means approximately 1,287 events are incorrect.

The faulty events mainly concern Curb Your Enthusiasm and One Piece, the two shows I watched during those two days. They are not just duplicates of the episodes I actually watched. For example, I am only around season 3 of Curb Your Enthusiasm, but episodes from seasons 10 and 12 were added as watched. One Piece also received many duplicate events for older episodes.

The movie does not appear to be affected, so the issue may only affect TV episodes.

As far as I can tell, only activity from July 20 and 21 was affected. Older history appears to have imported correctly and does not seem to have been modified.

A Trakt → Scrob pull should only read data from Trakt. It should never create or modify events on Trakt.

Could you please investigate whether v1.39.0 can:

• Write events back to Trakt during a pull
• Reprocess recent episodes multiple times
• Incorrectly map episodes or seasons
• Send duplicated local entries back to Trakt

I have also opened a support request with Trakt asking them to remove only the incorrect events and identify which API client created them. I will update this issue as soon as they provide more information.

Environment

• Scrob version: 1.39.0
• Previous versions: No issues
• Import direction: Trakt → Scrob
• Incident date: July 21, 2026
• Affected dates: July 20–21, 2026

Please let me know which logs, database files, or screenshots would be useful.

[moodiness]

The likely issue is in backend/routers/trakt.py, inside _run_trakt_push().

The full push selects each watched media only once and calls add_movie_to_history() / add_episode_to_history() without the original watched_at timestamp. Trakt therefore creates new history events at the current time every time the push runs, causing large batches of duplicates.

The Pull path appears protected by exclude_cloud_source=CollectionSource.trakt, so the main problem is likely the non-idempotent full Push, not the import itself.

[Danavans]

Hi,

Thanks a lot for taking the time to investigate this and look through the code.

To be honest, I'm not a developer, so I can't really comment on whether _run_trakt_push() is the cause. I mainly wanted to report what happened from a user's perspective.

What I can confirm is that this had never happened before version 1.39.0. I've used Trakt imports many times in previous versions without any issue. The problem appeared immediately after updating to 1.39.0.

One thing I'm a bit confused about: in Scrob I only configured a Pull from Trakt (watch history, ratings and lists). I never configured or manually ran a Push to Trakt, so I'm wondering why _run_trakt_push() would run at all.

Also, if a full push really happened, why would it only affect Curb Your Enthusiasm and One Piece instead of my entire Trakt history? Those were the only two shows that ended up with hundreds of incorrect watch events.

I ended up cleaning everything manually. It took me almost two hours of clicking through more than a thousand history entries one by one... I definitely don't want to do that again (One Piece wasn't exactly the ideal series for this bug! 😅).

Do you think you've identified the root cause, and is this something that will be fixed in a future release? At the moment I'm afraid to sync with Trakt again because I don't know if it could happen a second time.

Thanks again for investigating this.

[moodiness]

Thanks for the clarification. Since you never enabled or ran a Trakt push, my initial _run_trakt_push() explanation does not fully match your case. I checked the v1.39.0 Pull path: it calls /trakt/sync and explicitly excludes Trakt from the outgoing fan-out, so a normal Pull should not write anything back to Trakt.

The fact that only the two recently watched shows were affected suggests another path, possibly live scrobbling or a media-server playback/sync event, rather than the full Push job. The Trakt support response identifying the API client and endpoint that created the events would be the strongest evidence. Until this is identified, I would keep all Scrob → Trakt options, especially Now watching, disabled.

[denny-cube]

FYI, I pull from Trakt regularly (almost daily), and I didn't find similar issues, all seems working flawlessly. And recently I watched both movies and TV series. So it should be something not so generic...
Hope this can help identifying the root cause.

[Danavans]

Small update: after seeing that another user regularly pulls from Trakt without any issue, I decided to risk testing it again.

I ran three fresh full Trakt → Scrob pulls, and this time everything worked correctly. No new duplicates appeared in Scrob or on Trakt, so for now the issue seems to have stopped.

I still find the timing suspicious, since the incorrect events appeared immediately after using Scrob and stopped once I stopped using it. But it may have been a temporary or very specific issue.

Thanks everyone for taking the time to investigate and reply. For now it seems resolved, and I’ll report back if it happens again.

[keldian]

As a possible mitigation angle: since the root cause seems tied to walking the entire history on each run, an incremental pull (tracking a cursor/last-synced timestamp and only touching items after that point) would shrink the blast radius of bugs like this considerably—a non-idempotent write bug in a scoped, incremental walk affects a handful of recent items instead of the whole history. Might be worth considering alongside the root-cause fix, not just for safety but because it'd also make scheduled/unattended syncs practical.

[keldian]

Heads up: with scrob updated to 1.42, I ran a Trakt history push, and it wrote nearly 1000 titles I've already watched back to Trakt as if they had been watched today—a mix of episodes/movies I hadn't touched in months, all stamped with "now" as a new watch date. Had to docker stop the container mid-push to limit the damage, but it looked like it was going to push the entire scrob history as new plays that didn't happen.

[Danavans]

Well... I guess this proves I wasn't going crazy after all 😅

Sorry this happened to you too, and good luck deleting those ~1,000 entries... I had to manually remove around 1,300 myself, so I know exactly how painful that is. And just to save you some time: don't expect Trakt support to remove them for you. I already asked, and they basically told me it would take months, so I ended up deleting everything manually.

The difference is that your issue happened during a Push, while mine happened with a Pull-only setup. They're not exactly the same scenario, but in both cases Scrob ended up writing incorrect watch history to Trakt, which really shouldn't happen.

That's what worries me the most. I actually really like Scrob, but Trakt is the one thing I can't afford to have corrupted. Until the root cause is found, I'm honestly a bit scared to sync with Trakt again. I really don't want to spend another two hours deleting 1,300 history entries by hand 😅

[keldian]

Recovery wasn't that painful as I had Claude make me a Python script to delete all plays from today. Worked like a charm.
https://claude.ai/public/artifacts/6557c1c4-9693-4fea-bed4-d012197e7182
https://claude.ai/public/artifacts/05fb66cb-89e2-4bc5-b07b-8322befa5a1c
I already had an access token from another app so I didn't need to use the auth script.

That said, I should mention I didn't have this issue in v1.39 or prior. Trakt Push worked as expected the few times I had tried it.

[ellite]

@Danavans @keldian , really sorry about that.
I think I finally found the issue. Will create a fix after work today.

[moodiness]

Update after reviewing the v1.43.0 fix and rebasing #84:

There appear to be two distinct scenarios in this issue.

1. Confirmed Full Push problem

The v1.43.0 fix in 27f66b8 addresses the reproduced case where a Full Push submitted the entire local history without watched_at. Trakt consequently recorded every title as a new play at the current time.

v1.43 now sends the latest completed local timestamp for each media item, so it should prevent the specific “hundreds of old titles watched today” failure.

2. Original Pull-only report

The original report was from a Pull-only configuration. That path already excludes Trakt from outbound fan-out, and the v1.43 change does not otherwise modify the Pull behavior. The incorrect season/episode mapping reported for Curb Your Enthusiasm and One Piece is therefore still not fully explained by this fix.

While reviewing v1.43, I also found three remaining Full Push safety gaps:

• the initial query selected media from every WatchEvent, while the timestamp lookup only considered completed events; an item with only an incomplete event could therefore still be sent with watched_at=None and become a false play stamped as now;
• only the latest play per media was retained, so legitimate rewatches were discarded;
• identical Full Push jobs submitted the same history batch again and relied on Trakt to recognize existing events.

PR #84 has now been rebased onto v1.43.0 and updated to address those remaining gaps:

• only completed watch events are eligible;
• every distinct completed play and timestamp is preserved;
• existing remote history events are compared and skipped before writing;
• recurring Pulls use an overlap-safe incremental cursor;
• an explicit Full resync remains available;
• regression tests cover incomplete events, rewatches and repeated pushes.

Validation after the rebase: 73 backend tests passed, including 14 Trakt tests and three focused Full Push safety scenarios.

I recommend keeping this issue open until the original Pull-only/wrong-episode scenario is either reproduced or tracked separately. The confirmed Full Push corruption is addressed by v1.43, while #84 adds the remaining history-safety guarantees.

[ellite]

Thank you @moodiness .
I'll have a look in a bit.