Support Forum

Use case being NZBs that were automatically added for example by parsing an RSS file and are stupidly named so you would like to know if it is something you actually want...

Might in fact be NZB file related as it has not happened in the past 16 hours... I'll try to see if I can get debug information next time I come across it. Thanks!

Many NZBs contain an nfo. It would be really useful - and likely reasonably straight forward to implement - if sabnzbd could offer a link in the queue that would download the nfo immediately (IOW, as the very next article that is downloaded) and send it to the browser. Or maybe even download the nfo...

I would see thread crashes on the console right? I have not noticed any such thing yet... Debug output is hard to capture at full wirespeed...

This is a weird behavior I'm seeing with 0.4.6 (I cannot remember having it seen before but I have not used all of the 0.4.X releases either). Basically, I have allocated a rather big chunk of RAM (round 200MB) to reduce disk trashing which used to work quite nicely (download 1 part to buffer, write...

They are already in your nzb backup dir why do you want that?

Well they would be, if that was active by default. I forgot to set it up. Exporting the queue would solve that issue, I guess. Or I might just wait until it is empty

Great, keep up the good work!

Exporting the queue into individual NZB files would be another great feature but by far not as important (mainly useful for upgrades I guess)

I wanted to discuss a possible speed up with regard to PAR2 verify. How about doing it immediately after assembling a file? That way, you can most likely load it straight from the disk cache, saving a lot disk trashing. Then sabnzbd can keep track of how many blocks it needs (possibly even giving up...