[Bug]: Jellyfin → TubeArchivist watch sync keeps bumping watched_date and breaks TubeArchivist auto-delete

[shmuelsash]

I've read the documentation

• I'm running the latest version of tubearchivist-jf-plugin.
• I'm running the latest version of TubeArchivist.
• I have read the how to open an issue guide, particularly the bug report section.
• I have searched for both closed and open already existing issues about the problem I am reporting.

Operating System

TrueNAS Scale (Jellyfin in Docker), Jellyfin 10.11.8, TubeArchivistMetadata 1.4.4.0, TubeArchivist 0.5.10

Your Bug Report

Describe the bug

When the TubeArchivistMetadata plugin is configured to sync watch status from Jellyfin back to TubeArchivist, the plugin repeatedly updates the watched_date in TubeArchivist every time a video is played or progress is reported in Jellyfin, even if the item is already marked as watched.

TubeArchivist’s auto-delete logic is based on player.watched_date (delete watched items older than N days). Because the plugin keeps bumping watched_date to “now”, videos never become older than the global / channel autodelete_days threshold, so TubeArchivist’s auto-delete never triggers for those items.

In other words: playback in Jellyfin keeps resetting the TubeArchivist watch timestamp, which effectively breaks TubeArchivist’s retention feature when Jellyfin → TubeArchivist sync is enabled.
I confirmed this by comparing /api/video/<id>/ output from TubeArchivist before and after playback.

Example from TubeArchivist /api/video/<id>/:

First read (before re-playing in Jellyfin)

"player": {
  "watched": true,
  "watched_date": 1776605115,
  "duration": 986,
  "duration_str": "16m 26s"
}

Second read (shortly after triggering a Jellyfin sync by playback)

"player": {
  "watched": true,
  "watched_date": 1776605359,
  "duration": 986,
  "duration_str": "16m 26s"
}

The video was already watched and watched: true in both responses, but the plugin caused watched_date to jump forward by ~244 seconds just from briefly playing content through Jellyfin. This happens repeatedly.

Because TubeArchivist only auto-deletes when player.watched_date <= (now - autodelete_days * 24h), this continuous bumping prevents videos from ever satisfying the “older than N days since watched” condition.

Steps To Reproduce

1. Environment:

   • TubeArchivistMetadata plugin 1.4.4.0 in Jellyfin.
   • TubeArchivist 0.5.10.
   • TubeArchivist global setting downloads.autodelete_days set to 1.
   • No per-channel autodelete_days overrides (so global setting applies).

2. In TubeArchivist:

   • Download a video and let metadata sync.
   • Make sure it is marked as watched once (either directly in TA or via Jellyfin).
   • Call GET /api/video/<youtube_id>/ on TubeArchivist and note:
     • player.watched is true.
     • player.watched_date is some timestamp T1.

3. In Jellyfin:

   • Play any video for a short time (so the plugin sends progress / watch updates and triggers a sync).
   • Stop playback.

4. Back in TubeArchivist:

   • Call GET /api/video/<youtube_id>/ again and compare player.watched_date:
     • player.watched is still true.
     • player.watched_date has changed to a newer timestamp T2 > T1, even though the video was already watched.

5. Repeat step 3–4 two or three times:

   • Each time, player.watched_date advances closer to “now`.

6. As a side effect:

   • TubeArchivist auto-delete (based on autodelete_days = 1) never picks these items up, because watched_date is always very recent.

Expected behavior

Once TubeArchivist has a watched item with a watched_date set, syncing from Jellyfin should not keep resetting that watched_date to the current time.

Possible expected behavior (any of which would avoid breaking TubeArchivist auto-delete):

• Only update TubeArchivist’s watched / watched_date when transitioning from watched = false → true, and avoid changing watched_date if it is already true (unless that specific video is being rewatched).

The key point is that playback (or a sync triggered by playback) should not continually push TubeArchivist’s watched_date into the future for already-watched items, because TubeArchivist uses that timestamp for its retention / auto-delete feature.

Additional context

• TubeArchivistMetadata plugin version: 1.4.4.0
• TubeArchivist version: 0.5.10
• TubeArchivist auto-delete setting: Global downloads.autodelete_days = 1
• Channel for test videos has no channel_overwrites.autodelete_days field, so it should obey the global setting.
• With Jellyfin → TubeArchivist sync disabled, TubeArchivist’s auto-delete works as expected once watched_date is older than 1 day and the download queue runs post-processing.

Relevant Jellyfin log output

Here is a Jellyfin log snippet from Jellyfin.Plugin.TubeArchivistMetadata during a sync:

[<TIMESTAMP_1>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Playback progress for video <VIDEO_TITLE_1> set to 0 seconds for user <USERNAME>.
[<TIMESTAMP_1>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Watched status for video <VIDEO_TITLE_1> set to True for user <USERNAME>.
[<TIMESTAMP_2>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Playback progress for video <VIDEO_TITLE_2> set to 0 seconds for user <USERNAME>.
[<TIMESTAMP_2>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Watched status for video <VIDEO_TITLE_2> set to True for user <USERNAME>.
[<TIMESTAMP_3>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Playback progress for video <VIDEO_TITLE_3> set to 0 seconds for user <USERNAME>.
[<TIMESTAMP_3>] [INF] [<THREAD_ID>] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: Watched status for video <VIDEO_TITLE_3> set to True for user <USERNAME>.
...
(many more lines in the same pattern for different videos)

As you can see, during a single sync the plugin iterates over a large number of items and, for each one, sends:

- "Playback progress ... set to 0 seconds"
- Immediately followed by "Watched status ... set to True" (or False)

These items were already present and many were already watched on the TubeArchivist side; this appears to be a bulk re‑assertion of watch state rather than a one‑time transition from unwatched → watched.

Because TubeArchivist updates `player.watched_date` every time it receives a "watched = True" event from the plugin, this bulk sync effectively resets the watched timestamp for each video to the current time. That in turn breaks TubeArchivist’s retention / auto‑delete feature, which only deletes items whose `watched_date` is older than N days.

Anything else?

Related TubeArchivist issue where we tracked this down:
tubearchivist/tubearchivist#1150

The investigation there shows that TubeArchivist’s auto-delete logic works as designed when watched_date is stable, and that the repeated updates coming from this plugin are what prevent videos from ever aging past the retention window.

[Jurrer]

Hi, I went around to finally fix this(I was procrastinating)

The root cause is that we're syncing whole channels, but we don't need to. We just need to sync watch state of videos.
If we sync whole channel, all channel videos in TA get marked as watched, no way to avoid this.

As a bandaid solution I've been running the sync job very rarely(once a week).

I have this fixed locally, will test it a bit more and prepare a PR

[Jurrer]

@shmuelsash can you verify it only happens for channels that are fully watched?

channels that have at least one unwatched video should not overwrite the watched_date

[Jurrer]

Reading your issue more closely you mention "progress update" or JF->TA sync job.
These are two different operations, and there is different logic applied.

• JF->TA sync job I fully agree, it shouldn't overwrite the watched_date and it's a bug IMO

• updating progress when watching a video - you're actually watching the video so it's logical the watched_date is updated.
  Theoretically if we changed it to keep the oldest watched_date, it would lead to situations where you're watching the video and it gets suddenly deleted by auto-delete job (bad)

[Jurrer]

@DarkFighterLuke hi ✋🏼
Could you take a look at my bugfix ⏫ and release it to the people?

[shmuelsash]

Reading your issue more closely you mention "progress update" or JF->TA sync job.
These are two different operations, and there is different logic applied.

• JF->TA sync job I fully agree, it shouldn't overwrite the watched_date and it's a bug IMO

• updating progress when watching a video - you're actually watching the video so it's logical the watched_date is updated.
  Theoretically if we changed it to keep the oldest watched_date, it would lead to situations where you're watching the video and it gets suddenly deleted by auto-delete job (bad)

What I meant by "progress update" is that when any video is watched in Jellyfin it triggers a complete update of every video in the TA catalog. I definitely agree that it should update the watched_date for videos in progress.

[shmuelsash]

@shmuelsash can you verify it only happens for channels that are fully watched?

channels that have at least one unwatched video should not overwrite the watched_date

I think it does happen regardless, but I don’t have logs to back that up. I’m basing this on what I’ve observed: I’ve often had videos from channels that were unwatched for a while, yet the watched ones still weren’t deleted.

[Jurrer]

Some time ago I've fixed an issue when the sync would ALWAYS overwrite the watched_date.
It shouldn't do that anymore. First, it checks in Tubearchivist if a video is the same state(watched/not watched) and then it only synchronizes the differences(meaning it does not mark already watched video as watched).

Now the issue is specifically related to synchronizing whole channels.
I see it locally, after couple days on a fixed version, it definitely works as it should.