Thema: NNTPdefrag.R32

[Sky-Nett]

Hallo zusammen,

erstmal grosses Lob an R32 für die schöne Arbeit!
NNTPdefrag.R32_1.04 hat jetzt auch bei mir das Perlscript ablösen können.

Zum speed:
Manche nntpDateien (50-100+MB) enthalten lediglich textstrings mit infos
über neue usenet-Postings, da geht auch das perlscript ordentlich in die Knie und braucht
äusserst lange zum defraggen. Die End-Ausbeute ist imho vergleichbar mit perl.
Wohl dem, der Dualcore-CPU hat

zu Skynet (allgemein)
Jetzt stellt sich mir aber immernoch die Frage warum mac-Filter durch Einträge in rules.txt
überhaupt nicht greifen bei nntp wohl aber bei http. Also wenn SkyNet Mod R32 ein bischen
dahingehend auf nntp optimiert werden kann wären alle glücklich

grüsse Sky

SS2@66MHz Skynetix0.11Test  8°West AMDX2.............

[bigobelix]

Hi Sky-Nett,

darüber habe ich mir auch Gedanken gemacht und bin zu dem Schluß gekommen, Gott sei Dank geht das nicht!
Begründung: Nur weil einer pausenlos den Musikantenstadl schaut und den ZDF-Fernsehgarten oder ähnliche Brechmittel heißt nicht, daß er morgen nicht Stargate anschauen will - alles klar? 

Machs wie ich, ich sortiere vorher mit dem Total Commander nach Größe und schau mit F3 kurz rein bei den Dateien, die sehr groß sind. Und alles unter 1MB wird gelöscht. Dauert 5min...

bigobelix

[Plastic]

@woodie,
ist Dein Problem mit dem Absturz gelöst?
Eine Idee hätte ich, versuch es im abgesicherten Modus!
Kann es leider nicht testen ob NNTPdefrag.R32 im abgesicherten Modus läuft.
Gruss, plastic

[woodie]

@plastic

Nein, das Problem besteht immer noch, hatte aber noch keine zeit mich darum zu kümmern. Werde erst zum Wochenende dazu kommen.

[R32]

Hallo,

ich hab NNTPDefrag nochmal überarbeitet.
Der Link ist in meiner Sig.

Gute Nacht,
R32



Die wichtigsten Änderungen ...

1.05 - 2006/10/17
-----------------

- Laufzeitoptimierung durch Code-Umstellung von string class auf char[]
- Bugfix Line Endings
- Bugfix Zeichenersetzung in Nicht-YEnc-Files
- Bugfix für div. Abstürze
  [Vielen Dank an bigobelix und plastic!]
- Markierung der Dateien ohne "=yend" als *.uud.no_yend
  [Idee von plastic]
- Default von -s auf 2kB geändert
- Verbesserung der Abschnittserkennung bei defekten Blöcken im NNTP File

[bigobelix]

@R32

Ich weiß ja nicht, wann Du eigentlich schläfst, aber daß Du Dir die halbe Nacht um die Ohren gehauen hast, war nicht umsonst, das Programm ist eindeutig schneller. Bin noch nicht ganz fertig, aber bis jetzt auch kein Absturz.

Danke für Deine geleistete Arbeit.

bigobelix

[R32]

@bigobelix

Schlafen? Wozu?   
Ich kann beim Hacken gut entspannen. 5-6 Stunden Schlaf reichen.

Dein erster Eindruck klingt ja schonmal gut. Ist es denn dabei geblieben?

Gruß,
R32

[bigobelix]

Hi R32,

kann den ersten Eindruck voll bestätigen, schnell und absturzfrei, danke!

bigobelix

[pogo13]

Hallo,

habe doch noch etwas Zeit gefunden um zu testen. Respekt, Respekt.

Habe in der Nacht 14GB an nntp Dateien auf der Platte gehabt. Nach 1:57 h NNTPdefrag.R32 (1.4 GHz Athlon), etwa 13,9GB uud´s im OK. Sehr gute Quote.

Vielen Dank für deine Mühen.

Grüße
Pogo

[bigobelix]

@pogo13

Das Ergebnis habe ich auch, aber was bleibt nach Uudeview noch übrig?

bigobelix

[pogo13]

hallo bigobelix,

nach uudview ist leider nur etwa 7GB übrig geblieben. Rein subjektiv würde ich meinen, dass nach dem perl-script mehr übrig geblieben war. Aus diesem Grund möchte ich morgen das gleiche Material zwei mal bearbeiten lassen und einen genauen Vergleich anstellen. Bericht dann morgen.

Aber ich habe auch eine andere Frage. Ich hatte seit Mai nichts mehr gemacht. Nun war die gewohnte Frequenz auf 8°W nicht mehr da. An anderer Stelle hatte ich gelesen dass auf 11222 was läuft. Dort hatte ich auch die 14GB über Nacht. Allerdings war fast alles in french

Wo läuft den der deutscher Content auf 8°W?

Grüße
Pogo

[Plastic]

Hallo Pogo,
Versuch 12261 bzw. 12524
(siehe "Was geht wo, Frequenzen & Pids")
Gruss, plastic

[bigobelix]

@pogo13

den Test kannste Dir sparen, genau das hatte ich auch gedacht. Daran liegt es nicht, das Progi von R32 arbeitet tadellos. Irgendwas ist faul und ich weiß noch nicht, was es ist.  Bei bleibt neuerdings einfach zu wenig übrig. Da ich das seit Jahren mache, fällt das sofort auf.

Ich prüfe weiter.

bigobelix

[pogo13]

Hi bigobelix,

meinst du dass einige Jungs evtl. am Codieralgo gedreht haben könnten? Hast du schon mal die header angesehen, ob da was anders ist?

Hat es möglicherweise mit der Endung .uud zu tun, den nach dem perlscript hatten wir .m Dateien. Ich hatte vor langen Zeit im uudeview mit den Decoderoptionen herumgespielt (fast mode, dump mode u.s.w.) und hatte festgestellt, dass das outcome teilweise viel schlechter war. Vielleicht werden uud Dateien von vorn herein anders behandelt als unbekante Dateitypen?

Eine andere Frage. Für nntp hatte sich die skynetx bisher bestens bewährt. Leider konnte ich noch nicht die R32 Version testen. Wie sind deine Erfahrungen damit? Den die 0.90 skynet Version hatte gegenüber der 0.89 das nntp Protokol vernachlässigt.

@Plastic,

vielen Dank für den Hinweis, hatte aber auf der 12524 leider kein Erfolg, Server4PC zeigte mir hier keinen Empfang. So hatte ich es nicht mit skynet versucht, vielleicht ein Fehler.

Ich habe auch noch eine Frage zum DeleteFiles.vbs. Irgendwie will er nicht. Nach dem ich ihn nach der windoof Warnung autorisiert habe, wird er durch die bat aufgerufen (?) und die kleinen Dateien bleiben erhalten. Die Verzeichnisse habe ich entsprechend angepasst. Hat jemand ein Tipp?

Grüße
Pogo

[bigobelix]

@pogo13,

das vermute ich auch. Leider habe ich keine alten Dateien zum Vergleich mehr da.
Und ob hhtp noch geht, weiß ich nicht, nutze ich nicht.
DeleteFiles.vbs ging bei mir auch nicht.

bigobelix