![[eMule-Web]](images/satellite/header/logo.jpg){kind=logo}
|
Mhh .. vielleicht wäre ein dynamsiches overhead Limit hier doch ein bisschen angebrachter .. ;) Zweierlei Limits .. Upload 10k und Overhead Maximal 14k ... Das sollte mit dem XTreme D-Manager doch leicht machbar sein ... |
glaub Du solltest erst mal etwas intensiver den Code studieren um die Zusammenhänge zu begreifen ;-) |
wenn ich den kompletten hätte würd ich ds auch machen ;) Jedoch warte ich lieber auf die "Final" .. bevor ich noch was falsches in mir verewige ... |
Zitat:
Zitat:
@ Xman: Die Idee find ich in Ordnung. Allerdings wie wäre es wenn du eine session based ratio einbaust¿ Von der Funktionsweise kannst du ja wählen zw. ZZ, NetF und einem eigenen. Und koppeln an den Durchschnittsupload. Mach n paar Tests wo der UL liegen sollte minimal bei ner 16 kbps Up Leitung und orientiere dich daran. MFG Stulle |
@stulle was ein glück das du das nicht bestimmen kannst |
Joa, sonst könntest nicht mehr so gut leechen, was¿ *OMFG* MFG Stulle |
da ich kein Powershare für partfiles hab und auch keine multiple friendslots brauch ich kein ratio das irgendetwas anders berücksichtigt als dies der offizielle emule tut. Den min Upload auf 11 heraufzusetzen ist eine logische Konsequenz, da der gesamte Overhead im Uploadlimit berücksichtigt wird (im offiziellen emule ist das ebenso, allerdings wird hier nur weniger als die hälfte des Overheads erfaßt). Falls jemand Einwände gegen das Heraufsetzen des min Uploadlimits hat oder irgendwelche Nachteile sieht so möge er sich melden ;-) |
Also ich find es sicher nicht schlecht, war nur ne Idee, weil ich eigentl. von der Funktionsweise die session based-ratios besser finde, da sie bis zu dem Punkt wo das Limit erreicht ist keine Limitierung mit sich bringt. Aber hey, du bist der Boss! Und vor allem weiß du wesentl. besser was du tust als ich! :D MFG Stulle |
Den min Upload auf 11 heraufzusetzen finde ich ok. der Upload läuft super, hatte noch nie so wenig fehlgeschlagene UL, lag sonst immer bei 4-6 %, beim original Muli ca. bei 15 %. Laufzeit 30 Std. Zitat:
|
lieber xman .. ich wäre dir wirklich sehr verbunden wenn du die kompletten src files endlich online stellen würdest ... (anstatt die unkompletten .. um es mal so zu sagen) :beer: Die src Files sind nicht komplett vorhanden .. aber sie sind vorhanden .. nur warum nicht komplett ..? Um eine abwendung deinerseits zu vermeiden .. ;) Ich würde denen Code nun gerne mal als Basis benutzen ... Am allerhellsten würde natürlich die Final vor meiner Nase leuchten ... |
Hi Xman, ich habe jetzt auch für ca. 3 Tage deine Alpha45 laufen lassen und nun ein paar Rückmeldungen über meine Beobachtungen dabei, auch speziell im Vergleich zum Morph Mod, den ich sonst meist einsetze. Alpha45 Muli läuft stabil, keine Abstürze oder Prozessorvolllastphasen trotz teilweise provozierender Rumklickerei in den Mulifenstern :-) , weniger Prozessorzeit- und Speicherverbrauch als bei Morph 6.7. Upload läuft stabil und hält sich weitestgehend an die Slotspeedeinstellung, solange man nicht zu dicht an die aktuell für den Muli nutzbare Uploadbandbreite stößt. Während ich bei 0-Down noch so 25,8 Upload einstellen konnte, ohne dass die Regelung versagte, mußte ich bei stärkerem Download das Uploadlimit doch was runterdrehen, sonst versagte die Regelung von Slotspeed und die Uploadlinien wurden sehr zackig. Bei ca. 50-Down auf 25 Uploadlimit und bis auf 24,5 UpLimit bei noch mehr Download, dann blieb auch der Upload gleichmäßig. Mir ist aufgefallen, dass in meiner 24 Stunden Dfü-Netzwerkstatistik die gesendete Datenmenge in den letzten 3 Tagen immer (egal ob mit max. Uploadeinstellung oder auf 25 begrenzt) ca. 50-100 MB geringer als an den Morph Tagen war, das ist doch ein spürbarer Teil meines täglichen Uploads. Auch die Uploadwerte in den Mulistatistiken waren etwas kleiner als beim Morph. Halte ich mal bei den nächsten Mulisessions mit anderen Mods genauer im Auge, ich bin halt ein Uploadfan, alles muss raus.:mrgreen: Download lief ebenfalls sehr gut für meine Verhältnisse, bei meinen geringen Quellenzahlen kann ich da aber nicht mit Rekorden dienen, obwohl rein subjektiv der Download vielleicht noch etwas besser als beim Morph war. Gefundene Quellenanzahl war jedenfalls vergleichbar zum Morph. Auch Download von einer mir schon länger bekannten problematischen (aber leider einzigen vollständigen) Quelle klappte. Aufgefallen ist mir die etwas mangelhafte Funktion beim "Download in alphabetischer Reihenfolge" innerhalb der Mulikategorien. Keine Ahnung ob das hoffentlich nur vom offiziellen Muli geerbt ist und nicht doch vom Xman-Downloadmanager stammt? Das tats jedenfalls nicht so toll, selbst vollständige Quellen für die alphabetisch erste Datei wurden oft bei weiter hinten liegenden Dateien als Quelle einsortiert. Auch die praktischen Ergebnisse waren mies, die ersten beiden Dateien wurden nicht fertig, aber welche mittendrin (gemäß alphabetischer Sortierung). Die Quellen waren im Prinzip für alle Dateien ähnlich, 2 vollständige für alle Dateien und ca. 30 Quellen insgesamt mit unterschiedlichem Stand je nach Datei. Alle Dateien wurden mit Prio Auto (Hoch) geladen. Im Morph verwende ich für die gleichen Dateien erst die Sortierung nach Alphabet, dann die Zuordnung der "Linear Priority" Werte für einzelne Dateien und die Download Methode "gestapelte Sourcen" , dann klappt die Quellenzuordnung ganz gut und auch das praktische Ergebnis überzeugt. Insgesamt gefällt mir dein Mod sehr gut, er ist auch gut für Anfänger geeignet oder Leute, die einfach nur downloaden wollen ohne sich groß mit speziellen Details beschäftigen zu wollen. :clap Ciao Rumpelzuck |
mensch.. das ist so viel... bevor ich jetzt weiterlese fang ich mal mit antworten an ;-) mein Mod untersützt gar kein "download in alphabetischer Reihenfolge". Die Quellen werden immer gleichmäßig(hohe Prioritäten bevorzugt) verteilt. Ich hab das Feature noch gar nie benutzt... muß sogar gestehen: noch gar nicht gefunden. Wo stellt man das denn ein ? Das muß ich nämlich noch entfernen. Zu Deinem Upload: Ich bin mir noch nicht sicher, ob ich die ACK-Packete richtig zähle. Leider konnte ich das noch nicht zu genau testen, da es dafür einen hohen Download braucht, was wiederum Zeit benötigt. Doch mein Mod läuft dank des vielen testens meist nicht länger als ein paar Stunden. Es sollte aber zumindest genauer funktionieren als Uploadreduction. Möglicherweise sind es aber gar nicht die ACK-Packete die zu wenig gezählt werden. Es gibt ein anderes Problem welches schwieriger in Griff zu bekommen ist: nehmen die Clients brav das gewünschte ab, so ist bei mir die gelbe Linie nur sehr wenig über der weißen. Ist aber ein oder mehrere problematische Clients dabei erzeugen diese zusätzlichen Overhead - die gelbe Linie wird zackig und ist wesentlich weiter von der Weißen entfernt. Hintergrund dafür ist, daß sich der interne Socketbuffer füllt und erst später recht viel auf einmal versendet, und das dann mit zusätzlichem Overhead. Das Problem dabei ist... sobald ich ein Packet in den Socketbuffer gestellt hab gilt er für emule als versendet und ich hab keine Kontrolle mehr darüber. Windows übernimmt dann die Kontrolle darüber und entscheidet wie und wann gesendet wird. Ich hab probiert den Socketbuffer zu verkleinern was den benannten Effekt verminderte. Allerdings geht das auf Kosten des Datendurchsatzes zu einzelnen Clients. Mit anderen Worten: eine höhere Slotspeed wird erschwert. Zu empfehlen ist eh eher eine kleine Slotspeed (nicht höher als 4kbs)... daher auch mein default-wert von 2.8 Generell besteht das Problem, daß emule nur auf OSI-Schicht 7 (Anwendungsschicht) arbeitet.. auf das Darunterliegende besteht kein Einfluß. So weißt Du in emule auch nicht, wieviele Retransmissions vorgenommen mußten, da die Packete fehlerhaft empfangen wurden. Bezüglich diesen 100MB welche Dir in Deiner DFÜ-Netzwerkstatistik fehlten kann ich Dir nur sagen: Du weißt nicht ob das Uploaddaten oder Overhead waren. Du weißt nicht mal ob TCP oder UDP, ob Retransmissions, ACK-Packete oder sonst irgendwas. Als Tipp: der offizielle emule hat noch einen deftigen Bug im zz-Downloadmanager bezüglich UDP-Filereaskpings... UDP-Packete zur Datei-neuanfrage sollten frühstens nach 28 Minuten emule-Laufzeit stattfinden. Schaust Du in die Statistik vom offiziellen emule wirst Du bereits nach einigen Minuten sehen, daß er UDP-Neuanfragen startet. Noch ein Tipp: der offizielle emule arbeitet mit doublesendsize. Das bedeutet, daß immer zwei Packete auf einmal versendet werden. Das soll eigentlich rein theoretisch den Overhead vermindern, da so nur ein ACK-Packet zurückgesendet werden muß. Tatsächlich vergrößert es bei mir allerdings den Overhead (gelbe Linie). Allerdings kannst Du damit eine höhere Slotspeed geben. Probier es selbst was bei Dir am besten funktioniert, doublesendsize oder einfache. Auch wenn ich momentan mit dem Upload des Xtremes wirklich zufrieden bin, es wird immer etwas zu verbessern geben. Edit: ok, hab den Code und die Einstellungen für Download in alphabetical Order gefunden. Da das mal ein Code ist der modular aufgebaut ist, sollte er sich eigentlich ohne weiteres in den Xtreme-Downloadmanager integrieren lassen. Das darfst du dann in der nächsten Version testetn ;-) Edit 2: Ich hab heute mal mit >180 kbs runtergeladen (danke an den Tipp @Paul2).. die ACk-Packete wurden hier definitiv richtig gezählt. Den Downloadmanager hab ich auch in manchen Teilen umgeschrieben... war doch mehr Aufwand als zunächst gedacht.. sollte nun aber auch mit linearer Prio funktionieren. |
Code: eMule v0.45b alpha4.5 Statistik [[MK.L]daenemark on x3alpha 4.5][edit by Pathfinder: Statistiken bitte auf's Wesentliche kürzen oder Code-Tags verwenden!] |
------------------------------------------- Kapitel 5 - Optimierungen der GUI - ------------------------------------------- new: - neben zahlreichen Optimierungen der GUI (z.b. IP to country) gibt es auch noch ein paar extra Features: - Powerrelease: + nur für komplette Dateien möglich + stark erhöhte Release Priorität: wenn weniger als 100MB oder das 1,5 fache der Filegröße geshared wurde, dann sehr sehr hohe Priorität, ansondern sehr hohe + für Powerreleasedateien gilt ein dynamisches HideOvershares. Es startet mit hideos=1. Sobald 2/3 aller chunks versteckt sind wird der Wert für HideOS automatisch erhöht - Xtreme Downloadmanager sollte nun auch mit download in alphabetischer Reihenfolge zurechtkommen - 11kb min Upload für unbegrenzten Download - weitere Änderungen im englischen changelog... und auch mit dem Auge sofort sichbar :wink: to test: - funktioniert das mit dem swappen richtig ? regeln sind: + Dateien mit hoher Downloadprio werden am meisten für A4AF-sourcen bevorzugt + bei Dateien mit gleicher Prio sollte einigermaßen gleichmäßig verteilt werden, es sei denn: + download in alphabetischer Reihenfolge ist eingestellt, dann gehts nach Alphabet - ansonsten ist alles zu testen... findet den letzten Bug! :wink: Anmerkung: sollte alles so funktionieren wie gewünscht wird dies die letzte alpha sein, bevor der große, allgemeine, internationale beta-Test erfolgt. Da inzwischen hunderte Dateien geändert sind, noch nicht alles sauber dokumentiert ist und es viel Arbeit macht den Quellcode zusammenzustellen, hab ich die sourcen für diese Version weggelassen. Wie gesagt, findet ihr keine größeren Fehler gibt es in ein paar Tagen die beta, selbstverständlich mit (wie früher auch) großen source-packet. Download: binaries changelog alpha5.0 - //Xman PowerRelease + only avaiable for complete files: + increased release-prio: if transfered <100MB or < 1.5 of filesize, very very high Prio, otherwise very high prio + dynamic hide overshares: start with hideos=1, after 2/3 of the chunks are hidden, hideos will be increased + (some parts of code from slugfiller) - added Xtreme Icons - MoNKi: -Fixed UTF-8 strings on web searchs - Preferences Fix (tHeWiZaRdOfDoS) - color LowID-clients in downloadlistctrl - min 11 upload for unlimited download! - // Mighty Knife: Static server handling (morph) - // - show requested files (sivka/Xman) - //Xman friendhandling from all windows - some rewriting of xtreme-downloadmanager to be compatible with categorie-handling of 0.45b - some codeimprovements in drawing of chunkbars - Fix For Incorrect Corruption Stats (netfinity) - fixed a bug in anti-leecher-log - //Xman process prio (parts of code from TPT) - IP to country (Eastshare/ morph) - // SLUGFILLER: searchCatch |
mal schauen, ob ich emule mal wieder laufen lasse; wenn ja nehme ich natürlich deinen. würde gerne weiter testen aber ich bin gerade an einer systemumstellung auf debian 3.1 .... naja viel erfolg :-) |
@drfreak2004 ich hoff Du hast bemerkt, daß ich Dein Feature-Request berücksichtigt hab ;-) |
wann rutscht dir endlich mal die final ausm sack ... manche leute habens nicht so mit dem warten ..... (ICH zB) Und .... Für dich gilt übrignes auch die GNU General Public License ... Wenn du die bin online stellst, müssen die vollständigen brauchbaren Sources dabei sein ... Sei es nun eine Testversion, eine Beta oder gar eine Final .... Jetzt hab ich ihn ;) greetz, evil |
lol, was soll das denn wieder¿ es ist reine freundlichkeit das xman überhaupt in diesem Stadium (pre-beta / alpha) Versionen zur Verfügung stellt! Hast du ein Problem damit, dass er nicht die sourcen released, niemand wird gezwungen diese Mod alpha zu nutzen, nicht mal du! Und davon abgesehen EastShare ist so gesehen eine etabblierte Mod (im Morph n eigenes Pref-Fenster) und hat zB für die Version 9.1 auch keine sourcen released weil es nur ne Test-Version ist. Und das war auch nicht das erste Mal (soweit ich weiß). MFG Stulle |
dazu kann ich nur immer wieder "GNU General Public License" sagen .. ^^ Das mit dem Sack war als "Weihnachtsman Geschenkesack" gemeint ... also wer das als beleidigung auffasst ... ;) ok stulle .. ich habe zawr respekt .. aber als analforscher werd ich mich desswegen nicht eintragen ... für alle gelten dieselben regeln .. und wenn Xman so nett ist und seine pre aplha/beta zur verfügung stellt, steht er hiermit auch unter der GNU General Public License .... diese besagt (wie gesagt), dass man die modifizierte source anderen benutzern frei zugänglich machen muss ... und wenn der Xman hier die programmdatei veröffentlicht, wird er wohl sicherlich auch keine probleme haben, dasselbe mit dem quellcode zu machen ... ich verstehs beim besten willen nicht! Ich finde seine Ideen erste Sahne ... Nun .. warum muss ich auf die Srces warten ..? Vielleicht gefällt mir der XTreme ja jetzt schon .... Außerdem - einmal stellt er eine nicht komplette src online .. und dann wieder gar keine .. das ist schon ziemlich verwirrend .. finde ich .. "KEINE SRCes VOR DER FINAL" (obwohl er mit der programmdatei allein viel mehr schaden anrichtet) Die src selber wird niemandem weh tun ... außer die beißt .. da kann ich dann auch nix für :) |
*kopfschüttel* ich glaub irgendwas geht hier zieml. verkehrt. soll ich nun mav auch die src zu meiner 1.0 pre mitschicken¿ wenn du n problem mit xman seiner politik hast, ignorier den mod, schnapp dir ne andere src, bau "ban gnu verletzer" ein, adde die xtreme alphas! typischer korintenausscheider... meine meinung! MFG Stulle PS: gl beim weiteren coden, xman, bin schon gespannt! |
1. ich sagte immer wieder: wenn jemand eine Datei der sourcen fehlt, soll er mir sagen welche, ich reich sie nach. 2. falls Du mal selbst einen Mod rausbringst, der einige tausend Änderungen beinhaltet, welche alle dokumentiert und getestet werden müssen, dann wirst Du es vielleicht begreifen, wieviel Arbeit es ist, sourcen zu veröffentlichen die als "ordentlich" eingestuft werden können 3. ich finde gerade das Zitat von Slugfiller nicht mehr... aber er antwortet auf die Frage warum er keine betas released sinngemäß: weil ein komplettes Release einen Arbeitsaufwand von einem Tag bedeutet. 4. Ich sehe dieses Posting nicht als öffentliches Release an, sondern als Test für eine kleine Benutzergruppe. 5. Lasse ich mir nur ungern ans Bein pinkeln... wir können das auch nächstes mal so machen, daß die alpha-Testversion nur einer wirklich geschlossenen Benutzergruppe zur Verfügung gestellt wird.. dann bekommst Du es erst gar nicht mit. 6. Steht in meinem Beitrag, daß ich die sourcen in ein paar Tagen veröffentliche... solltest Du soviel Geduld nicht aufbringen können, ist es Dein Pech. |
hier gehts ja wirklich arrogant zu ... für mich seid ihr .. "du und stulle" nix anderes als kleine kinderz die sich hier wichtig machen wollen ... wenn du emule modifizierst, musst du auch das befolgen, was vor langer zeit als grund baustein festgesetzt wurde .. und das ist nunmal die GNU General Public License. soll ichs buchstabieren ..? musste ja nur sagen .... Und nochmal .. es ist EGAL (E - G - A - L) ob du nun eine alpha .. eine beta .. eine gamma .. oder eine final release'st ... wenn du dies öffentlich machst (beispiel HIER) dann müssen die srces dabei sein! Und wenn die srces noch nicht soweit sind .. dann lass es auch ... ansonsten bist du nichts anderes als ein "leecher" der seine sources nicht online stellt ... ne sorry .. aber auf sowas wie euch habe ich absolut keinen bock ... anscheinend verfällt man mit seinem status auch der arroganz ... also .. mir ist es nun egal was mit euch passiert, wann ihr vereckt oder nen arm verliernt .. macht euren mist weiter, lasst die anfänger im glauben es wär alles in ordnung und gestaltet eure eigenene traumwelt mit viel zuckerwatte aber leider ohne sources ... in diesem sinne, verreckt alle ... mfg, evil ... PS: wer bock hat kann mich auch löschen .. wenn ich assoziale kinder sehn will fahr ich zur gerichtsverhandlung von michael jackson. |
OMFG, was bist du denn für n verdammter clown¿ Der einzige der hier arrogant ist, bist DU! Ja, du! Warum¿ Du hast die arroganz dich hinzustellen und sowas vom Stapel zu lassen. Nichtmal genügend Anstand um eine angemessene Wortwahl hier anzubringen hast du. Das ist doch echt arm! Das Kind bist eher du, also sonst wer. Und übrigens, ich kenne 15 jährige die weiter sind als du! Mit freundlichen Grüßen für alle anderen Stulle |
Zitat:
Ich gönn' ihm mal ein paar Tage Pause, bis dahin hat Xman auch seine Files in Ruhe sortiert. ;) |
Hi Xman, die A4AF Quellenzuordnung in Kategorien mit aktiviertem "Download in alphabetische Reihenfolge" klappt jetzt bei mir hervorragend, ich habe keine falsch zugeordneten Quellen mehr gefunden. A4AF Zuordnung nur nach Downloadprio und gleichmäßige Verteilung klappte bei mir schon mit der Vorgängerversion gut, aber ich probier nochmal beides aus. Aber mir ist doch noch was aufgefallen, ist aber harmlos: In den Statistiken für Total Overhead bei Up- und Downloadsessions steht immer eine ca. 10% größere Bytemenge drin, als die Summe der 4 Einzelwerte hergibt. Ähnliches gilt für die Paketanzahl. Meine klar formulierte Frage: Wat dat denn? :-o Ciao Rumpelzuck Code: eMule v0.45b alpha5.0 Statistics |
einfache Frage, einfache Antwort: wie diese Werte errechnet werden ist aus der offiziellen Version. Dort gibt es nicht nur die 4 besagten Kategorien, sondern eine fünfte "other". Alles was nicht direkt in Zusammenhang mit den 4 Kategorien gebracht werden kann, wird dann auf "other" dazuaddiert. (ein Beispiel: Das Packet OP_HELLO, welches bei jedem Zusammentreffen zweier Client ausgetauscht wird) Die Angezeigte Summe, ist die Summe aller 5 Kategorien. Freut mich, daß das alphabetical order nun geht. Wenn jetzt auch noch das alte gleichmäßige Verteilen geht bin ich zufrieden ;-) |
Die 5.0 läuft seit einem Tag ohne Probleme.A4AF funktioniert auch wie es soll.Und gut Aussehen tut er auch. :-) |
danke.. genau das wollte ich hören ;-) |
hi xman, ich habe 2 fragen zu der 5.0 1. bei mir stürzt sie immer nach einem neustart ab, auch nach einer kompletten neu-inst. ich habe keine aktiven downloads nur dateien die ich freigebe. (bei neuinst lasse ich diese auch komplett neu hashen) soll ich dir mal ein dgb zukommen lassen ? 2. bleibt das tray-menu so, oder ueberarbeitest du das noch (sieht naemlich shice :) aus) ansonsten, wenn ich sie nicht neu starte ist die mod super, thx. hf phiber |
ein dump wäre mir sehr wichtig. Ohne kann ich den Fehler nicht finden. was ist denn mit dem tray-menu? Eigentlich sollten nur ein paar Einträge weniger sein. Vielleicht kommen die auch wieder.. aber wenn dann im Xtreme 2.2 Style. |
hi xman, der dump ist unterwegs.. es muss irgendwas mit dem hashen der dateien zu tun haben, denn wenn ich die known(2).met loesche, kann ich sie stressfrei starten.. bis zum restart. @traymenu naja ich finde es koennte kleiner, also entsprechend der geringeren anzahl an eintraegen, sein. und die fette schrift nicht bei allen worten. einfach harmonischer fuers auge.. --- das auge zieht ja auch mit :D http://home.arcor.de/ruben.roeder/emule_tray.jpg phiber |
der bug ist bereits gefixt... eine Stunden vor Dir kam jemand mit dem gleichen Fehler... ein Wunder ist nur, daß der nicht schon seit der alpha 3.0 berichtet wurde. Es hat nur indirekt was mit dem hashen zu tun... dies scheint nur zu viel CPU-Power zu nehmen, so daß das bandwidthcontrol mit seinem Timing ins straucheln kommt... im schlimmsten Fall führt das zu einer Division durch 0. Dies wird nun abgefangen. Ok, das Tray-Menu hab ich auch noch etwas verkleinert. Wenn ich mal mehr Zeit hab, werd ich mich intensiver damit beschäftigen. Edit: ein paar Fehler im Posting gefixt |
thx.. dann warte ich bis zum naechsten release phiber |
Xman Werf mal einen Blick in den neuen eChanblard v8.0 8-) Januar |
sag mir doch mal wo ich den finde und warum ich den anschauen sollte !? |
[edit by Pathfinder: Link entfernt] ...oder eMulePower pur. Wenn ich das richtig sehe, baut er auf Deine 5.0 als Basis. Mich würde in diesem Zusammenhang interessieren, ob der MOD sauber ist. Das kann ich so nicht erkennen. Januar |
die 0.5 alpha wurde doch ohne sources released.... das geht doch also garnich oder hab ich was verplant¿ MFG Stulle |
eben.. es stimmt schon was stulle sagt. Auf der französischen Seite find ich mich aber gar nicht zurecht.. kann dort kein Wort verstehen. |
Zitat:
|
nee Pathfinder.. nicht alle.. nur bestimmte Versionen... verwende den morph Code ;-) Und noch danke fürs Avatar :yes: |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:12 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.