I’ve noticed that Sonarr/Radarr consistently report incorrect file hashes. Upon closer inspection, I saw that unnecessary "0"s—like padding—are being added. Could the issue lie with the download client integration or the indexers misreading the data?
Looking at it in even greater detail, I analyzed the JSON response file in Radarr. The padding is visible there too, but the "guid" field shows the correct entry.
This issue also renders Radarr's "Reject Blocklisted Torrent Hashes While Grabbing" option ineffective, as the hash ID turns out to be incorrect.
UPDATE: Could it be because the hashes in eMule are in MD5 format, while those in Radarr/Sonarr are SHA-1?
I’ve noticed that Sonarr/Radarr consistently report incorrect file hashes. Upon closer inspection, I saw that unnecessary "0"s—like padding—are being added. Could the issue lie with the download client integration or the indexers misreading the data?
Looking at it in even greater detail, I analyzed the JSON response file in Radarr. The padding is visible there too, but the "guid" field shows the correct entry.
This issue also renders Radarr's "Reject Blocklisted Torrent Hashes While Grabbing" option ineffective, as the hash ID turns out to be incorrect.
UPDATE: Could it be because the hashes in eMule are in MD5 format, while those in Radarr/Sonarr are SHA-1?