Du hast recht. Ich hatte eine dunkle Erinnerung an diese Funktion aus einem Test im Dezember und habe da einiges durcheinandergebracht. Daß das aus dem RT ist hast Du auch damals schon geschrieben. Allerdings hat der damals wirklich jemanden rausgeworfen und nicht, wie bei ZZ, einen zusätzlichen Slot für den Freund geöffnet, bis der Upload an jemand anderen normal beendet wurde.

Naja, ich muß mal wieder den Kopf schütteln, dann verteilt sich der Kalkstaub gleichmäßiger...

Mit freundlichen Grüßen
aalerich

Streu nicht so oft Asche über dein Haupt, aalerich ^^

@Xman
so mit Limit sind es ca.34% und ohne Limit ca.32% scheint nichts damit zu tun zu haben.
Vielleicht habe ich ja auch nur ein schlechtes Wochenende erwischt.
Schönen Sonntag noch:-)

bevor der Thread einschläft.... eine kleine Vorankündigung:
morgen gibts die 4.1 !
diese Version wird sehr sehr viele Änderungen beinhalten, auch wenn sich diese Änderungen unter einem Wort zusammenfassen lassen: Xtreme Downloadmanager

Na, dann werde ich mich nun beim Testen mit einklinken :)

Und ich bin Rechnerlos :-( . C++ pauken kann so öde sein vor allem wenn man nicht mal nen Compiler hat. Wenn ich ne DSL Leitung hätte könnte ich wenigstens mit testen,aber nichtmal das ist mir vergönnt. Werd mich aber ab nächstem Dienstag dem Test anschließen. Bis dahin...

mfg Max

Neue Testversion x3alpha4.1
---------------------------------

new:
- zz-Downloadmanager wurde zum allergrößten Teil entfernt


- Xtreme Downloadmanager hinzugefügt (sehr viele Änderungen)

+ alle Optionen vom Xtreme2.2 Downloadmanager wieder verfügbar+ manuelles/automatisches droppen (in den Einstellungen/Erweitert kann man sich drop-Meldungen ansehen lassen)

+ manuelles swappen wieder möglich
+ manuelles Stoppen eines Downloads

- anderer Code zur Kalkulierung wann eine Quelle erneut abgefragt werden muß

+ mittels Tooltip auf einen Downloadclient kann man sich die Zeit bis zur nächsten UDP(TCP)-Abfrage ansehen

- etlich Codeverbesserungen

- Extended Cleanup des offiziellen emule wurde auf Extended Cleanup II umgeändert, da es Basis für Xtreme Downloadmanager ist


- einige Detailänderungen im Transferwindow, Downloadclients

+ statt Time Remaining, wieder AvgQR

- Preferences/Tweaks geändert

- kleiner Patch um den Anfangsausschlag des Uploads zu unterbinden


- in den Xtreme-Einstellungen wurde die Option "doublesendsize" hinzugefügt


Anmerkung zu Doublesendsize: schickt statt der MTU-Größe, das doppelte von MTU. Kann sinnvoll sein, bei Slotspeed > 5 kbs. Der Upload zu den einzelen Clients stabilisiert sich dadurch, dafür wird der Uploadgraph etwas unruhiger, das ist technisch so bedingt


to test:
- alles was man so im Transferfenster mit den Downloadclients machen kann




- nun dürft ihr Statistiken frühere Versionen vergleichen... bitte prüfen:

+ Overhead vergleichen + UDP-Neuanfragen, insgesamt/fehlgeschlagen vergleichen

+ alle Werte die aus der üblichen Norm fallen

- Speicherverbrauch ? CPU-Auslastung ?




Download: binaries & sources


changelog alpha 4.1
- removed most parts of zz-downloadmanager




- added //Xman Xtreme Downloadmanager (many changes!)

- includeds all features of Xtreme2.2- manual/automatic dropping

- manual A4AF Handling
- manual stoping of downloading source

- // Maella -Unnecessary Protocol Overload- (modified by Xman)

- //spread reasks (Maella/Xman)
- codeimprovements to downloadqueue, downloadclient, partfile
- Maella -Extended clean-up II- (modified by Xman)
- show time until next UDP-reask/TCP-reask in downloadlistctrl-Client-Info-Tip
- some changes to downloadlistctr
- small patch to uploadbandwidththrottler to avoid to high uplod at start
- cleaned up Preferences->Tweaks
- added an option to Log Dropping messages


- added an option to preferences->Xtreme to use doublesendsize

remark: you can try to use this, if you have choosen a high slotspeed(>5), this can help to increase the datarate, given to each client. but this option let your uploadgraph show more "unstable"

Zu guter letzt:
Gut 50% des Xtremes sind nun fertig.. man kann sagen: das Herzstück ist geschafft.
wie ich schon erwähnt habe, werde ich mir nun 2 Wochen Coding-Pause gönnen. Ich werde zwar noch hier im Forum ab und zu vorbeischauen, doch geht die nächsten 2 Wochen das Privatleben vor.


Edit: Ich glaub ich bin kein Freund der Boardsoftware... verwendet man Einzüge macht sie scheinbar willkürlich Leerzeilen an beliebige Stellen.

x3alpha4.1

bei den transferrig Clients mit einer niedrige ID steht in dem Tooltip als nächste Anfragezeit 49 T 16 H

bin etwas begriffsstützig, verstehe das nicht. Ein File konnte ich bisher doch immer manuell stoppen und für einen Client sehe ich keine Option

@paul2
ist ein kleiner Anzeigebug, wenn der Client noch gar nicht gefragt wurde wegen "zu viele Verbindungen".. werd ich ändern, danke für den Hinweis.

Stoppen eines Downloads meint hier nicht das File, sondern den Download eines Clients. War reine Absicht es ein wenig verwirrend auszudrücken ;-)

Test Test Test Test Test Test Test Test Test
 

Hi

Seit 4.30h läuft die x3alpha4.1
1) aber er schaft es nicht die Freigeben Datein zu Überprüfen
18 bekannte freigegebene Dateien gefunden, 9 neue Dateien warten aufs Hashing
2) habe ein fertige Datei in Transfer die nicht "Wird beendet (Überprüfe)" habe 29 DL
3) Sever wecksel 21:45:53: HighID your IP is: 83.***.***.***, "NAFC-Adapter will be checked" ?

Was bedeutet die funktion in Tranfer nach Rechtklick Drop NNS und FullQ ?

Habe alles sauber installiert aus meiner alten Version :!: MorphXT v6.2 :!:nur cryptkey.dat, preferences.dat und clients.met mitgenommen. Temp und Incoming wie gehabt überschrieben.

Einstellung Verbindung
AppVersion 0.45b [alpha4.1] MaxUpload 19
Nick http://emule-web.de/ MaxDownload 230
MaxConnections 400 Port 4662
UDPPort 4672 DownloadCapacity 256
ServerUDPPort 65535 UploadCapacity 24
MaxSourcesPerFile 800 MaxConnectionsPerFiveSeconds 20

Habe in den Optionen ansonsten keine Werte geängert,was bedeutet "Xtreme" in Optionen ?
Mein Internetanschluß ist von Versatel 2048 Down u. 256 Up kein Router aber eine Agnitum Outpost Firewall 2.5 und cFosSpeed 2.?.

Kann mir jedemand ein paar Antworten oder Tipps geben oder ein Anteitung zukommen lassen?

[edit by Pathfinder: IPs unkenntlich gemacht - Board Rules beachten!]

@extremeevil
Du scheinst noch ziemlich neu in der Materie zu sein... darum würde ich Dir empfehlen vorerst mal keine alpha Version eines Mods zu nehmen.

zu Deinen Fragen:
an den ganzen Hashing-Algorithmus hab ich nicht Hand angelegt und werde es auch nicht tun. Insofern bitte ich Dich zu überprüfen ob das Problem nicht auch im Original-emule auftritt. Evtl. ist der Bug auch beim Morph zu suchen... keine Ahnung
Drop NNS = verwerfe Quellen welche keine benötigten Teile haben
Drop FQ= verwerfe Quellen welche volle Queue haben

bei mir öffnete er 8 UL Slots mit je 0,7kb/s ??? kann doch auch nicht sein, oder?

Die 4.1 läuft seit ca.7 Stunden ohne Probleme.CPU und Speicher ist wie immer.Alle Neuerungen
funktionieren.Aber durch das Autodropen der NNS/FQ habe ca. 60 Verbindungen mehr als in der
Version 4.0

@Hopie
nee.. das kann wirklich nicht sein.. drum überprüfe doch nochmal bitte Deine Einstellungen.

@daenemark
pauschal auf das droppen kannst Du das nicht mal zurückführen. Der ganze Abfragemechanismus ist geändert in sehr vielen Details. Sollte aber nicht stören solange es gut läuft und der Overhead sich in Grenzen hält.

was mir in der Verbose Log auffiel
40 mal der gleiche Eintrag hintereinander, mitgleicher Uhrzeit und gleicher IP
23.03.2005 02:11:43: Invalid packet with opcode: 0xff, size=50, client=eMule v0.44d, up. state=In Warteschleife, down. state=none, data=[50 b2 ac 4e 54 5e 43 b5 36 12 cf d7 e8 8d 23 a0 11 13 a3 81 6b 11 ed e0 b7 83 0 b0 85 b ff 7f 88 b ff b4 67 93 aa de ff 3a ab fa 6b fe f7 f2 cf 51]; Client=80.178.***.** 'h**p://W*w.L**Network.***' (eMule v0.44d,None/OnUploadQueue)

hatte die standart einstellungen drinne

@hopie
das darf lediglich 15 Sekunden nach dem Start und bei ingeschaltetem "UploadReduction" sein (da braucht er 15 Sekunden um die passsenden Werte zu errechen).
Wenn das danach passierte, dann ist Dein Upload zu hoch !?

@paul2
das ist ein Fehler des Clients von LionNetwork. Der ist bekanntermaßen buggy. Die offizielle Version würde hier genauso reagieren, nur die Meldung etwas anders formatiert anzeigen. In der endgültigen Version werde ich diese Meldungen (wie auch im Xtreme2.2) wieder unterdrücken.

@xman..

hab dsl1000 und als UL 12 o.13kb freigegeben. is ja eigentlich normal. werds aber noch mal testen

EDIT:

ok passt.. hatte gestern wohl nur n volles netz ... ;)

@Hopie

Was hast du denn bei Upload Slot Speed eingestellt ??
upps überlesen:bang ,dann hat das sich ja erledigt

So nach 18 Stunden Laufzeit sind keine besonderheiten aufgefallen, im Downloadfenster kann ich alle Funktionen ausführen, Stabil läuft der Mod auch. Ich habe nur mein altes Problem, es werden immer zu viele Slots aufgemacht es sei den ich schalte "Open mor Slots ..." ab, doch dann ist der Upload sehr "sprunghaft". Ach meinen Overhead habe ich jetzt einigermassen in den Griff bekommen, fragt mich aber nicht wie, habe ienfach ein bisschen rumgespielt und jetzt läuft es.

Mit freundlichen Grüssen
mav744

4.0 und 4.1 schicken Rechner in einen Reset
 

Hi XMan,

nachdem die 4.0 nach ca. 5 Stunden abgeschmiert ist, hatte ich mehr Hoffnungen in die 4.1 gesteckt. Diese schickte meinen Knecht allerdings nach ca. 6 Stunden in einen Reset.
Prozessorauslastung ist im Betrieb minimal. Hatte mit den 3er Versionen keine derartigen Probs...

[Edit:]
Zu den Sessions hab ich hingegen gute Neuigkeiten (vergessen zu posten):
Erfolgreiche Upload-Sessions: 633 (89.66%)
Erfolgreiche Download Sessions: 863 (76.9%)

Gruß,
X-Ray

Auch nach 1Tag und 3 Stunden läuft die 4.1 Stabil alles funktioniert Ul/DL sind auch O.K.
Ausser das die :
Fehlgeschlagene Download Sessions: 398 (34.6%) (paused: 0, no needed part: 2, timeout: 106, socket: 280, out of part: 9, exception: 0, others: 1)
seit der 4.0 mehr geworden sind ( lagen bei den 3er Versionen bei max 28%). Egal ob DL-Limit an oder aus .Und wie schon erwähnt sind die Verbindungen um ca.60 mehr geworden.
Ansonsten läuft der Mod wieder SUPER.Danke Xman

Ich kann mich daenemark's Danke nur anschließen.

Also die 4.1er läuft jetzt seit ca. 7 Stunden ohne Probleme und mit gewohnt gutem Up- und Download. Lediglich die Zeit die er braucht bis er auf vollen Touren ist, hat sich meiner Ansicht nach seit der 4.0er etwas verlängert (würde wegfallen, falls man dies mit einer Erhöhung der Quellen (ca. 5500-6000 in letzter Zeit) erklären könnte). Die erfolgreichen Upload- und auch die Download-Sessions sind wie immer - eine markante verbesserung oder verschlechterung kann ich nicht erkennen. Overhead: Upload: 1.5 - 2.0, Download: 2.5 - 3.0).

Ich hätte allerdings noch eine etwas nebensächliche Frage, bezügliche der Berechnung der Gesamten Durchschnittlichen Downloadrate (GDD). Was ich meine:
Also meine Statistik läuft jetzt seit ca. 11 Tagen und davon ca. 80-90% der Zeit bisher mit einem Durchschnitt von ca. 75-80 kb/s - jedenfalls rein theoretisch aus meiner Sicht geschätzt. Meine Session-Durchschnittlichen-Downloadraten (SDD) nähern sich also während der 24 Stunden zwischen den Zwangstrennungen regelmäßig an 70 kb/s an. Die GDD fängt nach jedem Emule-Neustart ebenfalls wieder bei null an und klettert dann gemeinsam mit der SDD langsam nach oben - jedoch etwas langsamer und mit 5-10 kb/s weniger.
Ok was ich mich nun Frage: Wieso fängt die GDD jedesmal wieder bei null an und errechnet sich nicht über den Durchschnitt aller bisherigen SDD? Beim Upload : Download Verhältnis wird es doch auch so gehandhabt.

@Xman
mein upload problem liegt nicht an zu hohen einstellungen des Limits, selbst wenn ich ein limit von 11 oder 12 einstelle, habe ich das gleiche Problem das im Schnitt 8 Slots geöffnet werden. Laut DUMeter geht mein Up zu Spitzenzeiten incl. Overhaed bis auf 14 -17 hoch (auch bei hohem Down). Der Originale hat dieses Problem nicht, ich weiss Du hast den Upload umgeschrieben, habe aber die letzten Stunden extra vergleiche gemacht. Die waren zwar nicht als langzeittest angelegt, aber irgendwie mache ich wohl etwas falsch.Ach mein Overhead ist mitlerweile auf im Schnitt 3-4 KB/s Gesunken, ist doch nen Vortschritt :mrgreen:

Mit freundlichen Grüssen
mav744

Hanussen,
beim Upload : Download Verhältnis ist das Gesamt immer sichtbar
beim GDD muß du den Zweig Geasmt aufklappen
wenn ich dich richtig verstanden habe

@mav744 & Xman
Ich habe mich in der letzten Stunde auch einmal der Anzahl meiner Upload-Slots gewidmet, weil es bei mir teilweise auch 8 offene Slots waren. Habe dann mal den Haken bei "Open more slots if needed" rausgemacht und daraufhin wurde es nach kurzer Zeit auch tatsächlich besser. Die Anzahl der normalen Slots ist auf 3 mit jeweils 2.7 kb/s runtergegangen mit zusätzlich einem grauen Slot mit 0.5 kb/s - also so wie es denke ich mir eigentlich sein sollte. 3 * 2.7 -> 8.1 + 0.5 -> 8.6 + ca. 2.0 Overhead = 10.6 <- eingestelltes Upload-Limit. Das hat aber auch nur eine paar Minuten gehalten und jetzt sind es wieder 4/7 Slots. Also 4 Stück mit ca. 1.8. Woran liegt das?
EDIT: Mittlerweile sind es wieder 3/4 Slots. Es scheint also doch ohne "Open more slots if needed", jedenfalls bei mir, besser zu laufen. Ich werde es aber weiter beobachten.

@Paul 2
Danke für deine Antwort, aber nein, das meinte ich nicht.Mir ist schon aufgefallen, dass man den Gesamt-Zweig erst aufklappen muss!! :-) Es ging mir mehr darum nachvollziehen zu können aus was sich die GDD zusammensetzt bzw wie sich berechnet wird.

@X-Ray
wurde kein dump-file erstellt ? Das bräuchte ich um den Fehler zu finden.
@Hanussen
kannst Du mal genau den Teil der Statistik posten der nicht richtig funzt ? Ich weiß nämlich nicht genau was Du nun meinst.

wegen Uploadslots:
wenn "Open more slots" eingestellt ist, schaut emule ob einer der Slots 25% über der eingestellten Slotspeed ist, falls ja->neuer Slot. Ebenso neuer Slot, falls ein Trickle 50% der Slotspeed erreich.
Ohne der Option wird die Anzahl der Slots simple errechnet aus uploadlimit/Slotspeed (aufgerundet).

@all
einem Bug bin ich noch auf der Spur, der aber von der offiziellen Version kommt und schon seit vielen Jahren drin ist. Hab ein evtl ein Socketproblem gefunden, welches aber sehr sehr tief im Code zu suchen ist. Werde das womöglich auch gar nicht fixen können... aber gehe dem ganzen nach, um den Bug verifizieren zu können und die Devs darauf aufmerksam machen. Der Code seit 4.0 welcher für das einlesen der Downloaddaten verantwortlich ist, ist zumindest nun von mir auf Herz und Nieren getestet und als fehlerfrei zu bezeichnen.

Edit:
ich bat euch doch schon früher mal paar Statistiken zu sammeln um sie vergleichen z ukönnen. Warte noch auf einen 24-Stunden vergleich zwischen Version <4 (oder offizieller version) und 4.1... es geht hauptsächlich um den Overhead und die UDP-Anfragen. Falls es euch zu aufwendig ist die Statisitken selbst auszuwerten, könnt ihr mir gerne auch eine aktuelle + früherer an emulextreme@yahoo.de schicken.

@Xman

Statistik ist unterwegs.

Hi Xman,

hab sogar beide Minidump-Files, also vom 4.0 und 4.1-Crash. Ich muß gestehen, daß ich mit den Files nix anfangen kann:oops: - kann sie dir aber gerne zukommen lassen (wenn du meinen Speicherinhalt vertraulich behandelst :wink: ).
Eine Statistik werde ich dann auch mitschicken. Allerdings hab ich's versäumt von einer 3er eine zu machen:oops:. Werd ich aber (leider erst nach den Feiertagen) nachholen.

Btw: Aktuell läuft die 4.1er seit 22 Stunden durch.

Hi

Die 4.1er läuft jetzt seit ca. 11 Stunden ohne Probleme, das Up- Downverhältnis 1:4,1

Ein Frage was ist der Unterschied im Transferfenster zwischen

Übertrage und Übertrage*

Xman du machst einen tollen Job

micha1963

@x-ray
die dumpfiles zeigen im wesentlichen nur an, an welcher Stelle des Codes udn mit welchen Werten emule gecrashed ist. Damit kann nur ich was anfangen (zumindest meistens). Und natürlich werden Daten vertraulich behandelt.

@micha
der * bedeutet immer, daß der betreffende client nicht nur eines, sondern mehrere Files hat, die Du benötigst.

@all
danke für eure Unterstützung

@Xman

Habe dir zwei 24 Stunden Statistiken per E-Mail geschickt.

Was ich wegen der Gesamten Durchschnittlichen Downloadrate gemeint hatte muss nicht unbedingt ein Bug oder ein Fehler sein. Ich habe mich lediglich gefragt, wie dieser Wert errechnet wird.
Angenommen meine Statistik läuft seit 10 Tagen und davon 90% der Zeit mit einer Downloadrate von 80 kb/s. Wenn ich nun Emule nach jeder Zwangstrennung, also nach 24 Stunden, neustarte, dann nähert sich der Wert der Session-Durchschnittlichen-Downloadrate innerhalb der 24 Stunden der Marke 70 an. Die Gesamte Durchschnittliche Downloadrate fängt aber nach jedem Emule Neustart so wie ich das sehe bei Werten zwischen 0 und 30 an. Das erscheint mir unlogisch, die GDD müsste sich doch genauso bei ca. 70 kb/s einpendeln und durch kurz andauernde langsame Downloadraten (also der Übergang Volllast -> Neustart -> neue Session) nicht groß beeinflusst werden. Genauso eben wie es bei, Gesamten Upload : Download Verhältnis gehandhabt wird.
Ich hoffe es ist jetzt verständlich, wenn nicht auch egal dann lassen wir das :-)

MfG Hanussen

Sorry Xman, aber ich werde mich bis nach den Feiertagen etwas aus dem genauen beobachten des emules zurückziehen. Feiertage bedeuten leider auch weniger Zeit und zudem bin ich vom Sport auch noch verletzt. Wenn irgendetwas dringendes anliegt oder eine neue Version released wird werde ich natürlich versuchen zu helfen.

Mit freundlichen Grüssen
mav744

@hanussen

so ganz genau kann ich es zwar nicht nachvollziehen.. aber 2 Punkte:
erstens... das hier ist der Code:
zweitens: das Up/Down-Verhältnis läßt sich aufs Byte genau errechen, da klare Werte bis aufs Byte vorhanden sind. Bei der Down/uprate hingegen ist das rein mathematisch gar nicht so einfach möglich. (wann war welche up/downrate für wie lange gültig... usw. zu speichern und auszuwerten ist bei weitem zu viel Aufwand). Daher sucht das System einen möglichst realistischen Wert zu "schätzen".

Wenn ich Hanussen richtig verstanden habe wird bei einem Neustart des Mulis nicht nur die Sessionrate auf Null gesetzt und neu mit ihrer Ermittlung begonnen, sondern auch die Statistik für die gesamte Rate über alle bisherigen Sitzungen. Normalerweise sollte die Statistik der Gesamtrate ja angeben, wie hoch die Downloadrate für die gesamte Laufzeit des Mulis im Schnitt war. Schon zu Beginn einer neuen Sitzung müßte dieser Wert also deutlich über Null liegen (Es sei denn natürlich, daß mit dem Muli noch nie etwas heruntergeladen wurde.) Bei ihm wird aber wohl nicht nur die Sessionrate jedesmal zurückgesetzt, sondern auch die Gesamtrate.

Naja, so habe ich das zumindest verstanden.

Mit freundlichen Grüßen
aalerich

Guten morgen allerseits. aalerich hat die Situation genau richtig erfasst.
"Normalerweise sollte die Statistik der Gesamtrate ja angeben, wie hoch die Downloadrate für die gesamte Laufzeit des Mulis im Schnitt war. Schon zu Beginn einer neuen Sitzung müßte dieser Wert also deutlich über Null liegen" <- Genau so habe ich das gemeint.
Die Gesamtrate wird zwar nach jedem Neustart nicht jedesmal auf null zurückgesetzt sondern meistens auf Werte zwischen 10-30, jenachdem wie der Download gerade lief/läuft, aber denoch kann dieser Wert ja kein realer tatsächlicher Wert sein.
Erklärung gibt daher der Post von Xman. Von dem Code habe ich eigentlich soweit alles verstanden bis auf "thePrefs.GetConnAvgDownRate". Logisch erscheint mir deine zweite Erläuterung. So etwas in der Art habe ich mir auch schon überlegt. Wenn ich es richtig verstanden habe, dann kann man den realen Wert der Gesamten Durchschnittlichen Downloadrate nicht errechnen, da sich ja der Muli nicht alle Downloadraten merken kann um daraus dann einen gesamten Durchschnitt errechnen zu können - logisch :-)
Ich denke das "Problem" hat sich jetzt geklärt, danke für eure Erklärungen.

Mit freundlichen Grüßen
Hanussen

Na gut, für mich ist der Code genauso verständlich wie Konfuzius in der Originalsprache :mrgreen:

Mit freundlichen Grüßen
aalerich

Ich habe eigentlich auch keinerlei Ahnung vom Programmieren, aber ich finde, der Code lässt sich relativ logisch erschließen. So wie ich es verstehe beschreibt er die Berechnung der Gesamten Durchschnittlichen Downloadrate. Sie wird errechnet durch die aktuelle Session Downloadrate plus "thePrefs.GetConnAvgDownRate()" (hierbei wird wohl aus den Preferences irgend eine Durchschnittliche Connection Downloadrate gelesen) und das ganze geteilt durch zwei. Das Ganze wird bei der Gesamten Durchschnittlichen Uploadrate genauso berechnet.
Schließlich geht es noch um die Maximale Gesamte Durchschnittliche Downloadrate. Wenn der Wert der aktuellen GDD größer wird als der Wert der maximalen GDD, dann wird dieser neue größere Wert als maximale GDD eingetragen.
Also wie gesagt ich habe mit Programmieren absolut nichts am Hut, es wäre aber interessant zu hören, ob meine Erläuterungen so in etwas zutreffen.

MfG

@hanussen:
richtig interpretiert. Ich hab den Code hier auch darum gepostet, weil er mehr sagt, als ich mit 100 Erlkärungen ausdrücken könnte.
Die Idee zu diesem Code ist nicht auf meinem Mist gewachsen... man könnte es sicherlich besser machen... aber ich glaub der Aufwand lohnt nicht für einen doch eher unwichtigen Wert.

und den der Normaluser auch wahrscheinlich nie ansehen wird