Unuzable nzb/Failed URL is actually misleading for a "Wait x" common API msg
Posted: March 24th, 2011, 10:25 am
sabnzbd+ fills history with one hundred "URL Fetching failed: Unuzable nzb file". Visiting the URL you see it actually is one of your search providers telling you your "API daily/hourly limit is reached, try again later".
- Deleting this items from history would confuse the nzb search program (like Sick Beard for example, which thinks the download was snatched)
- Most people won't look at the URL. Will simply delete, creating unnecessary search traffic to all news search providers again, while the nzb was perfectly good if the user would wait a little before trying again.
- Even trying again can be complicated. You have to manually click "try again" for many nzbs in your history. If they bounce back, it gets to a point in which you can't distinguish what has been tried again and what has not.
Someone smart at sabnzbd+ development must think of a better solution to this case and better management of the "try again".
How about this:
- The failed downloads / nzbs are referenced in the history as "API restriction" if the server response string contains "API", instead of "Unusable nzb or Failed URL", etc which are misleading.
- A list of "API Restricted" nzbs is created, like the one for "Orphaned" dloads.
- The list shows:
[More than 1 hour ago]
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
[One day ago]
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
[One week ago] -
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
Anyway, its just a suggestion. You can probably imagine better ways to do it.
Regards,
- Deleting this items from history would confuse the nzb search program (like Sick Beard for example, which thinks the download was snatched)
- Most people won't look at the URL. Will simply delete, creating unnecessary search traffic to all news search providers again, while the nzb was perfectly good if the user would wait a little before trying again.
- Even trying again can be complicated. You have to manually click "try again" for many nzbs in your history. If they bounce back, it gets to a point in which you can't distinguish what has been tried again and what has not.
Someone smart at sabnzbd+ development must think of a better solution to this case and better management of the "try again".
How about this:
- The failed downloads / nzbs are referenced in the history as "API restriction" if the server response string contains "API", instead of "Unusable nzb or Failed URL", etc which are misleading.
- A list of "API Restricted" nzbs is created, like the one for "Orphaned" dloads.
- The list shows:
[More than 1 hour ago]
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
[One day ago]
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
[One week ago] -
nzb1 - date/time
nzb2 - date/time
nzbn - date/time
Anyway, its just a suggestion. You can probably imagine better ways to do it.
Regards,