Obfuscated files being renamed as they download

[cheeba777]

I have recently been downloading more obfuscated posts and found some problems that I don't know how to fix without a lot of manual work. I downloaded some posts lately that show the obfuscated files name under "Download Descriptions" in Newsbin program with rars showing as:

xcvbbz.10
xcvbbz.11
xcvbbz.12
etc...

and pars showing a different name, but all the same. eg:

asdf.par2
asdf.vol000+01.par2
asdf.vol001+03.par2
etc...

but as I download, the rar files are saved with different names and all of them are different from one another. This happens to both rars and par2 vol files. rars will also have no extension when downloaded. Also par2 vol files will all be named differently from one another so they do not recognize each other.

ie rars now look like:
hkgwfhosdfajfdsoa
kjfkjsdjklsdsldfck
hckaskdasakka
laajdkjsadkajsks


and pars will be like:
asdf.par2
sdssd.vol000+01.par2
yrdfsd.vol001+03.par2
etc...


When I double click on the par2 file it will be able to rename most files but if any need repair (which many do) they are not renamed and the post shows as missing many blocks because the files that are not renamed are not having their blocks counted. I have had to manually rename by trial and error all the rar files which were not renamed, which takes a long time. then in order to repair I must also rename all of the par2 vol files to the same as the par2 in order for par2 to be able to see the other repair blocks.

Please tell me there is another way.

Thanks

[Quade]

PM me some examples. If need be you can email the NZB's (assuming you used NZB's) to ts@Newsbin.com. Reference this post in the email.

Newsbin doesn't do on the fly renaming anymore. I mean newer versions of Newsbin. If the PAR says one name and the filename is some other name. Newsbin notes the filename and then does a rename after all the files download.

The problem with renamed and obscured files is that it removes one layer of PAR files ability to ID the files to know they belong to the set of files. Typically PAR files use, an ID on the beginning of the file and/or the filename to include a file in the set of files. If the first chunk of the file is missing AND the filename is incorrect, it's difficult to actually include the file in the set.

[cheeba777]

Thanks for the quick response. I have emailed you a nzb example.

[Quade]

Ok here's the issue.

1 - The filenames listed in the subject in the NZB's aren't the filenames that are in the actual files so,

"26850855dee8403dff3c464033f3a3dc.10"

gets saved as:

d6c5f61fe85fa0688418faefa739075e5782c66f

The PAR files use a third filename.

"bla bla bla.part01.rar"

So for this download to work you need

1 - The files have to download and be recognized by the PAR code, meaning if the first chunk is missing, it probably won't see it.
2 - After the last filename is downloaded, the PAR code has to rename it to the RAR filenames listed inside the PAR.
3 - Unrar the rars.
4 - Another problem is that the actual output filename inside the RARS is:

k8sHf5rjwGKem.mkv

Which is kinda useless.

You might want to use $(NZBFILE) in the unrar or download path so, you can ID what this file should really be named.

I've thought of a way to improve the PAR par by defaulting to using the par information from the other files even if a damaged one can't be id'd. In your case, you might want to install QuickPar and then double-click the PAR file and then manually import the mis-named damaged files. This might allow quickpar to find and use the damaged files to rename and repair.

These kinds of NZB's are ripe for automation using something like Sonaar with Newsbin which can rename the final MKV into a decent filename.

[cheeba777]

I have always been using Quickpar manually for the operations I described earlier. I do not use any autorar functions of the news client. I manually use quickpar and winrar seperately after downloading with Newsbin. I download the nzb for obfuscated post from nzb site which shows the rar files in the nzb as all having the same name but different extentions (same for pars2 files, but with a different name to the rars sometimes). The nzb is named for the correct name of the file (tvshow.s01e01.1080p.x264-GROUP) . I add the nzb to Newsbin and begin downloading. Newsbin creates a folder with the proper show title, but as stated earlier, all of the downloaded rars and par2s are renamed from what they originally said they were going to be called. After download finishes, I manually run Quickpar to rename and repair. with all of the problems listed above. then i manually unrar file and if unrared file name is still obfuscated I copy title from folder to rename the mkv file.

Thanks for the help.

[Quade]

. I do not use any autorar functions of the news client.

At this point, I'm not sure what you're asking from me then. I thought you wanted some AutoPAR changes but since you don't use it, there's really no changes I can make for you. I don't think you realize that there are 4 layers of obscured filenames here. For this to work, you'll have to manually import the files into QuickPAR (not depend on it finding the files automatically because as you noted, it can't automatically find damaged files with the wrong filename). This is what the "Add" button in Quickpar does.

1 - The subject is lying about the filenames.
2 - The actual filename in the posted file is a random string with no extension.
3 - The PAR files list the RAR's but the RARs are obscured too differently than 1 and 2. QuickPAR will have to rename 100% of the files to match the PAR file.
4 - The files inside the RARS are also obscured.


I used "AutoPAR" in Newsbin and it handled this NZB without me needing to touch it. Download, Rename and unrar were all 100% automatic. The only thing I didn't like was that the final output MKV needed to be renamed.

Since I had the name in the folder path, if I wanted to keep this file a rename would be easy.

[cheeba777]

thanks and sorry for the misunderstanding. I didn't know that the autopar function did more than what quickpar and winrar could do after the download.

[Tanamur]

Ok here's the issue.
You might want to use $(NZBFILE) in the unrar or download path so, you can ID what this file should really be named.

I've thought of a way to improve the PAR par by defaulting to using the par information from the other files even if a damaged one can't be id'd. In your case, you might want to install QuickPar and then double-click the PAR file and then manually import the mis-named damaged files. This might allow quickpar to find and use the damaged files to rename and repair.

These kinds of NZB's are ripe for automation using something like Sonaar with Newsbin which can rename the final MKV into a decent filename.

Hi Quade - Thanks for this suggestion and it is working partially for me. I am running Version 6.80B2. It is configured to create separate folders for both the archive file download and a separate folder for the UnRARed file. Both are to be named after the $(NZBFILE).

NewsBin is creating a folder named after the NZB file in the raw download location Z:\Usenet\Incomplete\$(NZBFILE)\ however, the UnRAR folder is not being created by NewsBin leaving only the obfuscated file in the completed folder Z:\Usenet\Complete\\ monitored by my PVR. (Edited to delete $(NZBFILE)

Is there a problem having both the download and unrar folder configured to be named after the $(NZBFILE)? Again, the raw download path (\Incomplete\$(NZBFILE)) and the unrar paths (\Complete\$(NZBFILE)) are different.

[Quade]

I found some of the obscured posts are purposely damaged causing Newsbin problems. I have a fix for it which will be in the next beta. Not all obscured posts do this.

Is there a problem having both the download and unrar folder configured to be named after the $(NZBFILE)?

There isn't. It's a good way to go.

[Tanamur]

I found some of the obscured posts are purposely damaged causing Newsbin problems. I have a fix for it which will be in the next beta. Not all obscured posts do this.

Is there a problem having both the download and unrar folder configured to be named after the $(NZBFILE)?

There isn't. It's a good way to go.

Many thanks for the quick reply and I will look forward to the next update.

[tuxlie]

I found some of the obscured posts are purposely damaged causing Newsbin problems. I have a fix for it which will be in the next beta. Not all obscured posts do this.

Could you expand a bit on this Quade please
For about a month now a large percentage of my downloads have been massively incomplete, requiring hundreds of block to complete, far beyond what the par files can cope with.
There is no rhyme nor reason to it. I wasn't doing anything differently. It just started

I don't use auto-unrar/par
I use quickpar manually, using the add button to add the files. Windows Explorer or Directory Opus which I use shows them the correct file size. I've tried using multipar instead, different news server providers, makes no different, they all still require hundreds of blocks, every file is damaged.

[Quade]

How about trying this one:

http://www.newsbin.com/downloads/nb680B5.exe

The logging tab will report "Post isn't the post requested" when downloading these purposely damaged files.

I don't use auto-unrar/par
I use quickpar manually, using the add button to add the files. Windows Explorer or Directory Opus which I use shows them the correct file size. I've tried using multipar instead, different news server providers, makes no different, they all still require hundreds of blocks, every file is damaged.

It's not an auto-par issue in this case. They're actually posted wrong. The work-around is I have to ignore the lies in the yEnc headers.

[travisaggie]

This is happening to me as of yesterday 12/29/2017. If I restart my computer, the problem goes away. I am not sure what is happening. I am running 6.73b4821.

[sirrichard]

I am seeing many and not sure even the pars download as expected. (ie they also appear random rubbish)
Are these fake posts released to waste people's time?

The header text of a smaller file (possibly a par or last file) indicates there could be something of interest:

PAR2 PKTD(# åy§ñ"wÑ(Ú¤ÄÈc?ûõàÄ:g[Ó:zÏ ŸPAR 2.0 RecvSlic Šm"ì$2E^QÜu¡zå5]œý*Hù߶öÚ!8ði˜-Áu>úyøëGÐÒ³pD: \K¼_nSñâ
ç„Ê`„sèm™Èî

–§  p:)¥:D©ÖáÉWFºžäœõHmÚˆ`æ—8X6èãVƒè
ÊŒÖg/÷ÒÓzht;m‹§w¹«·Ü‚ºŠSì!©À13cËéñ
äî&+”(1FùA^þë<_R¢qÅn®~±¯Íßv3(¼XÕ•²ÏoŇás?

and footer:

aÑýGÎÌyG‹Bö#MqŸi†Êá¹Zf/yø¯+äà^"®F’^€bEúPAR2 PKTt È­TÎã½ âåë‘VÓá?ûõàÄ:g[Ó:zÏ ŸPAR 2.0 Creator ParPar v0.2.2 [https://animetosho.org/app/parpar]

Sample of what appears in the download folder - no file extensions etc:

size | filename

805,622,000 _XAlwXK6aSBQFfCg2OWn0
805,622,000 QENDuBMHyb
805,622,000 59enCun9Xs4-4
805,622,000 nQbOjTIPf9TjbT
805,622,000 pgc80a
805,622,000 iS6_-5
805,622,000 x7sPJW5Maoo
805,622,000 o2NIvSJGF
805,622,000 BaM6Y-
805,622,000 hB0Gix7BNv-B4N06_Wjau5_Nv2
805,622,000 lXcKlQCda5JdUNclzMt9ZeN
805,622,000 ik4acp8k7U7-wgX7qaoUpxvr
805,622,000 UYb7fuyOuzJ3-X7qBTrLPCh1GWUiM

[Quade]

I am seeing many and not sure even the pars download as expected. (ie they also appear random rubbish)
Are these fake posts released to waste people's time?

Usenet, after numerous pretty steady years has been changing pretty rapidly. If these files are files from a much larger set with PARS then likely the PAR has the correct filename in it. Newbin will rename to the real filename after all the files download and Newsbin initiates repair.

Honestly, if you're not running 6.80 RC3 you ought to be. It's the best at handling these bizarre files.

[sirrichard]

Thanks I will give it a go and let you know how it goes.

Yes, part of a much much bigger set.

I am not yet 100% sure if the pars dont also download like this - no file extension and random char name.

Will see how the latest RC goes.

[Quade]

I am not yet 100% sure if the pars dont also download like this - no file extension and random char name.

Yeah, if this happens it'll be problematic. I saw Newsbin renaming some PARS from the subject because filenames from the posting headers didn't match the filenames of the downloaded file.

[sirrichard]

From what I can see, problem solved by latest RC - thanks!

Will post back if ever notice same issue but things seem to have returned to normal from what I can see, since installing the RC.

Thanks!