I'm selecting and nzb to download. (1) The NZb is put into the hdd folder. Sabnzbd imports the files into the queue, but does not always delete the file from the hdd folder, so 120 seconds later (my time import setting) imports the file again and again... Generally though it does work, it is just the odd occasion.
(2) I've had a productive day and ther are around 25 NZB compilations in the queue, As the queue fills up with the jobs above (somewhere around 30 nzb files), when the first of the repetative jobs hits posiition 0, the whole queue stands still and no more downloads, not even after multiple restarts or reboots will it download.
(2a) all the other corrupt copied jobs may or may not have the same position number as each other (rather than increments), or from top to bottom once these entries are found the numbers can be out of sequence with the rest of the working entries I currently have positions 0 to 7, then a jump to the multiple corrupt ones all number 13. There is no number 8, 9, 10, 11, 12, but these could relate to the number of duplicate entries as it does on my queue list, but also may be a red herring.
(2b) these corrupt files often can not be given new numbers (occasionally can though), but it rarely sticks even if a new position number is chosen, as after a refresh may see it back to the same as it previously was before the change.
(2c) generally these jobs can not be deleted, but think - I deleted 2 about of about 9 after MUCH trying, but eventually they stick.
As soon as another normal job Sabnzbd starts to download again until it get to a duff nzb entry again.
The workaround was to sort the queue by pressing "Sort Age" etc. as it is the only way to move the entry from top spot. Once position 0 is occupied by a non corrupt entry, you can select the other working entries as position 0 and this will push the corrupt queue entry down. Sometimes you are lucky and are able replace the first corrupt queue entry with a working one, but it is a bit hit and miss. It is more likely to work if you slot a working nzb in the position just above the first corrupt entry.
3. When files are corrupt, it seems par files are not automatically queued for a repair. This may be a command line setting, but I'm not that familiar with this software yet

Otherwise a good job
