SABnzbd Forums

sander wrote: ↑January 22nd, 2021, 3:21 am

KKALnSF wrote: ↑January 22nd, 2021, 3:14 am

sander wrote: ↑January 22nd, 2021, 12:40 am

Can you please send those NZBs to safihre @ sabnzbd.org?

Hi. I did send them .
Subject: Unable to Rename Sample+ file
Wed, Jan 20, 7:10 PM EST(2 days ago)

Yes, two. See my report on those two.

But you showed a picture with 5-10 more problematic NZBs. Can you send them too?

Thanks.

Yes, of course. Does Sab store the NZB files after the download? If not, I'll track down as many as I can from the news server.

KKALnSF wrote: ↑January 22nd, 2021, 3:31 am
Yes, of course. Does Sab store the NZB files after the download? If not, I'll track down as many as I can from the news server.

By default: No. But you can instruct SAB to make a backup of each NZB: http://127.0.0.1:8080/sabnzbd/config/fo ... backup_dir

sander wrote: ↑January 22nd, 2021, 3:41 am

KKALnSF wrote: ↑January 22nd, 2021, 3:31 am
Yes, of course. Does Sab store the NZB files after the download? If not, I'll track down as many as I can from the news server.

By default: No. But you can instruct SAB to make a backup of each NZB: http://127.0.0.1:8080/sabnzbd/config/fo ... backup_dir

I created the backup folder and hit "retry" in Sab on some of the failed downloads. I sent you the files from the backup folder.

As a (ugly) workaround, you can do this:

In SAB, uncheck "Post process only verified jobs" (so ... http://127.0.0.1:8080/sabnzbd/config/sw ... e_postproc )

... and redownload. You will get error messages ("Post-processing was aborted" and "Post Processing Failed for") because of the Sample+ ... but your content is there!

(Unless repair is needed ... then no luck)

There's a bunch of these out there now, and I'm getting these errors as well. I'm sure they're all the same uploader, or maybe some uploading script that has been distributed.

The error occurs with both the latest SAB 3.1.1 and even back to at least 2.3.9, both of which are using linux, however there's no error using the latest SAB on Windows. I have Ignore Samples checked in all instances.

Here's an example NZB:

https://we.tl/t-2nh3jFSkx5

The RAR password is "sab1".

sander wrote: ↑January 22nd, 2021, 4:10 pm As a (ugly) workaround, you can do this:

In SAB, uncheck "Post process only verified jobs" (so ... http://127.0.0.1:8080/sabnzbd/config/sw ... e_postproc )

... and redownload. You will get error messages ("Post-processing was aborted" and "Post Processing Failed for") because of the Sample+ ... but your content is there!

(Unless repair is needed ... then no luck)

I unchecked "Post process only verified jobs" and let it run for a few days. Previously I was at about 90% failure rate, now I'm at 100% success so far.
The process still fails to rename sample+, but the process no longer terminates. Sab seems to be cleaning up the leftover mess, so it's all good at this point.
It even still works after a repair is needed.

If anything changes I'll post again.

Thanks for your help. It is very much appreciated !!

The downside of that setting is that if your download is missing 100% from the servers, it will also show as "succes" even though there are no files..

I could also suggest you turn on "Download all par2 files" instead (!) of the "Post process only verified jobs".
It seems this way par2cmdline is able to fix things.

safihre wrote: ↑January 27th, 2021, 10:50 am I could also suggest you turn on "Download all par2 files" instead (!) of the "Post process only verified jobs".
It seems this way par2cmdline is able to fix things.

I think I tried that early on and it didn't help. I'll try again and see what happens.

When I reenabled"Post process only verified jobs" the problem returned. So, in SAB I unchecked "Post process only verified jobs" and the jobs were able to complete without termination due to the Sample File rename.

Hi.

I am having the exact same problem.

Backstory: I recently moved my sabnzbd installation from a really old version running on a physical ubuntu machine, to a new/current version running under docker container, within a VM. I noticed that I am having a heap of TV episodes (that are fed in via Sickgear) fail, and looking at the logs it's always failing when it's trying to move a sample file.

I have had some time today to actually start investigating the issue. I spun up a fresh Ubuntu 20.10 VM, installed Docker, and installed the latest sabnzbd/sabnzbd image (3.1.1 [99b5a00]) and ran with a completely fresh/default configuration. Using an .nzb file known to fail on my live/production installation, the brand new installation also fails.

Knowing that I had recently upgraded from a really old version of sabnzbd, I then went down the release line using the tags on the official sabnzbd docker images until I found one where the problem did NOT occur. This was sabnzbd/sabnzbd:2.0.0 (2.0.0 [55c4bef]). As soon as I go to the next highest version tag in docker (2.3.0) it starts failing.

I'd ideally not want to pin myself to 2.0.0 (as part of my exercise in migrating from the physical ubuntu machine to docker containers inside of a vm was to increase my ease of upgrade).

This problem also seems to happen with the most recent Windows sabnzbd release too (also 3.1.1 [99b5a00]). Other NZB clients are able to download the contents of these nzb files without issue also.

At this link there is a zip file that contains the logs for the download using both the 3.1.1 version, and the 2.0.0 version (through docker), aswell as the full config for each (with identifiable information stripped) and the example nzb file.
drive . google . com/file/d/1El9WMn_Bxl2eSKydTf3dmriYoQmds5aI/view?usp=sharing

Any help would be greatly appreciated.

I am also experiencing this problem running SABnzbd in Docker on Linux.
Getting more and more failures on nzb files
All with the 'sample+/... cannot be renamed' sub-directory rename/unpack error.



Disabling 'Post process only verified jobs' indeed helps, but that is more a quickwin and not the preferred solution as the actual extraction of the sample in the sub-directory still fails.

Did you have the chance to investigate this problem?

@timmyc Thanks for the NZB; with that I'm able to reproduce on Linux (not on Windows: works on Windows)

Let me try to make a summary. I'll correct this post based on corrections.

This happens IF:
- with par2 from par2repair (read: on Linux) AND
- post needs repair (from par2 files) AND
- post contains "Sample+ aka Sample\ -subdir (which cannot be handled by par2)


Correct?

On my Linux, after SAB failed, I was able to get the post this one:

Preparation:
I Installed wine: "sudo apt-get install wine"
I ran par2j.exe (=Windows multipar) once: "wine /home/sander/git/sabnzbd/win/multipar/par2j.exe". That took some time, and gave some wine messages. The par2j.exe is in SAB's git, but also on https://hp.vector.co.jp/authors/VA021385/

Then:
I instructed SABnzbd to only Download the post
Afterwards, I ran

wine /home/sander/git/sabnzbd/win/multipar/par2j.exe r <blabla>.par2
unrar x blabla.s10e13.hog.heaven.720p.web.h264-blabla.rar

... and ... nice MKV and Sample/...MKV



@timmyc and @luchtmacht does the above manual workaround work for you?

Is the problem that the par2 files were generated with the sample file in the Sample directory but unpacks to the same, that it's not supposed to convert the plus into a slash, or that the client simply can't handle subdirectories? If there is no Sample directory then maybe it would stop failing if it was created before running par2?

@sander - Glad you were able to reproduce in linux. The problem definitely does occur under Windows too though.

Using the most current Windows client (also 3.1.1 [99b5a00]) , that same nzb file fails. Logs below;
pastebin . com/czhhwyjd

The problem with a manual work around is that it is just that, manual. I, like most other people, use Sabnzbd tied in with other microservices to automate the ingestion of content. If I were to have to manually perform those tasks for ~80% of the TV episodes I download, it would defeat the purpose.



I did a little bit more testing. I grabbed the par2 and unrar binaries that are working on the 2.0.0 release container, and put them in my 3.1.1 container and tried to download the nzb again. Still failed. I then rolled back my production Sabnzbd container to use the sabnzbd/sabnzbd:2.0.0 docker image, with my existing configuration file and all my settings, and it works now (I just didn't want to pin myself to an archaic version).

I don't believe this to strictly be a problem with the par2 or unrar binaries themselves, but more something to do with the workflow in Sabnzbd >2.0.0 (I'd likely guess it's something to do with how the file names/paths are passed to the unrar binary to extract the files, and the use of subdirectories causing the failure).

Your example manual work around uses a much more rudimentary unrar command than what Sabnzbd does, but I imagine if the arguments (RE: file name/pathing) were passed to it in the same way that current versions of Sabnzbd pass them, it too is likely to fail, that might be a next step in the investigation/replication. If that is indeed the cause, then the dev team could likely use the information gathered there to resolve this issue in a forthcoming release.

Let me know if I can provide any more information to aide in a resolution here. I generally love Sabnzbd, and detest the idea of having to migrate to an alternative solution, so am invested in a solution to this problem.