NZBs are queued but do not download

[guest]

I've recently (in the last few days) seen NZBs get as far as being queued, but not downloaded. I had thought it was down to my ISP blocking the connection (my peak usage got too high) but that ought to have been reset by now.

I see this in the main output window:

Parsed: 22 files (543 posts), 192.7MB
Queued: 192.7MB
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[Total] 0.0KB/s, 192 MB queued, ETA: 00:00:00

...and a lot of this (repeated over and over) in the debug log:

2008-05-02 10:57:45,034 easynews[0] getting GROUP:  alt.binaries.tv
2008-05-02 10:57:45,132 easynews[7] got GROUP: alt.binaries.tv
2008-05-02 10:57:45,138 easynews[7] getting GROUP:  alt.binaries.tv
2008-05-02 10:57:45,145 easynews[6] got GROUP: alt.binaries.tv
2008-05-02 10:57:45,151 easynews[6] getting GROUP:  alt.binaries.tv
2008-05-02 10:57:45,643 easynews[5] got GROUP: alt.binaries.tv
2008-05-02 10:57:45,648 easynews[5] getting GROUP:  alt.binaries.tv
2008-05-02 10:57:45,655 easynews[1] got GROUP: alt.binaries.tv
2008-05-02 10:57:45,682 easynews[1] getting GROUP:  alt.binaries.tv
2008-05-02 10:57:45,779 easynews[3] got GROUP: alt.binaries.tv
2008-05-02 10:57:45,784 easynews[3] getting GROUP:  alt.binaries.tv

I've just upgraded to 0.13 from 0.10 to see if that helps, but the situation is the same. I've tried this with SSL (both stunnel and the built-in support) and without. The possibility remains that my ISP is still being a pain, but I wondered if there was any other likely explanation.

[guest]

Replying to guest:

I had thought it was down to my ISP blocking the connection (my peak usage got too high) but that ought to have been reset by now.

Apparently my ISP's restriction is not due to be lifted for a week, so that could still be a factor. Would a restriction on binary newsgroup access explain the above symptoms?

[guest]

i've had this exact same problem, but it was due to (bad) nzbs from tvnzb

i have UNS, but otherwise the debug log is the same, got a.b.tv getting a.b.tv over and over again

[guest]

Replying to guest:

i've had this exact same problem, but it was due to (bad) nzbs from tvnzb

I've tried again with an NZB generated by Easynews (my news provider), and I got the same problem. However, I tried another NZB from Easynews with a different group, and it's working. So it seems to be a.b.tv-specific! (I wonder if my ISP's traffic-shaping looks at the particular group.)

i have UNS, but otherwise the debug log is the same, got a.b.tv getting a.b.tv over and over again

I'd be interested to know what those log entries mean, ie why they're there and there's nothing else. If it's a result of ISP intervention, perhaps it's something that can be spotted and a warning emitted.

[guest]

I encountered the same thing, the problem here is extra space in the group

2008-05-02 10:57:45,779 easynews[3] got GROUP: alt.binaries.tv 2008-05-02 10:57:45,784 easynews[3] getting GROUP: alt.binaries.tv

these are actually: (notice the '|' I added for debugging purpose.)

2008-05-02 10:57:45,779 easynews[3] got GROUP: |alt.binaries.tv| 2008-05-02 10:57:45,784 easynews[3] getting GROUP: | alt.binaries.tv|

I did a quick hack to get around this issue:

vi Hellanzb/NZBLeecher/Protocol.py, search for 'getting GROUP', and strip the space in group before that:

if not self.factory.skipGroupCmd:

# Change group for group in self.currentSegment.nzbFile.groups:

+ group = group.strip()

# NOTE: we could get away with activating only one of the groups instead # of all if group not in self.activeGroups and group not in self.failedGroups:

debug(str(self) + ' getting GROUP: |' + group + '|') self.fetchGroup(group) return

This is by no means a proper fix, but should get you around this stuck issue. Hope this helps..

Yifang

[guest]

Oops, the code above didn't come out right

        if not self.factory.skipGroupCmd:
            # Change group
            for group in self.currentSegment.nzbFile.groups:

+                group = group.strip()
                # NOTE: we could get away with activating only one of the groups instead
                # of all
                if group not in self.activeGroups and group not in self.failedGroups:
                    debug(str(self) + ' getting GROUP: |' + group + '|')
                    self.fetchGroup(group)
                    return

{{{

}}}

[guest]

Replying to guest:

I encountered the same thing, the problem here is extra space in the group ... This is by no means a proper fix, but should get you around this stuck issue. Hope this helps..

Thanks for the help! My problem seems to have resolved itself at the moment, so I won't make a change just yet (else I won't know if it fixed anything in this case). I'll apply the above code if it goes wrong again.

Cheers!

[guest]

It went wrong again this morning and I was able to verify that it's the same problem as Yifang reported. Thanks for the patch! I've fixed it and everything's going swimmingly.

Perhaps that patch could be applied to the main codebase?

Cheers.

[guest]

Thanks for the patch, it works well now :-)

[guest]

Thanks for the patch, if/when will this be added to the code?

[guest]

Wouldn't this be better handled by changing the nzb parser?

in NZBParser.py change

        elif name == 'group':
            newsgroup = self.parseUnicode(''.join(self.chars))
            self.file.groups.append(newsgroup)

with

        elif name == 'group':
            newsgroup = self.parseUnicode(''.join(self.chars)).strip()
            self.file.groups.append(newsgroup)

So glad I got to the bottom of this :)

Cheers!

[guest]

Replying to guest:

Wouldn't this be better handled by changing the nzb parser?

Agree! My original patch was just a quick work around :) Is pjenvey still around this project? I haven't notice anything from him recently.

Yifang

[guest]

I ran into the same problem, although the patch didn't help me. My issue seems to be the dash in the newsgroup name. When I deleted all of these lines in my NZB the problem was fixed:

<group>alt.binaries.U-4all</group>

[guest]

Info from my Log:

2008-07-05 12:17:19,987 giganews[3] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:19,989 giganews[3] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,006 giganews[1] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:20,008 giganews[1] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,010 giganews[0] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:20,013 giganews[0] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,016 giganews[4] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:20,018 giganews[4] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,020 giganews[2] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:20,023 giganews[2] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,029 giganews[3] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:20,031 giganews[3] getting GROUP: alt.binaries.U-4all 2008-07-05 12:17:20,052 giganews[1] got GROUP: alt.binaries.u-4all

[guest]

Replying to guest:

Info from my Log: 2008-07-05 12:17:19,987 giganews[3] got GROUP: alt.binaries.u-4all 2008-07-05 12:17:19,989 giganews[3] getting GROUP: alt.binaries.U-4all

Notice the difference of the case for the 'u', I think the group name is case sensitive (at least from a simple test with some nntp servers I can reach, it is). So I would say the nzb is invalid.

[guest]

See  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495518 for the debian bugreport, with a different patch (which fixes the case sensitivity issue as well).

[guest]

for the record: gentoo bug report:  http://bugs.gentoo.org/show_bug.cgi?id=224945

Proper fix:

diff -r 92936345c3f5 Hellanzb/NZBLeecher/Protocol.py
--- a/Hellanzb/NZBLeecher/Protocol.py	Mon Aug 18 10:38:55 2008 +0200
+++ b/Hellanzb/NZBLeecher/Protocol.py	Mon Aug 18 11:34:20 2008 +0200
@@ -655,7 +655,7 @@
         reactor.callInThread(decode, segment)
 
     def gotGroup(self, group):
-        group = group[3]
+        group = self.gettingGroup
         self.activeGroups.append(group)
         self.gettingGroup = None
         debug(str(self) + ' got GROUP: ' + group)

[pjenvey]

fixed in r1089, thanks!