SABnzbd Forums

Thanks

fakker wrote: Next Time im will try to restart the sabnzbd and see it will work , i will let you know.

It will, and it's the only way...  (already said that above)

Hi,
as far as i can see the incresed timeout for feching (60 sec now) fix the problem
i will let you know if someting change.

fakker

Still occurs with 0.50RC3, exactly the same way it did before...

I think that we need an automatic refresh of stalled requests or at least "reload fetch request" button

All you ask for is already in: retries and finally an entry with retry link in History.

Without more information about how to reproduce this problem,
we can never solve it.

Yesterday I updated to 0.50RC3 and this morning I saw that RSS tried to fetch 4 nzb from NZBMatrix.
The first one was successfully retrieved and it's download has started.
The 3 others where stalled on "trying to fetch NZB from http://nzbmatrix.com/..."
I stopped SABnzbd and relaunch it and then it fetched successfully the 3 others.



How can I give you more infos ?
What are the files and/or screenshots you may need ?

The log files would be useful.
You can get the most recent one from the Connections page.
Or else in the logs directory (see Config->Folders for its location).

Log files don't seem to store more than 24 hours.
Next time it occurs, I'll post the logs immediately...

The log files are a rotating set of 5 files, that will not use more than 5M each.
The most recent one is always sabnzbd.log

i don't think its a timeout problem because for me once it happens no nzb will get downloaded until i restart sabnzbd then it works instantly. If it was a timeout problem wouldn't it still timeout after i restart?

The next release will contain some fixes.
There is currently some weak code that will crash when messages
coming back from nzbmatrix have an unexpected format
(possibly due to temporary connection problems).
That's about what we can do without hard data to reproduce the problem.

Hi,
  I seem to be having the same problem, restarting seems to help get one or 2 of the nzbs which are trying to be fetched in the queue however it gets no where near all of them. I have dumped out everything in the queue a few times but the problem happens again when new posts show in the in the TVnzb rss feed. I this worked fine in all version until I upgraded to version 5 and now it no longer seems tp work. The error the log is showing is:

2010-03-17 16:23:59,605 WARNING: Invalid NZB file 38473.nzb, skipping (reason=syntax error, line=1)
2010-03-17 16:23:59,605 ERROR: Error getting url http://www.tvnzb.com/nzb/38473 (cause= "")

I don't believe the NZB file is invalid as restarting does seem to sometimes fix the problem which would not happen if the file was actually bad. I think I may just have to down grade for now. Hoping there will be a solution in the future.

Thanks

When I type http://www.tvnzb.com/nzb/38473 into my web browser,  I get this answer from tvnzb:
Invalid NZB ID

What do you suppose we do?
SABnzbd expects an NZB and it gets a text with an error message.
SAB's reaction is not very clear, but we're not going to build in specific handling for every site.

I've getting the same problem with tvnzb.com and I think it seems to be a timeout issue, although the nzb id reported in two posts above this was indeed invalid, the nzb urls that are failing to be fetched for me are definitely valid as I end up having to download them to my desktop and then add them that way.

It seems like it's definitely a timeout issue as when trying to download the files manually, it takes about 10 seconds for firefox to even initiate the actual download let alone start transferring any of the file.

TVNZB seems to be getting DDoSed regularly at the moment though so it may only be a temp problem until whatever loser stops fucking about with the site

SABnzbd is very persistent with retries.
However when it receives an invalid NZB file (like one with "Invalid ID" in it),
it gives up because why retry after such a message?
Like I said we're not very happy about implementing
recovery code for specific sites, because there would be no end to it.

I'll see if some generic improvements can be done.