renaming not happening, no unpack errors

Get help, report and discuss bugs.
Post Reply
eldon
Posts: 7
Joined: 16 Jul 2014, 17:32

renaming not happening, no unpack errors

Post by eldon » 07 Oct 2014, 09:14

running nzbget 13 on debian x64, i'm not using any post processing script, only a scan script that pauses incoming nzbs.

i've had a few renaming "errors" so i wanted to report them.
the nzbs were added with nzbdrone.

I renamed / unpacked the first one manually and the mkv got automatically moved by i'm not sure what to the nzbdrone directory and the download directory removed..

par2 files are for the "junk name" archives only but there's a cvf file amongst them with the original names and checksums.

what's bugging me is that nzbget doesn't log any warning or error at all, Par success / Unpack success

running the post processing again does nothing with almost no log output :
info Tue Oct 07 2014 09:51:59 Collection Falling.Skies.S01E09.REPACK.720p.BluRay.X264-CLUE added to history
info Tue Oct 07 2014 09:51:59 Queueing Falling.Skies.S01E09.REPACK.720p.BluRay.X264-CLUE for post-processing
info Tue Oct 07 2014 09:51:59 Falling.Skies.S01E09.REPACK.720p.BluRay.X264-CLUE returned from history back to download queue

i've attached three of those nzbs

.eldon
Attachments
norename.zip
(52.16 KiB) Downloaded 153 times

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: renaming not happening, no unpack errors

Post by hugbug » 07 Oct 2014, 10:23

No errors were reported because everything went OK:
  • the download consist of obfuscated file names plus par-files;
  • NZBGet uses par-files to restore original names. That step completed successfully;
  • then the archive was unpacked; Also successfully;
  • that's why the unpack status is success.
After unpack we have a bunch of obfuscated archive files and NO ANY OTHER FILES. I don't see any cvf-files. Did you mean svf BTW? Not there as well. Anyway NZBGet doesn't use svf-files for renaming but rather only par-files. If there were par-files there NZBGet would restore original file names AND IT WOULD STOP processing; second level archives are not unpacked by NZBGet but there is a pp-script for that in the extension scripts section of the forum.

I think the poster has screwed things up or we deal with a new type of obfuscation (double obfuscation) but in a latter case the nzb lacks additional par- or other files (svf, etc.) which could contain original names. Anyway I hope these are just messed posts because supporting new obfuscation methods requires a significant amount of work.

If you have more of such nzbs please send me at nzbget@gmail.com.

eldon
Posts: 7
Joined: 16 Jul 2014, 17:32

Re: renaming not happening, no unpack errors

Post by eldon » 07 Oct 2014, 12:22

okay you were right, it's a double obfuscation
the obfuscated archives i saw as the unpack result, were inside the downloaded obfuscated archives set..

the second level obfuscation doesn't have par2 but an (obfuscated) svf file (yes svf sorry, my tool is called cvf so i got confused)

it shouldn't be too complicated to handle the svf based second level obfuscation but i understand that it's not in your plans for nzbget core and should be handled by a post processing script.

i have no idea if this method is getting popular or not but it's is a recent post (73 days) :
https://www.usenet-crawler.com/details/ ... 9449550dc2

eldon
Posts: 7
Joined: 16 Jul 2014, 17:32

Re: renaming not happening, no unpack errors

Post by eldon » 07 Oct 2014, 12:31

a quick question

is nzbget monitoring the download directory after unrar / unpack success ?

when i do (or during) the manual renaming and unpack, the (renamed) archives get removed and the mkv moved to the destination directory.

i first thought it was nzbdrone that was cleaning up after a successful nzbget download but i killed it and it happened again so it must be nzbget doing its thing..

I guess it shouldn't get in the way if i was using a post processing script but doing it manually gets problematic.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: renaming not happening, no unpack errors

Post by hugbug » 07 Oct 2014, 12:47

eldon wrote:the second level obfuscation doesn't have par2 but an (obfuscated) svf file (yes svf sorry, my tool is called cvf so i got confused)
Indeed, looking at file sizes I can now recognize the svf-file.

Fast deobfuscating is a major feature of NZBGet. If such posts become more popular I'll probably add support for this into NZBGet. Let me know if you encounter more nzbs of this kind. Still it's a weird way to obfuscate and I really hope it's just messed posts.
eldon wrote:is nzbget monitoring the download directory after unrar / unpack success ?
No, once the nzb-job is completed (added to history) it is not processed by NZBGet anymore.
Moreover all changes made by NZBGet are logged e. g. "renaming file xxx to yyy", "deleting file xxx", "moving file xxx to yyy", etc. Check the log if you think it was NZBGet.

void.pointer
Posts: 60
Joined: 28 Sep 2014, 20:58

Re: renaming not happening, no unpack errors

Post by void.pointer » 01 Dec 2014, 03:34

I'm seeing the same thing. Attached nzb. Looks like this is common. SickBeard isn't able to pick up the episode after it's downloaded because it's got a SHA1 hash-like filename inside a directory, it doesn't seem to support this kind of structure. It seems like NZBget should be processing this into an expected single filename.
Attachments
The_100_S02E01_720p_WEB-DL.zip
(21.56 KiB) Downloaded 149 times

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: renaming not happening, no unpack errors

Post by hugbug » 02 Dec 2014, 10:19

void.pointer wrote:I'm seeing the same thing. Attached nzb. Looks like this is common. SickBeard isn't able to pick up the episode after it's downloaded because it's got a SHA1 hash-like filename inside a directory, it doesn't seem to support this kind of structure. It seems like NZBget should be processing this into an expected single filename.
This NZB is perfectly OK and is in no way related to the problem reported by topic starter.

What you experience is a well known problem of SickBeard, see this topic.

Post Reply

Who is online

Users browsing this forum: No registered users and 47 guests