news.software.readers

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.