RSS feeds stuck in "Trying to fetch NZB..."

[Jumbs]

Running Ubuntu build, 0.7.17RC1.
Since the update, rss feeds and nzbs sent using sabconnect++ plug in get stuck at:

"Trying to fetch NZB from http-++...."

Sometimes a restart of the service fixes them, but not always. And the restart takes a long time.

Has anyone else run into this?

[mptpro]

Yup. Same problem here. And it happens when I initiate a direct "send" from a site to Sabnzbd. If I download the nzb file first, then upload to sabnzb it works fine.

[shypike]

I'll check.

[shypike]

Are you sure this isn't happening with older releases too?
I cannot find a problem when I test it.
Does the server do proper URL quoting?
Which server are you using?

[ErikBrown]

Same thing for me. I installed 0.7.17RC1 with smpl skin on Windows XP last night and this morning I found two issues. I see several NZBs that it is trying to fetch. Also it showed that it was downloading continuously on the same speed of 869 KB/s (normally this fluctuates) but it was not actually downloading. I could still refresh the screen so SABnzbd was not completely hanging. Restarting did not work and shutdown also not. Taskmanager showed that SABnzbd was running but used zero CPU time. I do not use a plugin for the NZBs but RSS within SABnzbd.

I have not seen this with the previous versions. All the NZBs that it could not fetch were from nzb.su and their site mentions something about a DNS change so maybe this is triggering it. I use ssl.hitnews.com for downloads. I am not sure what you mean with proper url quoting but I noticed that the NZBs that it is trying to fetch show https-++ at the start of the url and not https://

[shypike]

I am not sure what you mean with proper url quoting but I noticed that the NZBs that it is trying to fetch show https-++ at the start of the url and not https://

That's a potential issue for sites that use SABnzbd's API.
They need to embed their URL in a URL for SABnzbd's API otherwise special characters their own URL get damaged.
But it is also possible that the problem is a side effect of changes in SABnzbd.
That's why I asked for more detailed information.
I'll do some more testing.

[shypike]

What I do see now is that when there's a whole bunch of URLs in the queue,
the names are indeed damaged like you describe.
However, with the indexers I'm using the NZB fetches are still successful. So only optical damage.
The latter I can fix easily (problem was introduced when trying to process embedded passwords better).

Does the log file actually say that SABnzbd is trying to retrieve "http-++" etc.?

[ErikBrown]

Since this morning I have not seen any failed NZBs. The log did not show anything for the period when the issue occurred. I have enabled debug logging now and I will let you know what is shown when I see the issue again.

[shypike]

It could be the coincidence of a failing indexing site and the garbled display.
I fixed the latter in the code now.

[shypike]

It could be the coincidence of a failing indexing site and the garbled display.
I fixed the latter in the code now.

I would appreciate to hear of your further experience.

[ErikBrown]

The logs are emailed. One more additional piece of information. I tried to restart Windows but clicking on the start button did not cause anything to happen. But when I pressed control alt delete and ended the SABnzbd process in task manager, the start menu appeared and I could restart Windows.

Before I restarted, no NZB was sucessfull, all 10 showed that they were being fetched. After rebooting, all 10 NZBs are now showing up normal (NZB downloaded and ready to download the actual files)

[Jumbs]

I use usenet-crawler.com and nzbindex.nl for RSS, along with sabconnect++ for ad hoc.

My computer has been off a while, but next time i get a feed trigger, i will look at the logs.

[Jumbs]

Here is the sanitized log for a failure. It just sat as Trying to fetch NZB from https-++www..... until a forced serice restart.
I removed any personalized details from the urls, however they still work

Code: Select all

2014-02-10 22:35:58,091::INFO::[rss:509] Starting scheduled RSS read-out for "[Show]"
2014-02-10 22:35:59,103::INFO::[rss:614] Adding https://www.usenet-crawler.com/getnzb/c66ef39d1f0e6c5ffa6d683d592b40af.nzb&i=180745&r=fd50a8e2d5c7ec6ed4cb4fa58ff661f2 ([Show].S05E47.HDTV.x264-W4F) to queue
2014-02-10 22:35:59,103::INFO::[__init__:511] Fetching https://www.usenet-crawler.com/getnzb/c66ef39d1f0e6c5ffa6d683d592b40af.nzb&i=180745&r=fd50a8e2d5c7ec6ed4cb4fa58ff661f2
2014-02-10 22:35:59,103::INFO::[nzbqueue:211] Saving queue
2014-02-10 22:35:59,104::INFO::[__init__:917] Saving data for queue9.sab in /home/[Me]/.sabnzbd/admin/queue9.sab
2014-02-10 22:35:59,609::INFO::[rss:614] Adding https://www.usenet-crawler.com/getnzb/3fb27bf082f68c0762f0a525b7d8c221.nzb&i=180745&r=fd50a8e2d5c7ec6ed4cb4fa58ff661f2 ([Show].S05E47.720p.HDTV.x264-W4F) to queue
2014-02-10 22:35:59,609::INFO::[__init__:511] Fetching https://www.usenet-crawler.com/getnzb/3fb27bf082f68c0762f0a525b7d8c221.nzb&i=180745&r=fd50a8e2d5c7ec6ed4cb4fa58ff661f2
2014-02-10 22:35:59,609::INFO::[nzbqueue:211] Saving queue

[shypike]

The https-++www style is only happening on the display, that's not what's being sent to the indexer.
As you can see in the log lines.
Of course it is possible that something goes wrong when getting NZBs from the indexer.
There are two parties involved and something can go wrong at both sides; it's not always easy to see on which side.

[Jumbs]

I also note the freezing of the display ErikBrown noted along with a new nzb link being queued.

Is it possible something near the final step of nzb resolution freezes parts of the system, but is all restored when rebooted.