Sickchill: Weird edge case with incorrect torrent name

Created on 21 Jun 2016  路  23Comments  路  Source: SickChill/SickChill

I finally tracked down why Sickrage kept on downloading Elementary.S01E01.1080p.WEB-DL.DD5.1.H.264-Juggalotus[rarbg] turns out the folder and file are named incorrectly compared to the torrent.

Ref: https://rarbg.to/torrent/luf9z8m

@rarbg not sure if there's even anything that can be fixed here.

Bug / Issue

All 23 comments

Thanks for the issue report! Before a real human comes by, please make sure your report has all the below criteria checked

  • [ ] Include basic information: Branch/Commit, OS, What you did, What happened, What you expected
  • [ ] Enable debug logging (be sure to disable after the bug is fixed)
  • [ ] Post debug logs, either inline (for smaller logs) or using gist

Please make sure you also read how to create an issue and followed all of the steps.

The title should describe your issue. Having "SR not working" or "I get this bug" for 100 issues, isn't really helpful. We will close issues if there isn't enough information.

Sometimes the devs may seem like grunts and respond with short answers. This isn't (always) because the dev hates you, but because he's on mobile or busy fixing bugs. If something isn't clear, please let us know, and this bot may get updated to automatically answer you.

Thanks!

@OmgImAlexis
This is deffinetly a no-fix. Thats like 1 in 50000 :)

Is there a scene label that can be added for fuck ups like that? Similar to how we have nuked, etc.

This totally not a bug from SR's side, scene usually does a DiRFIX but aren't usually raced either and as this is p2p only if @rarbg fix it on their side.

@OmgImAlexis
Only if its completely fucked up like uploaded e02 instead of e03 tagged as e03 it wont be renamed , it will be REPACKed ( .REPACK. ) , also old one will be deleted

Is there anything for now that can be done since this has been going on for months now and I've only just managed to find the source of the issue. I guess manually downloading it will "fix" it for me but others may have the same issue.

Mark the download as failed on SR, won't download it again.

That doesn't fix it for anyone else though.

This is really something the uploader has to fix, there isn't any ai to detect human mistakes like this , like rarbg said , the uploader should had uploaded a REPACK with fixed naming. As the files are Elementary.S01E01.1080p.WEB-DL.DD5.1.H.264-Juggalotus while the title according to the site is Elementary.S03E01.1080p.WEB-DL.DD5.1.H.264-Juggalotus[rartv]

The API is returning the correct , fixed title , right ?

Just checked - yes the API is returning the correct fixed title.
Well , i would suggest that you do the following to prevent this happening ever in the future - for single video file releases use the name from the API as a name , not the filename inside the torrent.... that should pretty much cover it ?

@rarbg SR will snatch as the correct one s03e01, but on post processing ,the download it will see has the files which are incorrect and treat them as a download for S01E01. And will still think s03e01 didn't complete as it doesn't see files for it. Hopefully i made sense :P

@duramato
Is the postprocessor aware of the source site of the file ? If yes just quick hack the postprocess to rename single video file releases use the name from the API as a name to rename to before running processing ?

@duramato @OmgImAlexis
Also , what i can do is talk to the uploaders to resolve a list of torrents with the same issue , or maybe delete them , but again - i cant promise that this wont happen in the future!
Looking at it this is a 7 year old rule on the site , title on the site>filename and its been like that as long as i remember....

Unfortunally it can't associate files with the origin when the download is finished.
Imagine a user wants to snatch s03e01 but will generate files with Elementary.S01E01.1080p.WEB-DL.DD5.1.H.264-Juggalotus , and won't be able associate both.
And something which can happen too and would be bad:
user snatches s03e01 , the right after snatches the "real" s01e01. The misslabeled s01e01 will be PP in place of the "real" one

Well if you could try and talk with the uploaders to fix this it would be swell, but yeah i understand it can't be something thats garanteed

@duramato since the magnet is a hash of the torrent can we not check the hash of the downloaded files and if it's got a different name from the magnet we snatched we rename?

@OmgImAlexis If you can do that , thats a great work around

@OmgImAlexis Are you suggesting hashing the files with bittorrent's method to see if both match? That's very resource intensive, and very overkill to only fix a 1 in a mil. case

@duramato no , to open the bencoded data and read what the dir name is

And compare to what? After the files are downloaded SR doesn't know the originating torrent, SR is only looking at the files

@duramato so you cant make SR keep a database of hashes+names ?

Could be done, but the files don't have ep names so the mislabeled dir name will match the real S01E01. So if you have snatched s03e01,then snatch S01E01 and that one finishes, when post processing how will it know which one should it match to? First occurrence of the dir name? And what if S01E01 gets snatched first? Dir names would be the same because of the typo. There are many ways it can "break"

@duramato if you are post processing based on names that is a very bad mistake , that is not only an issue in this current case but also an issue if there are 2 torrents with the same names in the torrent structure
when you have an internal db with hashes + names and your processing is done with hashes you can simply on download complete before processing check into that internal db what this hash name is and if this name is different that the one you wrote into that same db from the API - use the name from the API as base instead of the the one on the torrent.
if you are asking about if you start xxx as torrent name and xxx another torrent on the same torrent client - that shouldnt be an issue if you use hashesh as dir bases

Was this page helpful?
0 / 5 - 0 ratings