SABnzbd Forums

hi

there are several posting methods and cases where this feature might help, not to have to repair/unrar manually after a successful DL

for example when a post is pretty new, rars are up, maybe damaged or obfuscated but no par in sight yet, but you know pars are coming very soon
OR when the rars and pars are somehow posted seperately and you can´t combine them in 1 .nzb

the current method would be to DL rars and pars seperately, after that manually put them in 1 folder, repairing and unraring them (if you are stupid like me and can´t write your own postprocesing script), unfortunately that takes a lot of time to do it manually and could be solved very easily i believe/hope

my idea is that you can open a .nzb in sabnzb and specify a "par2 file/or folder of par2 files" you have on your pc (donwloaded it manually)
that way, even though in the original imported .nzb were only rars and no pars, the whole postprocessing could be done automatically by sabnzb, since it now knows which par2 to use

i know a lot of ppl would welcome this feature very much, i hope it´s possible to implement, so thx in advance

First of all, if you need to assemble posts in this way, then maybe SABnzbd isn't the right solution for you.
It was always meant as an automation tool.
BTW: it is already possible to supply an extra NZB in the Retry-from-History dialog.
If you download just the RAR files and then hit a CRC error, you can add the NZB containing the par2 files in the Retry.

Also it's not very hard to paste the content of one NZB into another one using a text editor.

>It was always meant as an automation tool.
that´s why i use and highly appreciate sabnzb and to further enhance the automation capabilities of that tool for a variety of posting methods, i believe this feature make sense/would help some ppl reducing their manual workload with usenet

>BTW: it is already possible to supply an extra NZB in the Retry-from-History dialog.
>If you download just the RAR files and then hit a CRC error, you can add the NZB containing the par2 files in the Retry.
and that would be nice to be able to set beforehand, wehn you start a dl and you already know you will need that feature
the use of specifying a seperate par2 is not always the need to repair something, more often than not it´s needed to rename obfuscated filenames to be able to extract the data

>Also it's not very hard to paste the content of one NZB into another one using a text editor.
that´s true, but in these cases it doesn´t work:
the rars are obfuscated/named randomly and encrypted with a pw, the needed par2 to rename/repair is posted in a seperate also encrypted rar
you can´t combine those 2 cause before unraring you would need to rename the files first, but you can´t cause the needed par2 is also in the combined nzb protected by the pw, you get my point?
in these cases it would be a great help to
1. DL the small par2 manually
2. import the full obfuscated/encrypted DL in sabnzb
3. and then tell sab: use this par2 for postprocessing

I'm not sure I want to get down the road of supporting such crazy schemes.
Also from a UI perspective, it's hard to do this right.

I think you can pull it off by using a pre-queue script.
The pre-queue script is called just after the job folder has been created.
Since there is only a single pre-queue script, you'd have to put the par2 files always in the same folder.
Pseudo-code:
- Assemble destination path from fixed "incomplete" path and the job name
- If they exist: copy the par2 files from the source folder to the destination folder
- Return 1 (accepting the job)

alright, thx

Please let me know if it works.
If not, maybe we can work something out.

i started to look into scripts yesterday, never did that before, i posted a thread in the postprocessing forum:
http://forums.sabnzbd.org/viewtopic.php?f=9&t=14127

what i believe i need to finish this are the parameters for the standard postprocessing options of sabnzb (repair and extract/delete)

it´s a different approach than you suggested with a postprocessing script, rather than a preqeue script, but that´s cause i´m basically a noob in that field and i had to work with what i got/know, i´m kinda proud to have come so far lol (yeah i´m THAT sucky when it comes to programming )

now that i know a bit more we could also discuss the preqeue script better if that would be the easier way
btw it makes fun to create a script, kinda feels like a sandbox game

actually this should be quite simple:
after the download and successful rename of the par2 files i guess i would just have to tell sabnzb to retry standard sabnzb postprocessing (delete) without the downloading of course
is there a such a command?

this postprocessing script renames the par2, after that i want to tell sabnzb to retry postprocessing option delete -without downloading again

I still think using a pre-processing script is a better idea.
The point is that adding par2 files later still won't convince SABnzbd to see them as part of a set.
Adding them before downloading, will.

that might be true if the par2 files werent packed into the nzb and renamed .p235
par2cmd doesn´t recognize misnamed files, that´s why i have to rename the .p234 files to par2 after the download and then i can start repairing
another thing i noticed, maybe i did something wrong, when the par2 files are renamed to .par2 they can be read with par2cmd
the files that need repair/renaming are something like this: 4358z7fgeub.456765
so they are misnamed and don´t have the standars .rar extension
par2cmd does not recognize these misnamed files? it reads the par2 and sees that there are additional files but it won´t use a single block of these misnamed but otherwise 100% complete files
if you drag+drop the files into quickpar gui all files are recognized and ready to rename without repairing, so it is just a recognition thingy with par2cmd
if i´m right (meaning i didn´t screw up the par2 parameters) it´s a limitation of par2cmd
is that in active developement so that i could request that on their forum, if yes do you have a link? i already googled but didn´t find anything

At least one par2 file must be properly named.
If you add * as the last parameter, par2 will process all files in the folder.
I'm not sure it will always work.
par2cmdline isn't developed actively, although some people have created faster versions,
the behaviour is much the same.

thx for the * tip

so far so good, the postscript now renames the pars and repairs/renames the obfuscated rars to their original names, ready to extract
is there a more elegant/universal way to link to the par2.exe? like %1 for the job-folder?
icing on the cake would be to extract the password protected rars with rarcmd, how does sabnzb handle the "jobname / password" feature? is there a way to call for that password in a postscript?
if it´s not possible to use that pw in a postscript, the other idea is, that one has to name the nzb exactly like the pw and to call for the "original nzb name" %2 as pw in the script, there could lay potential trouble with some special characters that can´t be part of a filename but can be used in rar as a pw?

in any case thx for your help so far! much appreciated

me2 wrote: is there a more elegant/universal way to link to the par2.exe? like %1 for the job-folder?

Not really.

me2 wrote: is there a way to call for that password in a postscript?

No, because the assumption is that extraction has already been done.
Hence, no need to pass a password.

makes sense, i always seem to search out the special needs

anyway the script finally works, the only thing you have to do is to name the job=password, since %2 original name of the nzb doesn´t work, i guess the original name is filename+extension? not just filename ?

here is the final version of the script:
maybe you have an idea for a failsafe for the last line of the script, deleting the rars is potentially dangerous because there is no function in the script to verify the success of the unrar process, does unrar return a success/error code to use as a failsafe? if so how would you do it?
same goes for the par2 i just realized, deleting those files would be nice for a tidy job folder, but not at the expence of safety/the risk to need to redownload because something got deleted too early

IF Return Code=1 del "*.rar" ELSE echo unraring failed

something like this i presume

if errorlevel 1 echo Failure
if not errorlevel 1 del *.rar

This will prevent deletion when unrar returns an error code 1 or higher.