[eMule-Web]
Seite 3 von 12 12 3 4567 Letzte »
40 Beiträge dieses Themas auf einer Seite anzeigen

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MOD - Development (http://www.emule-web.de/board/emule-mod-development/)
-   -   Xtreme Entwicklung - early alpha test thread (http://www.emule-web.de/board/9050-xtreme-entwicklung-early-alpha-test.html)

and 23. February 2005 07:01
hallo
2 MB minumim finde ich auch etws wenig ! ! !
vielleicht sollte jeder sellbst entscheiden indem man das min 2-7MB und das max 10-16MB selbst
einstellen kann
oder das gut verteilte Dateien min 2MB und max 10MB
und seltene Dateien min 7MB und max 16MB

Xman 23. February 2005 08:07
Zitat:
Zitat von and
hallo
2 MB minumim finde ich auch etws wenig ! ! !
vielleicht sollte jeder sellbst entscheiden indem man das min 2-7MB und das max 10-16MB selbst
einstellen kann
oder das gut verteilte Dateien min 2MB und max 10MB
und seltene Dateien min 7MB und max 16MB
das Minimum anders einzustellen bringt nichts! Stellst Du es z.b. auf 7 MB ein, so ist die Wahrscheinlichkeit sehr hoch, daß immer 9.32 MB gegeben werden, also gut 2 MB eines unvollständigen Chunks mit dem keiner etwas anfangen kann. Der Xtreme 2.2 arbeitete ja nach dem gleichen Prinzip und in der Praxis wurde bei deutlich weniger als 1% der Upload unter 4 MB beendet. Weniger gut verteilte Files müssen schneller an die Reihe kommen, ob von dessen Downloadern einmal einer einen halben Chunk mehr besitzt ist unerheblich, da er mit diesem nichts anfangen kann.
Die Option heißt: Full Chunk und nicht "special Amount"... und genauso wie sie heißt, das tut sie auch. Da das Verfahren nicht nur besser und fortschrittlicher ist, sondern sich auch bereits im Xtreme 2.2 bewährt hat -->Ende der Diskussion.

Edit: @aalerich: und wenn es Dir darum geht gerecht zurückzugeben was Du bekamst, das Xtreme Creditsystem sorgt dafür. Und noch was... fällt einer wirklich schon nach <4 MB raus, so hat er immer noch den Credit-Modifier des offiziellen emules von 3.3, was bedeutet er kommt eh bald wieder dran. Und zuguter letzt: der Xtreme ist wesentlich großzügiger beim Erlauben eines LOwID-Clients, in den Upload zu kommen.

Xman 23. February 2005 18:06
Kurzer Zwschischenstand: es geht voran... aber wie schon erwähnt ist der Einbau des Bandwidthcontrols ein großer Schritt, zumal es nicht nur ein Einbau, sondern an so manchen Stellen auch ein Umbau ist.
Was mir bei der Arbeit auffiel: Das OScope der offiziellen 0.44d (Diagramm der Statistik) ist 100% identisch dem vom Xtreme 2.x! :roll:

Hat vielleicht einer von euch mal irgendwo im changelog der des offiziellen emules (zwischen Version 0.30e und 0.44d), daß etwas aus meinem Mod, bzw. Maella übernommen wurde ?

Eine kleine Erwähnung wäre vielleicht schon ganz nett gewesen :dance :dance

drfreak2004 23. February 2005 18:20
ne aber schreib doch ornis+ mal an.. find des ne echte sauerei wenn es so ist !

ist doch eigentlich der codec der opensource gemeinde ! verwenden ja aber mit anmerkung zum urheber !

mav744 23. February 2005 18:27
Durchforste gerade die Changelogs, kann aber nichts versprechen. Aber was anderes, ein Bekannter wollte auch den Xalpha von hier herunterladen, er bekommt aber einen Fehler beim entpacken. Habe es dann auch mal probiert und es kamen die gleichen Fehlermeldungen, die ich beim entpacken des Xalpha 1.2 auch hatte. Könntest du dich wohl darum kümmern Xman?
Vielen Dank im vorrauss

Mit freundlichen Grüssen
mav744

Xman 23. February 2005 18:40
mav...
die Dateien liegen korrekt auf dem Server.. aber scheinbar überträgt der manchmal schlecht. Als Du leztztes mal nämlich das Poblem hattest, war der Fehler den ich machte, daß ich auf die Version 1.0 linkte, was ja falsch war. Du hattest also beim runterladen der 1.0 den CRC-Fehler, welchen Du einen Tag vorher nicht hattest.
Mit anderen Worten: Dein Bekannter soll es einfach paar Minzten später nochmal probieren. Wenn es ans "große Releasen" gehen wird, so werd ich über sourceforge releasen.

mav744 23. February 2005 19:21
So habe jetzt viele Changelogs gelesen von 30c-44d, wobei ich das changelog für die 42c nicht finden konnte.
Die Statistiken wurden des öfteren angepasst bzw. abschnitte hinzugefügt, aber von deinem Namen stand in den Changelogs, die ich gelesen habe, nichts. Ich erhebe keinen Anspruch auf vollständigkeit, da ich für einige mit Google nichts gefunden habe. Vielleicht solltest Du den Vorschlag von DrFreak beherzigen und Ornis+ einfach mal fragen, der muss es ja wissen.Und danke für die schnelle Antwort Xman, hat jetzt geklappt mit der Xalpha1.3 zu laden.

Mit freundlichen Grüssen
mav744

Edit:Habe mir alle Changelogs von 30c-44d (ausser 42c) auf emule-projekt.net mit der Suche herausgesucht, aber leider keine weitern Erkentnisse. :?

Xman 23. February 2005 20:04
@mav:
ich hab auch nichts gefunden.. auch keine credits an Maella. Hab bereits im offiziellen developement-Forum gepostet :wink:

Was ich noch gepostet hab: ich hab den Bug gefunden, warum Du auf einmal einen 0.45b[Xtreme2.2] hattest. Es ist ein Bug den alle Mods und auch die offizielle Version hat.
Gefixt.

drfreak2004 23. February 2005 20:41
hi zusammen,

da ornis+ auf emule-project sich nach zwei stunden noch nicht dazu geäußert hat, habe ich ihm eine pm geschickt. es kann meiner ansicht nach nicht angehen, einen so fähigen progra wie xman in dieser hinsicht so zu umgehen.

hier die pm:

"hi ornis+,

mit erstaunen stellte xman heute fest, das zitat "Das OScope der offiziellen 0.44d (Diagramm der Statistik) ist 100% identisch dem vom Xtreme 2.x" ist.

wäre es nicht angebracht xman und maella im changelog als urheber zu erwähnen ????

er war meiner ansicht nach sichtlich enttäuscht darüber ! opensource heisst zwar jeder kann das nehmen und verbessern was er braucht aber man sollte den urheber schon nennen !

ich würde mich freuen wenn du unter emule-web.de stellung beziehen würdest und das changelog geändert wird.

xman ist einer des besten modder die ich kenne und schätzen gelernt habe !

also fair play please ! "

xanthos 23. February 2005 21:00
Hi Xman @ all

Bin auch begeisteter Alpha Tester habe die ganze Zeit lang alles verfolgt. Doch nun muss ich mich auch mal endlich melden.
Habe da zwei Sachen gefunden weiß nicht ob sie wichtig sind für dich und eine bitte habe ich bzw. einen WUNSCH.

  1. " Category " sind es zuviele zb. 7 wie bei mir,kann man die ersten zwei RegKarten nicht mehr lesen wie kommt es dazu : schiebt man das Fenster auf Minimal Größe zusammen kommt die erste RegKarte sehr nah an die von dir hinzugefügten Sourcen und die Schrift ist weg!
  2. Die Anzahl der Angezeigten Sourcen im Transferfenster richtet sich nicht nach der Gesamtzahl der Sourcen sondern nach der jeweiligen RegKarte (Gesamtzahl aller Sourcen fände ich besser)
Meine Bitte oder Wunsch wäre einen selbst Wählbaren oder auch Fest eingestellten UDP-Port für den Kad habe da so meine Prob´s bezüglich meines Router´s.

Ansonsten macht der Alpha einen SEHR GUTEN EINDRUCK bei mir, bin gespannt wie sich das noch alles entwikeln wird. Melde mich gerne wieder wenn dies hilfreich gewesen ist


Mit freundlichen Grüßen
an alle Alpha Tester
xanthos

Xman 23. February 2005 22:27
@drfreak2004
nur keinen Aufstand machen... ich habs ja schon gepostet... und da es kein Feature ist, das ursprünglich von mir gecoded ist...

@xanthos
na dann scheint das Laben nun zu groß zu sein. Kannst Du mir nen Screenshot machen ? Das würde am schnellsten gehen.. ansonsten probier ich halt ein wenig rum.
Daß die Sourcen pro Kategorie angezeigt werden ist absicht, denn schließlich gibt es ja auch die Kategorie "alle"
An den Kad-Code wag ich mich eigentlich nicht ran. Falls Du aber einen Mod weißt, bei dem Dein Wunsch zuverlässig funktioniert, dann laß es mich wissen.

Ornis+ 23. February 2005 22:31
Nabend!

Ersteinmal sorry, falls dem so sein sollte, das größere Abschnitte verwendet wurden, ohne eine Anmerkung zu hinterlassen.

Creditkommentare würde es nicht grad als das Credo der Opensource nennen.
Aber wie oft im Code und in Changelogs zu sehen, hinterlassen wir Anmerkungen zum Author, wenn Fixes oder neue Abschnitte übernommen werden.

Schwer jetzt für mich aus dem Stehgreif die History nachzuvollziehen. Vielleicht kannst du identischen Code & Zeit ja genauer eingrenzen.

Soweit ich mich erinnere, wurde die OScopeCtrl zu den Anfängen der 0.2x ins Projekt genommen als ich die Statistik einführte und wurde fortwährend erweitert.
Unser aktuelles CVS geht "nur" bis Mai 2003 zurück. Wenn ich einzelne COmmits vergleiche (vor allem im 44b-c) Bereich, wurden immer recht lokale Änderungen vorgenommen, nichts was nach einer kompletten Integration aussieht.


Wie gesagt, wir halten üblicherweise die Credits. Sollte dies manchmal aus irgendwelchen Gründen doch mal untergehen, steckt dahinter keine Bosheit, Absicht oder Unhöflichkeit.

Dass zu dieser Zeit evtl du die Klasse vom Original übernommen hast, hast du sicher geprüft (soll ja auch vorkommen).

Was auch vorstellbar ist, dass eine Funktion von dir von einem anderen Mod übernommen wurde, wo wir dies dann übernommen haben. Aber steht dort der Ursprungsauthor drin, bleibt dies auch so.

Xman 23. February 2005 23:00
Ein Beispiel... das ganze OScopectrl steckt allerdings voll davon. Ich nimm aber ddieses Beispiel, weil man daran erkennt, daß selbst Maellas Kommentare übernommen wurden.
Ich weiß noch genau wie ich Maellas Code-Improvement studierte und in meinen damaligen Mod einbaute. Wirklich interessant, daß genauso wie ich es damals einbaute, es nun in der offiziellen Version drin ist.
Ohne jetzt böse sein zu wollen, möchte ich eigentlich nur, daß Ihr zukünftig wenigstens im Sourcecode vermerkt, von wem die Änderungen sind.

original 0.30c:
Code:
int COScopeCtrl::ReCreateGraph(void)
{
        int i;
        for(i = 0; i < m_NTrends; i++)
        {
                m_PlotData[i].dPreviousPosition = 0.0;
                m_PlotData[i].nPrevY = -1;
        }
 
        double *pAddPoints = new double[m_NTrends];
 
        int iCnt = m_PlotData[0].lstPoints.GetCount();
        for(i = 0; i < iCnt; i++)
        {       
                for(int iTrend = 0; iTrend < m_NTrends; iTrend++)
                {
                        POSITION pos = m_PlotData[iTrend].lstPoints.FindIndex(i);
                        if(pos)
                                pAddPoints[iTrend] = m_PlotData[iTrend].lstPoints.GetAt(pos);
                        else
                                pAddPoints[iTrend] = 0;
                }
                // -khaos--+++> Pass false for new bUseTrendRatio parameter so that graph is recreated correctly...
                AppendPoints(pAddPoints, false, false, false);
                // <-----khaos-
        }
 
        delete[] pAddPoints;
 
        return 0;
}
Xtreme 2.2 basierend auf 0.30c mit Maella Code-Improvement:
Code:
// Maella -Code Improvement-
int COScopeCtrl::ReCreateGraph(void)
{
for(int i = 0; i < m_NTrends; i++)
{
m_PlotData[i].dPreviousPosition = 0.0;
m_PlotData[i].nPrevY = -1;
}
 
double* pAddPoints = new double[m_NTrends];
POSITION* pPosArray = new POSITION[m_NTrends];
 
// Try to avoid to call the method AppendPoints() more than necessary
// Remark: the default size of the list is 1024
int pointToDraw = m_PlotData[0].lstPoints.GetCount();
if(pointToDraw > (m_nPlotWidth/m_nShiftPixels)+1)
{
pointToDraw = (m_nPlotWidth/m_nShiftPixels)+1;
}
int startIndex = m_PlotData[0].lstPoints.GetCount() - pointToDraw;
 
// Prepare to go through the elements on n lists in parallel
for(int iTrend = 0; iTrend < m_NTrends; iTrend++)
{
pPosArray[iTrend] = m_PlotData[iTrend].lstPoints.FindIndex(startIndex);
}
 
// We will assume that each trends have the same among of points, so we test only the first iterator
while(pPosArray[0] != 0){
for(int iTrend = 0; iTrend < m_NTrends; iTrend++){
pAddPoints[iTrend] = m_PlotData[iTrend].lstPoints.GetNext(pPosArray[iTrend]);
}
// -khaos--+++> Pass false for new bUseTrendRatio parameter so that graph is recreated correctly...
AppendPoints(pAddPoints, false, false, false);
// <-----khaos-
}
 
delete[] pAddPoints;
delete[] pPosArray;
 
// Draw the new graph without waiting on the next AppendPoints()
Invalidate();
 
return 0;
}
// Maella end
emule 0.44d
Code:
int COScopeCtrl::ReCreateGraph(void)
{
for(int i = 0; i < m_NTrends; i++)
{
m_PlotData[i].dPreviousPosition = 0.0;
m_PlotData[i].nPrevY = -1;
}
 
double *pAddPoints = new double[m_NTrends];
POSITION* pPosArray = new POSITION[m_NTrends];
 
// Try to avoid to call the method AppendPoints() more than necessary
// Remark: the default size of the list is 1024
int pointToDraw = m_PlotData[0].lstPoints.GetCount();
if(pointToDraw > (m_nPlotWidth/m_nShiftPixels)+1)
{
pointToDraw = (m_nPlotWidth/m_nShiftPixels)+1;
}
int startIndex = m_PlotData[0].lstPoints.GetCount() - pointToDraw;
 
// Prepare to go through the elements on n lists in parallel
for(int iTrend = 0; iTrend < m_NTrends; iTrend++)
{
pPosArray[iTrend] = m_PlotData[iTrend].lstPoints.FindIndex(startIndex);
}
 
// We will assume that each trends have the same among of points, so we test only the first iterator
while(pPosArray[0] != 0){
for(int iTrend = 0; iTrend < m_NTrends; iTrend++){
pAddPoints[iTrend] = m_PlotData[iTrend].lstPoints.GetNext(pPosArray[iTrend]);
}
// Pass false for new bUseTrendRatio parameter so that graph is recreated correctly...
AppendPoints(pAddPoints, false, false, false);
}
 
delete[] pAddPoints;
delete[] pPosArray;
 
// Draw the new graph without waiting on the next AppendPoints()
Invalidate();
 
return 0;
}

MaxUpload 24. February 2005 06:45
Hi Xman,

also ich habe zufällig ne Changelog History vom v0.27c bis zum v0.44d .
Sowas hat man eben als Modder N0oB :-) .

Dort fällt an verschiedensten Stellen der Name Maella.
Ich weiß nicht ob die strittige Stelle auch dabei ist,aber ich poste es einfach mal.

Zitat:
Zitat von Changelogs Original:
Changes from eMule v0.27c to eMule v0.28a
bluecow:Added small hex dump log output for unknown opcodes (Maella).

Changes from eMule v0.29b to eMule v0.29c

bluecow: Several small bug fixes and code improvements [Maella, dpr, rayita]

Changes from eMule v0.29c to eMule v0.30a

bluecow: Fixed bug with downloading of files with a size greater thean 2 GB [thx Maella]
Ornis: Fixed count of failed upload sessions [Maella]
Ornis: added Enhanced Chunk Selection, better selection which part of a file to download next [Maella & jicxicmic]
Zumindest sollte jetzt aber klar sein,daß ein nicht dokumentieren keine böse Absicht war. Warum sollten sie es sonst immer dokumentieren und in diesem Fall dann absichtlich nicht. Ich fänds unlogisch.

Hoffe ich konnte euch helfen etwas Licht in die Sache zu bringen.

MfG Max

Xman 24. February 2005 07:23
ich denke wir sollten das Thema Credits und OScopeCtrl abschließen.... bischen Wind aufgewirbelt wurde.. und nu is gut. Im übrigen hab ich den passenden changelogeintrag gefunden (finden lassen)

Zitat:
----------------------
- Jul, 31st 2004 -
----------------------

Unk: Did some merging from some Mods..
1) IRC gui updated.
2) Message gui updated.
3) Statistics gui updated.
So.. nun konzentrieren wir uns wieder auf die Xtreme Entwicklung.

drfreak2004 24. February 2005 10:33
moin zusammen,

vorschlag damit alle zufrieden sind.... alle wo das besprochene verwenden sollten in zukunft aus höflichkiet und ehrlichkeit im source wie im changelog einfach in klammer maella/xman reinposten und dann ist alles ok.

will ja keinen streit oder so sondern nur das man bei der auswahl seines esel sehen kann wer welche funktion gemacht hat. damit kann man sich dann danach aussuchen welche version man nimmt.

mfg und auf weitere tests !

mav744 24. February 2005 16:30
Wenn ich den Mod komplett beende, z.B. durch Neustart des Rechners, dan muss ich meine Einstellungen für das Transferfenster sowohl Upload als auch Download neu machen ( Übertragebe Dateien, u.s.w. ausblenden). Die Einstellungen werden nicht gespeichert, weiss aber nicht genau ob das im Originalen 45b auch so war, da Xman ja bisher nur den Upload neu programiert hat, denke ich das aber mal. Ist mir vorher noch nicht passiert, da ich ja nicht alzu oft neu starte (Es sei den, meine Kinder drücken einen der zwei berüchtigten Schalter).

Mit freundlichen Grüssen
mav744

MaxUpload 24. February 2005 17:16
@ Xman ...recht haste.

@drfreak2004: Solte man sowieso immer machen,damit man die entsprechenden Stellen auch schnell wieder findet. Brauch man dann nämlich nur ..Suchen ->Projekt-> Xman ;-) [Enter]

Der Rest ist ehrensache und selbstverstänldich...für mich zumindest.

Xman, hast du mal nen Tip für mich? Bei mir hat selbst der compilierte Source des Originalen v0.45b eine viel zu hohe CPU -Last. Kann es sein,daß ich beim compilieren schon was falsch mache oder ist das normal. Liegt so bei 29-60%...ich dachte es liegt an meinen Modifikationen,aber scheint so das Problem liegt woanders.

MfG Max

Xman 24. February 2005 18:19
@maxupload:
ehrlich gesagt bin ich etwas überfragt, warum Deine compilierte Version so viel CPU verbrät. Mit welchen libaries ich kompilierte steht auf der erste Seite.
Einen Optimizer würd ich nicht verwenden. Ich selbst werde ich wohl auch rausschmeißen. Der Grund ist einfach: der Optimizer bringt nur etwas, wenn große Blöcke im Speicher bewegt werden. Mit großen Blöcken meine ich MB! emule bewegt aber meist nur 16 Byte, manchmal 64 Byte. Hier braucht emule länger um die Daten der aufrufenden Funktion auf den Stack zu legen und anschließend wieder runterzuholen, als wenn man gleich das normale memcpy verwendet. Ich habs selbst getestet.
Versuch doch mal z.b. die sourcen von unclebob (im emule-project developement support) zu kompilieren, so rein testweise obs dann schneller läuft. Später, wenn beta version, werd ich von meinem Mod das komplette "one klick to compile" - source-packet bereitstellen.

@mav:
wäre mir schon wichtig zu wissen, ob das a) nur einmal auftrat oder immer b) auch in der original Version

@all:
es geht voran, aber gemählich. Ist einfach verdammt viel was geändert werden muß.

mav744 24. February 2005 18:58
Ich habe versucht, den Fehler zu reproduzieren, also sowohl den original 45b als auch den Xalpaha mehrmals neu gestartet, als auch einen Rechnerneustart. Der Fehler trat nicht wieder auf, was ich zwar komisch finde, aber ich kann es leider nicht ändern. Kann es sein das die Einstellungen erst beim beenden gespeichert werden? Anders kann ich es mir im Moment nicht erklären, da eines meiner Kinder den Resetknopf benutzt hat.

Mit ratlosen Grüssen
mav744

aalerich 24. February 2005 21:14
Das pasiert bei mir auch sporadisch. Mit verschiedenen Mulis, aber sehr selten. Dann rutscht z.B. die Spalte "Fertiggestellt" hinter die Spalte "Fortschritt", obwohl sie eigentlich zwei Spalten weiter vorn hingehört. Woran das liegt weiß ich nicht, da es aber immer nur einzelne Kleinigkeiten sind habe ich mir darüber nie den Kopf zerbrochen. Das ist also nicht so, als wäre die halbe ini-Datei kaputt.

Die Ursache muß jedenfalls schon lange und in allen Mulis drin sein. Danach zu suchen lohnt aber meiner Meinung nach nicht.

Mit freundlichen Grüßen
aalerich

mav744 24. February 2005 21:30
Es ist mit halt das erste mal aufgefallen. Ich hatte das Problem auch noch nie. Ich habe schon gedacht ich spinne oder bekomme Verfolgungswahn, aber da du aalerich das auch schon hattest, bin ich ja beruhigt.Desweiteren habe ich es ja auch erst bei der Xalpha bemerkt, deswegen habe ich es hier gepostet, aber scheint wohl ein allgemeines Problem zu sein, nicht Alpha spezifisch (schweres Wort, hoffentlich richtig geschrieben).

Mit dankbaren Grüssen
mav744

Xman 24. February 2005 22:25
also mit dem Xtreme 2.2 hatte ich das Problem noch nie. Ich werde aber mal beim testen ein Auge drauf werfen.

Edit:
grad las ich erst Mavs Posting auf der vorherigen Seite: ja, bestimmte Einstellungen werden erst beim beenden gespeichert. Welche das konkret sind, darüber hab ich mir noch nie den Kopf zerbrochen.

mav744 24. February 2005 22:46
Dann könnte es daran liegen, da ich emule ja sehr lange laufen lasse (versuche 24/7), ohne neu zu starten (sowohl den Mod als auch den rechner). Das bedeutet das, ich nen Mod starte, einstelle und laufen lasse und ich hatte diesen Fehler noch nicht bisher (allerdins auch keinen reset zu der Zeit, hatte meistens Frei ;) ). Ich schiebe es jetzt mal auf den unfreiwilligen reset meiner kinder :mad: . Falls der Fehler noch mal auftritt und ich ihn reproduzieren kann poste ich ihn.

Mit freundlichen Grüssen
mav744

EDIT:aalerich, lach nur, aber ich könnte meine Kinder deswegen manchmal zum Mond schiessen :oops: :beer:

drfreak2004 24. February 2005 23:37
jungs lese ich das richtig bei euch hat sich auch die verbindungseinstellung ohne eigenes zutun verstellt... bzw nach neustart ???? schaut mal etwas weiter vor ! bei mir war das au.... aber ohne neustart. in früh emule angeschaut und ich dachte ich spinne alles verstellt :-(

also is doch ein fehler im code vom 0.45, oder ?!

mav744 25. February 2005 06:23
@DrFreak: Bei mir werden zwar nicht die Verbindungseinstellungen wie bei Dir verstellt, sondern nur die einstellungen für das Transferfenster (Anordnung der Informationen). Den Fehler den Du hattest, hatte ich bisher noch nicht, aber ich konnte den Fehler bisher auch nicht reproduzieren, genau wie Du. Wenn es bei mir wieder auftritt, hoffe ich das ich dan anwesend bin, und nicht auf der Arbeit, damit ich eine genauere Aussage treffen kann, bzw. den fehler genau reproduzieren kann.

Mit freundlichen Grüssen
mav744

aalerich 25. February 2005 07:24
Auch bei mir waren das immer nur "kosmetische" Sachen wie Spaltenbreiten und -anordnungen. Wichtiges wie Verbindungseinstellungen sind nicht betroffen gewesen. Deshalb finde ich das auch nicht sooo dramatisch. Man schiebt es halt wieder passend und gut...

Mit freundlichen Grüßen
aalerich

MaxUpload 25. February 2005 16:26
Also die allgemeine Vorgehensweise der Originalen wäre folgendermaßen...

1) Beim Erststart des Mulis wird gecheckt ob die INI Dateien vorhanden sind. Wenn keine vorhanden sind werden sie erzeugt und mit Standartwerten initialisiert. Dannach wird der Wizard aktiviert um die Grundeinstellungen in der Preferences.ini vom User vornehmen zu lassen. Dies geschieht auch,wenn nur die Preferences.ini fehlt.

2) Wenn die Dateien existieren und nicht beschädigt sind werden sie nach dem erstmaligen Initialiseren im Regelfall nur noch durch die PPg-Dialoge und Veränderungen (z.B. verschieben der Spalten im Transferfenster per Maus) durch den User manipuliert und entsprechend bei OnApply (Übernehmen,Enter,OK) oder beim Beenden gepeichert.

Interessant wäre jetzt zu wissen,ob sich bei euch die Fensterpositionen wieder auf den Erststart Zustand zurückgesetzt haben,oder ob die Spalten Konfiguration eher zufällig ist? Und natürlich welche Spalten davon konkret betroffen sind? Ich hatte z.b. schon das Problem,daß ich während des Betriebes die Werte nach belieben verändern und speichern konnte und nach einem Neustart siehe da waren die Init Werte wieder aktuell.

MfG Max

mav744 25. February 2005 16:45
Bei mir haben sich die Einstellungen des Transferfensters auf den Erststartzustand gesetzt

Mit freundlichen Grüssen
mav744

MaxUpload 25. February 2005 17:08
Hmmmm.....aber der Wizard wurde nicht aufgerufen,oder?

MfG Max

mav744 25. February 2005 17:14
Nein, wurde er nicht.

Mit freundlichen Grüssen
mav744

MaxUpload 25. February 2005 17:23
Das würde darauf hin deuten,daß die Pref.ini vorhanden war. Der Teil in dem die Transferfenster Daten gespeichert wurden war entweder nicht mehr vorhanden (evtl. wird er bei unkorrektem Beenden gelöscht oder war defekt...müßte man mal nachschauen) und dann beim Neustart von Emule einfach die Standartwerte drüber geschrieben wurden.

MfG Max

Xman 25. February 2005 17:26
ich will ja nichts sagen.. aber dieses Thema gehört eigentlich nicht hierher.. da es sich um ein allgemeines emule-Problem handelt.

PS: es geht voran... aber es ist wirklich sehr sehr viel zu ändern.

MaxUpload 25. February 2005 17:49
Hmmm...wollt ja nur helfen...sorry.

Also hier mal was aktuelles von mir zum Alpha1.3...

Cpu Last 0-5%,UL 9-10 kb/s,DL 80-95kb/s nach 19h59min....bei UL 12kb/s und DL 115Kb/s

mit einer TDSL1000 Leitung.

Kann ich ja eigentlich direkt aufhören mich noch weiter mit dem Thema zu beschäftigen und einfach nur den Xtreme Mod benutzen,denn besser geht es ja wohl kaum noch.

MfG Max

mav744 26. February 2005 17:37
Hier jetzt ne stats von mir nach 4 Tagen und 17 stunden

Code:
eMule v0.45b Statistik [mav744]

Transfer
  Session UL:DL Ratio: 1 : 3.52
  Session UL:DL Verhältnis (ohne Freundesupload): 1 : 3.61
  Gesamte UL:DL Ratio: 1 : 3.29
  Uploads
      Session
        Hochgeladen: 1.59 GB
        Hochgeladene Daten durch Freundesuploads (Session): 42.42 MB
        Aktive uploads/nötig um Bandbreite auszunutzen: 4
        Gesamtanzahl der Uploads: 7
        Wartende Uploads: 2994
        Upload Sessions: 431
        Totaler Overhead (Pakete): 133.77 MB (2.46M)
      Gesamt
        Hochgeladen: 3.95 GB
        Upload Sessions: 1187
        Totaler Overhead (Pakete): 311.29 MB (5.83M)
  Downloads
      Session
        Heruntergeladen: 5.59 GB
        Beendete Downloads: 22
        Aktive Downloads: 24
        Gefundene Quellen: 4346
        Download Sessions: 1902
        Durch Komprimierung gewonnen: 227.85 MB (4.0%)
        Durch Datenfehler verloren: 27.83 MB (0.5%)
        Teile gerettet durch I.C.H: 0
        Totaler Overhead (Pakete): 116.18 MB (2.76M)
      Gesamt
        Heruntergeladen: 12.99 GB
        Beendete Downloads: 60
        Download Sessions: 4356
        Durch Komprimierung gewonnen: 409.93 MB (3.1%)
        Durch Datenfehler verloren: 68.58 MB (0.5%)
        Teile gerettet durch I.C.H: 2
        Totaler Overhead (Pakete): 265.41 MB (6.46M)
Verbindung
  Session
      Allgemein
        Erneute Serververbindungen: 5
        Aktive Verbindungen (geschätzt): 161 (Halb:2 | Komplett:40 | Andere:119)
        Durchschnittliche Verbindungen (geschätzt): 170
        Verbindungsspitze (geschätzt): 316
        Verbindungs-Limit erreicht: 0
      Upload
        Upload-Geschwindigkeit: 9.62 KB/s
        Durchschnittliche Uploadrate: 9.91 KB/s
        Max. Uploadrate: 13.76 KB/s
        Max. durchschnittliche Uploadrate: 9.95 KB/s
      Download
        Download-Geschwindigkeit: 70.19 KB/s
        Durchschnittliche Downloadrate: 34.85 KB/s
        Max. Downloadrate: 142.21 KB/s
        Max. Downloadrate Durchschnitt: 34.85 KB/s
  Gesamt
Zeit Statistiken
  Letzter Reset der Statistiken: 21.02.2005 23:15:09
  Zeit seit letztem Reset: 4 Tage 18:16 Stunden
  Session
      Programm-Laufzeit: 1 Tage 22:42 Stunden
      Übertragungszeit: 1 Tage 22:42 Stunden (100.0%)
      Dauer auf aktuellem Server: 10:39 Stunden (22.8%)
      Dauer auf Servern: 1 Tage 22:38 Stunden (99.9%)
  Gesamt
      Programm-Laufzeit: 4 Tage 17:47 Stunden
      Übertragungszeit: 4 Tage 17:44 Stunden (100.0%)
      Dauer auf Servern: 4 Tage 17:28 Stunden (99.7%)
Läuft super stabil, keine hohe Cpu Last und der Speicherverbrauch liegt bei mir im Schnitt bei 70 MB. Ich habe im moment sehr hohe Downloadraten, und dadurch sackt der Up ziemlich ein vorallendingen auch durchs nebenher surfen, muss ich wohl noch ein wenig feintuning machen. Thx Xman für den Xalpha.

Mit freundlichen Grüssen
mav744

Xman 26. February 2005 17:48
aber nochmal:
wenn die Version gut läuft, dann liegt das nicht an mir... es ist noch alles ganz offizieller Code... lediglich die Uploads werden etwas anders verteilt. Darum nochmal: bitte keine Statistiken posten, die im moment noch 0 aussagekraft haben.

Xman 27. February 2005 17:13
kurzer Zwischenstand:
die Arbeit ist eigentlich gemacht.. er läuft auch gut.. Upload schön stabil (laut DU-Meter und laut Anzeige im Transferfenster). Einzig und alleine der Uploadgraph ist mir noch zu unruhig. Darum werd ich noch ein wenig dran basteln. Denke aber es dauert nicht mehr lange bis die nächste alpha erscheint

Xman 2. March 2005 15:38
Kapitel 2
Integration von Maella-Bandwidthcontrol
-------------------------------------------
Anmerkung: Ich bin alles andere als glücklich mit dieser Version! Obwohl der Upload laut DU-Meter eigentlich ok ist, so ist die Uploadkurve eine Katastrophe! Wem das nichts ausmacht, der kann gerne testen. Seit ca. einer Woche arbeite ich täglich 12 Stunden daran, die Uploadkurve in den Griff zu bekommen. Doch was ich auch versuche hilft alles nichts. Auch der phoenix-Mod mit Maella-Bandwidthcontrol hat hier ein Problem. Leider finden ikabot und ich die Ursache nicht.
Sollte uns beiden kein Licht aufgehen, so werd ich wohl das Bandwidthcontrol wieder entfernen und nochmal die Arbeit von Neuem beginnen, unterbrochen von einer "Frust-Erholungsphase".

new:
- bandwidthcontrol

totest:
- Statsitiken überprüfen:
- Farbeneinstellungen, Zeiteinstellungen der Graphen, verschieben der Graphen
- alle Werte des Statistiktbaumes auf Plausibilität überprüfen
- alles überprüfen was man mit der Statistik machen kann (kopieren, zurücksetzen usw.)

- Webserver, Mobile emule zeigen richtige Werte ?
- Ist der Download ok ? (verglichen mit dem offiziellen emule oder letzten alphas)
- zu viele / zu wenig uploadslots ?
- Stabilität ?

- hints:
no stable upload-graph !

Download: binaries & sources

This version is buggy! Don't repost it on other boards!

changelog:
x3alpha2.0
- save the decimal of maxup/download
- // Maella -Accurate measure of bandwidth: eDonkey data + control, network adapter-
- // Maella -Support for tag ET_MOD_VERSION 0x55
- // Slugfiller: modid
- don't accept uploads if no internetconnection (to be tested)
- Threadsave Bandwidthcontrol (not sure)
- many codechanges
- reworked statistics (few parts taken from TPT)

mav744 2. March 2005 18:19
Hallo Xman,

Zitat:
Xman
- Statsitiken überprüfen:
- Farbeneinstellungen, Zeiteinstellungen der Graphen, verschieben der Graphen
- alle Werte des Statistiktbaumes auf Plausibilität überprüfen
- alles überprüfen was man mit der Statistik machen kann (kopieren, zurücksetzen usw.)
Habe alles überprüft, es funktioniert alles so wie es soll.

Was mir weiterhin aufgefallen ist, im mini mule wird der overhead für den Upload nicht angezeigt. Wenn du jetzt so etwas wie Quickstart eingebaut hättest, hätte ich sogar ne erklärung für den astronomischen overhead in der ersten halben Stunde, desweiteren ist der upload im allgemeinen nicht so stabil wie in der Xalpha 1.3, sofern ich das nach ca.einer stunde beurteilen kann. Im vergleich zur Xalpha 1.3 schwankt er doch sehr stark laut den Anzeigen im emule, werde es aber weiterhin beobachten und mich nocheinmal melden. Die Einstellungen sind im übrigen die gleichen die ich auch im Xalpha 1.3 genutzt habe.

Mit freundlichen Grüssen
mav744

Xman 2. March 2005 18:36
@mav
wie Du bereits lesen kannst, weiß ich, daß die Uploadkurve sehr instabil ist. Bitte nicht mehr mit der Vorgängerversion vergleichen... schließlich ist die Berechnung eine völlig andere.

Der "astronomische" Overhead ist allerdings als korrekt anzusehen. Wie ich schon öfter erwähnte: das Bandwidthcontrol addiert auch den TCP/IP, UDP-Header. Die Menge die an Overhead verbraucht wird, ist aber zur offiziellen Version identisch, denn hier wurde (noch) nichts geändert.

Danke für den Tip mit Minimule.. werd ich mir anschauen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:40 Uhr.
Seite 3 von 12 12 3 4567 Letzte »
40 Beiträge dieses Themas auf einer Seite anzeigen

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102