|
2013-03-11 15:42:09 GMT
|
It looks like they are having to try harder and harder to obfuscate releases now.
An example is this: https://nzbx.co/d?e67824513b045b9a47735e27845f7093
My dog tells me that this is Girls.S02E09.HDTV.x264-2HD, which aired March 10 2013 on HBO.
This is clearly very difficult to decode. It has been posted to a.b.etc (not necessarily a multimedia group), the rars have been renamed, and of course the release name isn't in the header. My dog tells me this release was available and named properly on nzbs.org and nzb.su very rapidly after posting. My dog also tells me it was available on omgwtfnzbs immediately after being filled, but that's not a fair comparison as omgwtfnzbs is piped the NZB directly and doesn't scan headers to index.
The only 'connection' we have available is the release ID. The #teevee ID is 130372, which is what the rar name and headers contain. My pet alligator is a bit of a usenet newbie and she messaged my dog this morning because she couldn't find the release. My alligator uses public sources to find downloads, such as binsearch and nzbx. Unfortunately my alligator doesn't have access to nzb.su, nzbs.org, or omgwtfnzbs so was eventually just sent the NZB from my dog.
Is there any chance of nzbX implementing some way of release determination? It could 'check' unknown releases (with mp4/mkv files conforming to scene standards) against the #teevee database by release ID. That's probably the harder of the two, but nzbX could also implement, if it can't read the header, fall back to the file names within the rar. My dog tells me that the above release, although the rars and such were renamed, contained a file name 'girls.s02e09.hdtv.x264-2hd.mp4'. My dog imagines that this would be a relatively reliable method as changing the filename would change the hashes of the scene rars, which is generally speaking a big no-no.
Anyone have thoughts?
|
