NNTPGrab

Deze logging is zeker afkomstig van NNTPGrab 0.6.90 onder Windows?
Zou je eens kunnen proberen om logging te verzamelen met maar 1 server en 1 verbinding geconfigureerd?
Dan wordt de logging namelijk niet vervuild door parallelle verbindingspogingen en wordt het hopelijk
wat duidelijker waar de oorzaak zicht bevindt.

De nieuwste beta wordt overigens op heel korte termijn verwacht :)

Alguno,

Inderdaad met 0.6.90 onder Win7-64.

De logging in mijn eerste post is van alleen reader.ipv6.xsnews.nl met maar 1 verbinding.
Zal het ook nog eens met m'n Linux pc proberen.

Ik wacht met spanning af op de nieuwe beta...

Alguno,

Met m'n linux pc gaat het (nu) wel goed.

Hier de logging met alleen reader.ipv6.xsnews.nl enabled en maar 1 verbinding:
NNTPGrab Core 1 download_thread_func: initializing
NNTPGrab Core 1 download_thread_func: Prepared a list for maximum 1 connections
NNTPGrab Core 1 download_queue_get_next_part_to_download for server_id 2
NNTPGrab Core 5 Returned part 50 from file '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' from collection 'vild-discovery.channel.ultimate.journeys.philippines'
NNTPGrab Core 5 proxies⁰ = direct://
NNTPGrab Core 5 No proxy required for 'reader.ipv6.xsnews.nl'
NNTPGrab Core 1 nntpconnection_connect_to_server SUCCEEDED, conn_id = 1, poll_fd = 16
NNTPGrab Core 5 Part 50 of file 'vild-discovery.channel.ultimate.journeys.philippines' from collection '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' was downloaded successfully
NNTPGrab Core 1 download_queue_get_next_part_to_download for server_id 2
NNTPGrab Core 5 Returned part 88 from file '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' from collection 'vild-discovery.channel.ultimate.journeys.philippines'
NNTPGrab Core 5 Part 88 of file 'vild-discovery.channel.ultimate.journeys.philippines' from collection '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' was downloaded successfully
NNTPGrab Core 1 download_queue_get_next_part_to_download for server_id 2
NNTPGrab Core 5 Returned part 103 from file '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' from collection 'vild-discovery.channel.ultimate.journeys.philippines'
NNTPGrab Core 5 Part 103 of file 'vild-discovery.channel.ultimate.journeys.philippines' from collection '[44868]-[FULL]-[#a.b.teevee@EFNet]-[ Discovery.Channel.Ultimate.Journeys.Philippines.720p.HDTV.x264-ViLD ]-[37/37] - "vild-discovery.channel.ultimate.journeys.philippines.720p.hdtv.x264.vol21+15.par2" yEnc (1/136)' was downloaded successfully
NNTPGrab Core 1 download_queue_get_next_part_to_download for server_id 2

Kan het zijn dat xsnews iets met de timers heeft veranderd waardoor het nu met Windows vaak niet goed gaat?

Alguno,

Overigens wel lastig dat er geen edit mogelijkheid is in het forum.....

Zou je eens kunnen proberen of het meest recente snapshot voor Win64 voor een meer stabiele verbinding zorgt? Deze zou in ieder geval iets andere logging moeten produceren dan met de 0.6.90 versie. Dit snapshot valt te vinden op https://snapshots.nntpgrab.nl/win64/unstable-trunk/nntpgrab_trunk_snapshot_svn_rev1798_setup_x64.exe. Dit snapshot zal overigens ook omgedoopt gaan worden tot versie 0.6.91 indien er geen kritieke zaken meer in gevonden kunnen worden.

Het edit'en van berichten op dit forum zou vanaf nu ook moeten werken

Alguno,

Voor het installeren van de nieuwe snapshot werkte de server ineens weer normaal.
Geen idee waarom nu wel weer....

Wel gemerkt dat ook "telnet 127.0.0.1 " niet werk als download fout gaat, maar dat werkt nu wel.

Ik zal het de komende dagen in de gaten houden.

Ziet er overigens mooi uit de nieuw QT omgeving.
Tijdens het verplaatsen van een file kreeg ik "beginMoveRows failed" hierna gaat het verplaatsen van deze file niet goed meer.
Stuur wel even in video...

Edit: Open download folder werkt overigens niet bij mij...

Tijdens het verplaatsen van files of collections in de Qt frontend kan het inderdaad voorkomen dat de selectie zich vreemd gaat gedragen.
Dat is voor nu een 'known bug' en ik hoop voor de definitieve 0.7.0 release dit alsnog te verhelpen. Voor nu is het geen blocking issue
voor de komende beta release.

Het openen van de download folder werkte bij mij onder Linux wel goed. Zal dit morgen alsnog voor de zekerheid even onder Windows uit testen
en hier eventueel een fix voor doorvoeren. Als het mee zit zal morgenavond dan de 0.6.91 beta versie echt uitgebracht gaan worden

Op https://snapshots.nntpgrab.nl/win64/unstable-trunk/nntpgrab_trunk_snapshot_svn_rev1799_setup_x64.exe kan je een nieuwer snapshot vinden waarbij het openen
van downloadmappen en het uitvoeren van bestanden vanuit de Qt frontend normaal zou moeten werken onder Win32/Win64

Alguno,

Bedankt voor de nieuwe beta! Ik heb 0.6.91 geinstalleerd (op Win7-64) en het openen van een DL folder werkt weer.

Wel krijg ik bij de Welcome Screen het volgende te zien:

Welcome to NNTPGrab

You are using version: 0.6.91
The latest available stable version is: 0.6.2
The latest available unstable version is: 0.6.90
You are using a snapshot version of NNTPGrab
This is subversion revision 1800 (build 317) which was built on 20101220
For more information, go to our website https://www.nntpgrab.nl

Had verwacht "The latest available unstable version is: 0.6.91"

Je was nog iets te snel. Had die update check nog niet geactualiseerd. Dat zou hierbij alsnog gedaan moeten zijn :)

Alguno wrote:

Tijdens het verplaatsen van files of collections in de Qt frontend kan het inderdaad voorkomen dat de selectie zich vreemd gaat gedragen. Dat is voor nu een 'known bug' en ik hoop voor de definitieve 0.7.0 release dit alsnog te verhelpen.

Zou feature https://www.nntpgrab.nl/issues/32 niet handig zijn met nu het verplaatsen van files niet lekker werkt?

@RomMon: Zag in de 2 logbestanden het volgende staan:
NNTPGrab Core 5 proxies0 = direct://
NNTPGrab Core 5 No proxy required for 'reader.ipv6.xsnews.nl'

Mogelijk heb je een portproxy ingesteld.
Dit is niet nodig omdat NNTPGrab IPv6 ondersteund.

Aanvulling: Heb deze server uitgebreider getest i.c.m. NNTPGrab 0.6.90 (0.7 Beta 1).
Het blijkt dat alleen het eerste ipnummer word gebruikt waarnaar het ipadres verwijst.
Er word niet naar de andere ipnummers gekeken. Op dit moment werkt 1 van de 4 ipnummers niet.
Heb dit getest door een download te starten. Server stond ingesteld op 1 lijn.
Wanneer download werkt programma afsluiten en starten.
Dit een paar keer herhalen en dan blijkt dat soms (1 op 4) er geen verbinding gemaakt kan worden.
Er werd gemeld "381 pass required" terwijl de gebruikersnaam en wachtwoord goed zijn.

HI 123456,

Bedankt voor je test. Goed te weten dat ik niet de enige ben.
Ik meende dat met anycast het far-end netwerk verandwoordelijk is voor het kiezen van het beste IP adres,... moet er nog maar eens in duiken.

De laatste paar keer dat ik NG heb opgestart heb ik het probleem niet gezien. Hopelijk blijft het zo.

Ik heb portproxy inderdaad wel geconfigureerd. Ik zal het eens deleten, kijken of dat de debug logging vereenvoudigd.

Gebruik anders de ipnummers. Dit is echter geen echte oplossing van het probleem.
Achterhalen ipnummer (in Windows): nslookup -q=AAAA reader.ipv6.xsnews.nl
Resultaat:
reader.ipv6.xsnews.nl AAAA IPv6 address = 2001:67c:174:101::2
reader.ipv6.xsnews.nl AAAA IPv6 address = 2001:67c:174:101::3
reader.ipv6.xsnews.nl AAAA IPv6 address = 2001:67c:174:101::4 <-- Deze doet het op dit moment niet.
reader.ipv6.xsnews.nl AAAA IPv6 address = 2001:67c:174:101::5
Stel ze in als 4 verschillende servers met 1 lijn.
Op dit moment doen dan 3 van de 4 het.
Bij het ipnummer die het niet doet staat dan bij Status "ongebruikt".
Vink de niet werkende server uit omdat anders regelmatig word gecontroleerd of de server het wel doet.
Hierdoor stoppen ook de servers die het wel doen.

De reden dat je het de laatste paar keer niet gezien hebt kan komen doordat je de portproxy regel gebruikt.
Als deze regel toegepast word dan word het ipnummer dat als eerste reageert gebruikt.
Er word geen rekening gehouden met de andere ipnummers.

Als de portproxy verwijst naar een niet werkend ipnummer dan kan de portproxy vernieuwd worden.
Start dan de bat met de portproxy regel opnieuw (zonder wissen oude regel).
Dit werkt in XP en Vista sp1. Andere Windows versies zijn nog niet bevestigd.

Als er geen portproxy gebruikt word en NNTPGrab kan geen verbinding maken met de
IPv6 server van XS News is het meestal voldoende om NNTPGrab opnieuw te starten.

@123456

Bedankt voor de uitleg. Zit nu achter m'n Mac en inderdaad :4 is niet bereikbaar.

$ nslookup -q=AAAA reader.ipv6.xsnews.nl

Non-authoritative answer:
reader.ipv6.xsnews.nl has AAAA address 2001:67c:174:101::5
reader.ipv6.xsnews.nl has AAAA address 2001:67c:174:101::3
reader.ipv6.xsnews.nl has AAAA address 2001:67c:174:101::4
reader.ipv6.xsnews.nl has AAAA address 2001:67c:174:101::2

$ telnet 2001:67c:174:101::4 119
Trying 2001:67c:174:101::4...
telnet: connect to address 2001:67c:174:101::4: Connection refused
telnet: Unable to connect to remote host

Voor alle andere kan ik wel telnetten naar de newsserver port:
$ telnet 2001:67c:174:101::2 119
Trying 2001:67c:174:101::2...
Connected to reader.ipv6.xsnews.nl.
Escape character is '^]'.
201 reader.ipv6.xsnews.nl NNRP Service Ready (no posting).
quit
205 Transferred 60 bytes in 0 articles, 0 groups. Disconnecting.
Connection closed by foreign host.

Ik heb portproxy welleswaar configureerd, maar voor NG gebruik ik het niet. Heel af en toe als ik even iets met een andere newsreader wil uitproberen of echt moet headeren dan heb ik het nodig.
Zou mooi zijn als bij de volgende release headeren wordt ondersteund (Optie 1). Met optie 2 zie ik toch vaak c.a 750kb results wat vaak een virus betekend.

Ter info: De IPv6 server van XS News heeft geen headers.
De IPv6 server van Newszilla heeft wel headers (paar dagen).
Voor zoeken gebruik ik liever Binsearch, nzbindex enz. i.v.m. de extra info.

123456,

Heb nu weer dezelfde situatie waarbij DL niet wil starten.
En nu met WireShark gekeken, en inderdaad er wordt constant gebruik gemaakt van 2001:67c:174:101::4
Maar ook na telkens opnieuw afsluiten en starten van NG, blijft dit adres in gebruik.
Ik zie dan ook geen AAAA DNS (IPv6 query) voorbij komen.
Bij het opnieuw opstarten van mijn pc wel (zie hieronder).
In de DNS reply staan wel alle 4 de adressen, met 2001:67c:174:101::4 als eerst.
Ook nu wil de DL niet starten....nog maar een keer opnieuw opstarten....

Queries
reader.ipv6.xsnews.nl: type AAAA, class IN
Name: reader.ipv6.xsnews.nl
Type: AAAA (IPv6 address)
Class: IN (0x0001)
Answers
reader.ipv6.xsnews.nl: type AAAA, class IN, addr 2001:67c:174:101::4
Name: reader.ipv6.xsnews.nl
Type: AAAA (IPv6 address)
Class: IN (0x0001)
Time to live: 1 hour, 13 minutes, 38 seconds
Data length: 16
Addr: 2001:67c:174:101::4
reader.ipv6.xsnews.nl: type AAAA, class IN, addr 2001:67c:174:101::2
Name: reader.ipv6.xsnews.nl
Type: AAAA (IPv6 address)
Class: IN (0x0001)
Time to live: 1 hour, 13 minutes, 38 seconds
Data length: 16
Addr: 2001:67c:174:101::2
reader.ipv6.xsnews.nl: type AAAA, class IN, addr 2001:67c:174:101::5
Name: reader.ipv6.xsnews.nl
Type: AAAA (IPv6 address)
Class: IN (0x0001)
Time to live: 1 hour, 13 minutes, 38 seconds
Data length: 16
Addr: 2001:67c:174:101::5
reader.ipv6.xsnews.nl: type AAAA, class IN, addr 2001:67c:174:101::3
Name: reader.ipv6.xsnews.nl
Type: AAAA (IPv6 address)
Class: IN (0x0001)
Time to live: 1 hour, 13 minutes, 38 seconds
Data length: 16
Addr: 2001:67c:174:101::3

Dat het voor mij voldoende is om NNTPGrab opnieuw te starten komt waarschijnlijk
doordat de service "DNS Client" uitgeschakeld is.
Hierdoor word er geen lokale dns cache gebruikt.

Over DNS Caching uitschakelen/configuratie https://www.tech-faq.com/how-to-flush-dns.html

Stel XS News anders zoals eerder genoemd als 4 verschillende servers in.

Ik had je eerdere suggestie al toegepast, en dat werkt perfect. Bedankt daarvoor. Ook bedankt voor de DNS cache info.
Op het forum van XS News was er een thread voor de IPv6 server, maar die is nu nergens meer te vinden. Jammer.

Binnen NNTPGrab is vanaf versie 0.6.2 ook een eigen DNS cache aanwezig.
Zodra een lookup-poging geslaagd is, dan zal deze in een eigen cache geplaatst
worden zodat het niet meer noodzakelijk is dat bij elke verbindingspoging een
DNS lookup uitgevoerd wordt. Als een DNS entry eenmaal in deze cache staat, dan
blijft deze daar ook staan voor zolang NNTPGrab blijft draaien.

Deze functionaliteit is geïmplementeerd om te voorkomen dat bij mensen met een
onstabiele internetverbinding het downloaden spontaan gestopt kon worden met een
'DNS lookup mislukt' melding. Door deze functionaliteit blijft het programma
bij verbindingsverlies gewoon doorgaan met het proberen van het opzetten van
een nieuwe verbinding in plaats van er compleet mee te stoppen na 1 mislukte poging.

Op dit moment word de server van XS News via alle 4 de ipnummers bereikt.
Het probleem dat er naar een niet werkend ipnummer word verwezen is er op dit moment dus niet meer.

Wilde eigenlijk controleren of met de nieuwe NNTPGrab versie wanneer naar een niet werkend ipnummer
werd verwezen zonder NNTPGrab opnieuw te starten later naar een werkend ipnummer werd verwezen.
Zal dit dus een andere keer testen als het probleem er weer is.

NNTPGrab versie 0.6.91

Op dit moment doen 2 van de 4 ipnummers van de XS News server het niet.
NNTPGrab probeert 2 ipnummers (van de 4) als het serveradres (dnsnaam) word gebruikt.
Het zijn echter net de 2 ipnummers die het niet doen.
Na een herstart van NNTPGrab werden weer beide niet werkende ipnummers gebruikt.
De dns service staat uit dus dat is het niet. Weet dat NNTPGrab een eigen dns cache gebruikt.
Kan deze maximaal 2 ipnummers per adres in de cache zetten?
Bij nslookup worden alle 4 ipnummers getoond.

Via IPdirect werkt downloaden wel via de 2 ipnummers.

Wanneer de 2 niet werkende ipnummers opnieuw worden gecontroleerd of deze werken
stopt de volledige download. Niet werkende servers dus uitvinken.