---

Når man henter en "multipart binary" med Xnews, og en af delene
ikke er tilgængelig, laver Xnews en fil, hvor "__error_part_11"
(f.eks.) tilføjes til filnavnet, og alle dele sættes så i kø
igen. Men når det bliver den fejlede downloads tur, begynder
Xnews gudhjælpemig *helt* forfra (fra 1. del), i stedet for at
begynde fra hvor den fejlede (i det her tilfælde fra 11. del).

Det er korrekt observeret, ikke? Kan der gøres noget ved det?
Hvis ikke, så vil jeg gerne høre om I kender en anden nyheds-
læser der kan gøre det bedre end Xnews.

---

Lars Stokholm wrote:

> Det er korrekt observeret, ikke?

Hmm, tilsyneladende ikke, i manualen står der under "A few words
on smart decoding":

| Starting with version Y2K-SE, Xnews can resume an interrupted
| multi-part decode from the last successfully decoded part (as
| opposed to doing the whole thing over). It does this by saving
| some state information about the decoded file in *.ini files
| in the temp\ folder. If you're decoding a multipart file and
| it gets interrupted, you'll see the name of the decoded file
| changed into
|
| filename__error_part_X.ext
|
| Don't delete or rename this file. You'll also see some *.ini
| files in the temp\ folder. Don't delete those either. Go back
| and queue the file you were decoding, starting from part X.
| Example: if the file is in 20 parts and X is 14, you should
| queue parts 14-20. Click decode and Xnews should pick up where
| it left off. (Actually, you don't need to queue just parts
| 14-20; you can queue the whole thing normally and Xnews should
| figure it out, but the first way may be safer.)
|
| If this feature gives you problems, you can disable it by
| setting Xnews.ini [Misc] UseSmartDecode=0

Så fatter jeg bare ikke hvorfor det ikke virker her. Hvorfor
findes der ikke nogen ordenlig binær nyhedslæser?