-
Notifications
You must be signed in to change notification settings - Fork 7
Description
By happenstance, I noticed that a series I had on my server was updated on SeaDex and I decided to check that the pipeline I had set up for processing upgrades was working as intended. I have a script of my own that uses the torrent_hashes value in the cache.json to query the SeaDex API with it. Needless to say, its important that the script has access to accurate and up-to-date torrent hashes to prevent unintended results.
From what I can tell, it seems like in this scenario -- where I happened to have the best release on SeaDex in Sonarr already, but the previously cached torrent hash pointed to an old "best" that was never imported -- the torrent hash doesn't update in the cache.json and points still to the old torrent hash. Yet, the "updated_at" variable is accurate and up to date with the changes in SeaDex.
The bug didn't cause any catastrophe for me this time as my script had a safe fallback, but its possible others, or even SeaDexArr itself could run into issues from it.
I happen to know that the old torrent hash is for a release that used to be marked as "best" on SeaDex but was found to be broken, so got removed entirely and the "best" before it was reinstated, leading to my scenario. This is the entry in my cache with the stale hash.
"name": "BLUE LOCK",
"updated_at": "2025-12-30 22:18:25",
"torrent_hashes": [
"4c3e3d973a47d40926c66dd2e05530f3fb014b8d"
]
},
Here is my SeaDexArr_badboy.log for your debugging pleasure.