SABnzbd Forums

Version: 0.7.3
OS: OSX Leopard (PPC)
Install-type: OSx .app
Skin (if applicable): Default
Firewall Software: None
Are you using IPV6? no
Is the issue reproducible? Presumably?

I had an issue where a site's API was giving me empty NZBs for my RSS feed, so SABnzbd was waiting to retry etc. and I assume those files would not have been classed as duplicates if they eventually downloaded correctly.

As this was going on for some time I deleted the failing downloads, created a new API key (as advised by the site), updated my feed, and proceeded to download the new RSS feed: they downloaded correctly but they were all marked as duplicates.

In a sense, this makes sense. They are completely new copies of the downloads. However, as the original versions were empty NZB files, I feel that the correctly downloaded versions should not be classed as a duplicates (i.e. delete the empty NZB file from the backups folder as well as retrying?).

In the case where a failing download is still in the queue and a working download is added, I'm guessing this would result in copy which is failing being marked as a duplicate when it tries to download again, which would also be a more desired result?

You are right.
Registering the empty NZB is an error.
Checking the code, I see that the backup (the basis for duplicate checking) is done before the error is detected.
Will be fixed in the next release.

However, a truly empty NZB file will not be backed up.
SABnzbd must have received a partial NZB, which is a very unusual.

Thanks.

My mention of backup files was only an assumption. If this sequence of events can occur without any empty file(s) being saved as in the backup folder then I doubt that part occurred.

I see now that you're talking about RSS feeds.
For this case there's a deeper issue.
Once the NZB URL is retrieved from the feed and sent to the queue,
the item is registered as a downloaded RSS item.
The assumption is that the NZB will eventually get downloaded and normally it is.
If you subsequently delete the NZB retrieval attempt, SABnzbd will refuse
to download another NZB with exactly the same title.
It would become very complicated to cater for your specific scenario.
The work-around in this case would be to delete the feed and define a new one.
BTW: the "aborted empty file" scenario causing an incorrect backup file is not applicable here.

My updated feed downloaded the NZB files, it was that they were paused as duplicates.
If that's fixable then huzzah, if it's the deeper issue then I understand. Hopefully it's a rare circumstance either way.

When you remove the feed, all the stored names will be removed too.
Just redefining the URL feed will keep the names.
The reason is that people sometimes tweak the URL for other reasons and then
it wouldn't make sense to forget the names.