NNTPGrab

Ik ga even in het Nederlands reageren omdat de werking daarmee wat makkelijker uit te leggen valt (in case somebody wants an English translation, please let me know).

In de volgende situaties gaat NNTPGrab de huidige toestand van de download queue opslaan op de harde schijf:
- Na het importeren van een NZB
- Indien een bestand uit de download queue herstart wordt (alleen in de GTK frontend)
- Indien een bestand verplaatst wordt binnen de download queue (alleen in de GTK frontend)
- Indien een bestand uit de download queue verwijderd wordt (alleen in de GTK frontend)
- Na het uitvoeren van een PAR2 verificatie/reparatie (treedt ook op indien een collectie geen PAR2 bestanden bevat, in dat geval treedt het op nadat een collectie volledig gedownload en gedecodeerd is)
- Na het automatisch uitpakken van de bestanden binnen een collectie
- Na het decoderen van een bestand (maximaal eens per 60 seconden)

Als de download queue opgeslagen moet worden, dan zal eerst gecontroleerd worden of er geen andere schrijfactie nog actief was.
Daarmee wordt voorkomen dat twee deel-processen tegelijkertijd de huidige toestand van de download queue proberen op te slaan (en er mogelijk corruptie ontstaat).

Tijdens het opslaan wordt de huidige toestand eerst opgeslagen in een tijdelijk bestand genaamd download_queue.db.new.
Pas als de complete toestand succesvol is weggeschreven naar dit tijdelijke bestand, dan zal het originele bestand, download_queue.db,
verwijderd worden en zal het tijdelijke bestand download_queue.db.new hernoemd worden naar download_queue.db.
Hiermee wordt voorkomen dat bij een volle schijf het originele bestand mogelijk verloren gaat of corrupt raakt.

In NNTPGrab 0.7.0 en NNTPGrab 0.7.1 zat een nog een bug waardoor het voor kon komen dat de 'hernoemen'-stap kon mislukken op willekeurige moment.
Deze zou met NNTPGrab 0.7.2 verholpen moeten zijn (https://bugzilla.gnome.org/show_bug.cgi?id=674214)

Je gaf aan dat soms 'verkeerde' bestanden gedownload worden. Als in het programma zelf wel normale collecties en onderwerpen vermeld staan lijkt me dit geen corruptie.
Ik vermoed eerder dat er iets op je usenet server gebeurd is waardoor sommige berichten opeens niet meer op hun oude message-id te vinden zijn.
Dit zou bijvoorbeeld kunnen komen wanneer een usenet provider gevraagd wordt om bepaalde berichten te 'verwijderen'. Afhankelijk van de manier
waarop ze dit 'verwijderen' toepassen zou het gedrag dat je beschrijft in principe mogelijk daardoor veroorzaakt kunnen worden.

Mocht het probleem omtrent de lege download queue weer optreden zou je eens kunnen kijken of je het download_queue.db.new bestand ergens kan vinden

Alguno,

Thanks for the info.
First a correction of my initial post. Just found that the following is not correct:
This time I did see strange files beeing downloaded that where not part of the items in the download queue.

The parts that ended up in other download directories are from other items in my download queue.
More detailed. From one download I found 7 parts in the wrong directory, and from a second download I found 1 part in a wrong directory, and 4 parts in another wrong directory.

I didn't found download_queue.db.new back on the pc, but the pc was rebooted a number of times already.

I'm using QT (nntpgrab_gui.exe and nntpgrab_server_qt.exe).
Decoding was happening every few minutes.

Seen the same issue again.
Must have appened somewhere between 8-April 21:39(last file written) and today (12-April).
Looked for download_queue.db.new, but didn't find it.

Nog even alle opties bekeken waarbij de download queue database overschreven wordt, of ik er nog een kon uitsluiten, en heb nu PAR2 verificatie uit gezet.
- Na het importeren van een NZB [ten tijde van probleem geen NZB's geimporteetd]
- Indien een bestand uit de download queue herstart wordt (alleen in de GTK frontend) [QT versie in gebruik]
- Indien een bestand verplaatst wordt binnen de download queue (alleen in de GTK frontend) [QT versie in gebruik]
- Indien een bestand uit de download queue verwijderd wordt (alleen in de GTK frontend) [QT versie in gebruik]
- Na het uitvoeren van een PAR2 verificatie/reparatie (treedt ook op indien een collectie geen PAR2 bestanden bevat, in dat geval treedt het op nadat een collectie volledig gedownload en gedecodeerd is) [heb nu deze optie uit gezet]
- Na het automatisch uitpakken van de bestanden binnen een collectie [is niet geselecteerd]
- Na het decoderen van een bestand (maximaal eens per 60 seconden)

Heb dit probleem zojuist nog eens gehad.
Dit maal niet na een reboot.

Sequence of events:
-Download gestopt wegens hdd vol (na langere tijd de pop-up window pas gesloten)
-Ruimte vrij gemaakt
-unpause download queue. Queue leek nog gevuld, maar download starte niet.
-Quite NNTPGrab, restart NNTPGrab >> download queue leeg.

Heb dit probleem zojuist nog eens gehad.
Dit maal niet na een reboot.

Sequence of events:
-Download gestopt wegens hdd vol (na langere tijd de pop-up window pas gesloten)
-Ruimte vrij gemaakt
-unpause download queue. Queue leek nog gevuld, maar download starte niet.
-Quite NNTPGrab, restart NNTPGrab >> download queue leeg.

Selecties in Configuration > Postprocessing: All unselected.