Articles missing but which files?

[temporary1]

Long time user, love the program, but stumbled into this today. Maybe an obvious question, but i cant seem to find the answer...
Create an nzb of many files (~20) into one nzb and put into the download queue, all seems to go ok, but at the end sabnzbd reports "5 articles malformed, 9 articles missing" (for example)... ok the poster hasnt been helpful with no pars to fix anything, but of the 20 files in the set, *which files* had the missing articles?
I cant seem to find how to get sabnzbd to tell me where the errors are. At least some have to be ok, 14 missing articles in 20 files, and maybe its just one of the files that was bad so most are good. But is there any way to tell rather than having to go through everything from beginning to end to find the glitches?
I've looked at the log and cant make good sense out of it. It lists when articles fail (430?) but i see it usually falls over to the backup servers. How to tell when it really failed on all servers, and which file?

Thanks heaps for any help
Windows XP installer, sab0.6.15 (edit:plush skin)

[sander]

I don't know whether it is OK or wise to put multiple files / downloads into onze NZB. In my expierence this certainly does not work for movies etc. And your own question point to another problem that is causes.

Anyway, back to your question: Yes you can, but my answer is fairly technical.

You need the article number that failed. You can get that from the sabnzbd.log and possibly other locations in SAB.
And you need the .NZB which you used for that download.
Then it's quite easy: find the article number in the .NZB, then move up in the .NZB to the line starting with "<file ...". In that line, the part "subject=" will tell the file name. You can use a text editor to look at the .NZB, or grep. See below.

Example with grep (so on Linux or OSX):

Let's say the artilce with ID '[email protected]' is missing from the Ubuntu.Desktop.10.04LTS.x64-LiNUX.nzb. The command to find the file is then:

Code: Select all

sander@R540:~/Downloads$ grep -B1000 -e '[email protected]' Ubuntu.Desktop.10.04LTS.x64-LiNUX.nzb | grep -i '<file' | tail -1

<file poster="linuxman" date="1327401397" subject="Ubuntu.Desktop.10.04LTS.x64-LiNUX [11/23] - "ub10ltd6.r09" yEnc (1/69)">

sander@R540:~/Downloads$ 

So the article belongs to the file ending with "b10ltd6.r09"

EDIT:

@" How to tell when it really failed on all servers": my sabnzd.log says "[decoder:194] .... missing from all servers, discarding" for really missing articles. I must say I have "+debug" on, so I'm not sure if SAB always has that line for really missing articles.

[shypike]

The number of articles listed in History is the number that
is not available on any server.

The reason why we don't flag individual files as damaged is that
often it is not helpful.
Most posts are RAR files which will be unpacked later.
Damaged RAR files are not useful no matter how little was damaged.
Also, the NZB might be incomplete, making guessing file quality imposssibe.
BTW: many non-packed downloads do have an SFV which will signal incorrect files.

[temporary1]

@Sander: Thanks. this gave me the answers i wanted. Although i couldnt get the grep to work on windows (even though grep and tail are installed, and i've used them- a long time ago...) I found the files manually in notepad++. i guess the piping is different between os's

@shypike: i understand. this is the first time in over 3 years of using sab i've wanted this info, but non-the-less, it would be nice to have the damaged files flagged by name. I would have thought that sab at the time would know on what file the error was thrown and therefore logging it shouldn't be too hard to implement. Worst case scenario is that when you have a group of files with no checksums/pars/sfv/rar etc you know what files you need to re-chase from other sources. but i am not a programmer

perhaps unwise as evident from this lesson, i do find myself often creating a compilation of files in one nzb for the queue, as doing a select all and save does make a lot more sense than 20+ individual click and save events and 20 nzbs etc... for non-parity (etc) checked files this is a scenario where logging the error by filename in the nzb makes sense (to me at least!)

edit: also- as i was reading elsewhere (possibly regarding 0.7 experimental features) if a non-packed no-par set does throw an error it would be a reasonable feature request to at least pause on error rather than continue to download a known corrupted file with no hope of repair.

thanks to all for your help and keep up the sab goodness