NZB mismatches

[Killer Skunk]

Hi,
a lot of different posters these days to tricks with NZBs,
for example they post 716 blocks seperately and the NZB gathers to it as 1 file,
while the block can be shattered everywhere, atm UE will then name then all to the names on the headers, which isn't appriate at all, nor are it multiple files, all what has been declared in the NZB.

Another trick they do which is in the same route, is renaming all there rare files to different names, which then the nzb will correct, again.

As UE takes headers still as it's main item to name, these things go wrong,
please fix.

[alex]

The problem here I think there are a few come and go paid users' gathering websites who want you to download nzb exclusively along with the passwords from them only.

Otherwise I don't see any significant number of posters left.

Then posting programs like nyuu it appears have a lot of obfuscating options, essentially making them spam tools, for all those users who try to download headers in the affected newsgroups they see a lot of random headers.

So it is not clear what to fix here, if usenet servers had stricter posting policies maybe it would help, but probably we are past that point.

[Killer Skunk]

The spam part i can agree on, nevertheless it's the way how several routes decided to post these days, in keeping them hidden in the underground.

Though if we just had a option, to follow the nzb logic instead of it always has to makes it's info fromout the headers, we could manually fix the specific downloads to come in correctly, which now with luck can be a handjob, and with badluck needs other downloads, like newsleacher, sabnzb and sonarr. And your product is way to good to be driven away from it for part of the downloads.

Certain indexers even have there own post routes, like wtfnzb (not omgwtfnzb), their nzb's only work by letting the nzb rule the filenames and the buildup of the files.

[alex]

Try to give me an example or a few examples (here or through email), so I could understand what exactly you mean then I could check it.

In the past when most posts were usable directly I implemented some requests which now I understand were caused by obfuscation, I just didn't imagine it will become the main trend.

[Killer Skunk]

Try to give me an example or a few examples (here or through email), so I could understand what exactly you mean then I could check it.

In the past when most posts were usable directly I implemented some requests which now I understand were caused by obfuscation, I just didn't imagine it will become the main trend.

Will take some time (days? weeks?) again to run into them again, but i shall harvest a view and mail them then after.

[Killer Skunk]

Sadly i cannot add bigger files then 250k, i've another example which i just cannot attach.

[Killer Skunk]

It seems that the problem maker is the way how for example nyuu can post,
ngpost and nyuu post do almost the same, butttt...

Code: Select all

<file poster="suBD3PM7zTphv@nyuu.com" date="1694628571" subject="[02/49] - "AKXzzoozmxmM1HxRVJNIGmJsrcZlrRMqb.part01.rar" yEnc  514850816 (1/719)">
 <groups>
  <group>alt.binaries.encrypted</group>
 </groups>
 <segments>
  <segment bytes="716800" number="1">f1a5a87a007b4e439cb20681aa9bb5ab@ucovGItMMzOwvFG.0wy</segment>
  <segment bytes="716800" number="2">fe45dcc310d14f7f92388140b973780b@NzU567tgxYfiSD6.Xv8</segment>
  <segment bytes="716800" number="3">a289e21420d54213a8f82835921521c9@Tlp0DxIJlVseZsb.rYA</segment>
  <segment bytes="716800" number="4">c5599277e2204730b37fa2ac2deceb82@Cza4gonrqI01mRX.zMs</segment>
  <segment bytes="716800" number="5">645f6b6b679446be84f6bb56a3d2675e@fSf5CENSug3VebK.HlE</segment>
  <segment bytes="716800" number="6">89c22baa6cd94faab27c1332f925c6ae@hpzKpsEA6qh7mwV.0JW</segment>
  <segment bytes="716800" number="7">9b646fe4c9cc4946a81811faf781166d@poC7b4LlBBSGwNj.ugF</segment>
  <segment bytes="716800" number="8">b2bd64e27bca4e55937d4ca184132d43@NKpKgqPwPpxiKEh.1X4</segment>
  <segment bytes="716800" number="9">029f6fb89f2743ebb9ee0175013f717e@3bnk9dobshznuaN.7h2</segment>

ngpost ends such different named segment with an @ngpost tag, and nyuu does not,
if you try to download above in usenet explorer,
you get a file for each segment instead of the builded up result.

ngpost example, which does download correctly:

Code: Select all

  <file poster="KUdGDSd4voM6d@ngPost.com" date="1702307519" subject="[02/41] - "wAfPUHzz8XW9vHlWJFzimh.part01.rar" yEnc (1/147) 104857600">
    <groups>
      <group>alt.binaries.mp3</group>
    </groups>
    <segments>
      <segment bytes="716800" number="1">3117e6c74eda41ec875382d1a12819a4@ngPost</segment>
      <segment bytes="716800" number="2">bc0e2c225a674ca1ab925bfa538c8402@ngPost</segment>
      <segment bytes="716800" number="3">6206064e05264a50b06feb9d19a50d34@ngPost</segment>
      <segment bytes="716800" number="4">d0eafd7b258d4df0be98d6abfe183690@ngPost</segment>
      <segment bytes="716800" number="5">71dd05aa48a24e7aac00e242418a6831@ngPost</segment>
      <segment bytes="716800" number="6">bab5cc4fa1a94c5596ff967379bed63a@ngPost</segment>

It can also be the length of the segment is wrong or any, but what's clear is
that the problem lays in the segment names and how ue handles it.

[alex]

I didn't read all the earlier replies, noticed them only now.

Those segments in the screenshots above are message-ids which are random, need to rather look at the subject field vs the attachment name inside the article body, in the nzb the file name is in the square brackets, in the screenshots above it appears it is enclosed in quotes.

The main issue is the nzb file above doesn't include par2 files, if they were there UE would rename the files to the correct file names listed in the par2 file or even if the files are damaged it would try to repair using not damaged blocks with the deep scan option in properties > save/unpack checked (it is by default), to try to find the file name inside the subject is less reliable, e.g. the square brackets may be a part of the file name itself and the archive should have redundancy using a winrar option which is usually not the case. What not including par2 files has to do with hiding the content, given that the real file name itself is also random is not clear.

From googling it appears this particular nzb site "wtfnzb" is dead since 2021 which is rather typical.