news.software.readers

Reginald Perrin wrote in news:$
@pd7urf2no:

> usablevirus wrote in
news:Xns9A5718190F12Eusablevirus@
> :
>
>> Reginald Perrin scribbled:
>>
>>> Using the latest test Xnews (aka 0 and 200)
with
>>> XnewsQueue (latest), the latter program does not work using
"Archive"
>>> as the "Queue", but it does work with "_queue" as the "Queue".
>>>
>>> Sometimes an entire binary downloads perfectly using this method,
but
>>> sometimes Xnews divides a target .rar file into two or three parts
>>> with _0 and _0_0 appended to the filename. The sum in bytes of
these
>>> parts is about the same as the length of the .rar, but QuickPar 091
>>> reveals that about half of it is garbage. For example, say the .rar
>>> is 15 MB containing 65 parts. Xnews will (sometimes) produce three
>>> files, totalling about 15 MB, but QuickPar reveals that only 31 of
the
>>> 65 parts are correct.
>>>
>>> It appears that XNews is mangling the decode, but only from the
_queue
>>> folder, never from a regular folder. This is repeatable
(downloading
>>> from the same _queue produces the same mangle; Xnews never pauses to
>>> say that a particular part is not found). At first I thought it
might
>>> be a problem with QuickPar. However, I was able to make perfect
.rar
>>> files from the same news server, using the same .nzb file, same IP,
>>> but with the Grabit program. Unfortunately, there are things that
>>> Xnews can do but Grabit can't (AFAIK).
>>>
>>> There is a cryptic remark at:
>>> /test/
>>>
>>> "200:
>>>
>>> o more queue crazinesses fixed. The wiser among you may want to sit
>>> out a few rounds :)"
>>>
>>> It's now a year and a half later and there are rumors that this is
the
>>> last ever version of Xnews.
>>>
>>> Is this a known issue? Is there a version of Xnews that does not
>>> suffer this problem?
>>>
>>> Thanks.
>>>
>>
>> I have noticed this problem as well. it appears that xnewsqueue does
>> not number the segments in their appropiate order. what I do when
>> using xnewsqueue is instead of decoding, save the segments and use an
>> external decoder for decoding.
>
> Looking further, I see that the .nzb file of a binary that downloaded
> perfectly via XnewsQueue and Xnews was in order. In other words,
> within each the "number"s went in order from 1 to [max]. In
> a binary whose download failed, the segments which failed had their
> numbers in no particular order. So an alternative solution would be
> a little utility to put the .nzb into canonical order before feeding
> it to XNewsQueue.
>
> Thanks again, usablevirus.

Give Snooze a try on those 'bad' nzbs -