[eMule-Web] - eMule v0.47c StulleMule v4.5 [14.02.2007]

[eMule-Web] (http://www.emule-web.de/board/)

- eMule MODs - Allgemein (http://www.emule-web.de/board/emule-mods-allgemein/)

- - eMule v0.47c StulleMule v4.5 [14.02.2007] (http://www.emule-web.de/board/11465-emule-v0-47c-stullemule-v4.html)

Diese Symptomatik hatte ich einige male mit einem älteren MorphXT-Derivat gehabt. Zweimal hatte ich zuvor Arbeitsspeicherintensive Anwendungen laufen gehabt, und sehr viel am System gearbeitet. Manchmal beendete sich der Morph schon nach 30 Minuten oder einer Stunde betrieb. Repruduktionsversuche verliefen alle erfolglos.

An den Arbeitsspeicher hab ich auch schon gedacht, der Bedarf am Ram wird immer größer desto länger eMule läuft, zZ ca 380MB. Ich habe 1GB im Rechner, sollte also kein Problem sein....

Zitat:

Zitat von Jok3r

@Pan Tau hatte ich falsch verstanden, thx! :D

Das hatte ich irgendwie auch vermutet.
Ist ja nun ausgeräumt das Missverständnis, Prost! :beer:
@ Catweezle: Da hab' ich dann wohl nicht genug zwischen den Zeilen gelesen, na ja was soll's.

Zum Thema neon-gelb schwarz: Könnte es sein das unser liebes Muli wegen seiner schlechten Rechenkünste -> siehe Statistik > Festplattenplatz sich dann und wann mal so sehr verkalkuliert das ihm selbst 100GB zuwenig sind?

Pan Tau

Hallo!
Ich muss sagen, dass die 4.0-er Version wirklich ordentlich läuft.
Allerdings habe ich einen Verbesserungsvorschlag.
Die A4AF Funktion ausm Scar Angel ist -zumindest bei mir- um längen schneller, als die vom StulleMule. Vielleicht kannst Du sie ja im nächsten Mod hier implementieren. Das wäre super.
Grüße
ScOoZ

meine msn adresse ist meine mail addi. bitte dumbs da hin!

@ scooz: am a4af sind keine änderungen geplant, seh ich keinen großen nutzen bei enorm erhöhter arbeit momentan.

@ Stulle:

Ich habe das Problem auch mit den ganzen letzten Morph-Versionen gehabt... jetzt gerade die 9.1... einfach selbst beendet über Nacht...
Irgendwann ab der 8.5 wurde das mal eingeführt und ist seitdem nicht mehr verschwunden... sie beenden sich einfach immer wider von selber ohne eigenes zutun... echt schade....

Und damit wieder endgültig zurück zur 8.5... :cry:

mfg,
Catweazle

Das Problem mit dem Beenden kenn ich irgendwo her. Heute Morgen an den Rechner gekommen und was muss ich sehen? Ausnahmefehler. Das ist mir nun schon ein paar Mal passiert.
Habe nun mal den 9.1-er Morph angeschmissen. Mal schauen, ob es am Morph Code liegt oder an Deinem.
Und noch eine Frage.
Wenn ich den Stulle in die Taskleiste minimiere, dann erscheint auf dem Desktop ein kleines Übersichtsfenster. Ist das der "Mini-Mule"?

Greetz
ScOoZ

Ja, das ist Mini in modifizierter Form, den Schwachsinn kann man seit eMule 0.47c zum Glück bequem unter Optionen/Allgemein deaktivieren.

Das Problem mit dem Absturz hab ich bei Stulle leider schon seit geraumer Zeit. Wenn die Mod mehrere Tage läuft kommt es manchmal vor, dass der ganze Rechner schlagartig neustartet. Die Festplatte geht dabei kurz aus. Ist mir kürzlich erst wieder passiert, deswegen hab ich die Mod wieder gekickt. Abstürze jeglicher Art habe ich normalerweise nie.

Ausschalten kann man den. Das stimmt. Aber bei der Morph 9.1 kann man den nicht einschalten. Es erscheint leider nichts aufm Desktop.

du mußt ihn manuell öffnen beim morphxt. beim stulle gibt es in den tbh MM optionen den punkt "öffnen bei minimieren" oder so ähnlich.

mfg stulle

Zitat:

Zitat von Stulle

du mußt ihn manuell öffnen beim morphxt. beim stulle gibt es in den tbh MM optionen den punkt "öffnen bei minimieren" oder so ähnlich.

mfg stulle

Und wie kann ich das machen? Nur so als Info gedacht. Brauchen tue ich den nämlich eigentlich nicht...

einmal mit der linken maustaste auf das muli-symbol inb der taskleiste klicke... ;)

mfg
myth88

Zitat:

Zitat von Verlierer

Das Problem mit dem Absturz hab ich bei Stulle leider schon seit geraumer Zeit.

Beim Stulle ist bei mir seit 3.6 und höher dieses Phänomen noch nicht untergekommen, aber öfters beim Magic Angel und auch gelegentlich beim MorphXT. Das blöde ist: Ich kann machen was ich will, ich bekomme es nicht reproduziert.
Vielleicht ist es einfach eine Kollision auf der Datenleitung die eMule zum "aufgeben" zwingt.

Zitat:

Wenn die Mod mehrere Tage läuft kommt es manchmal vor, dass der ganze Rechner schlagartig neustartet.

Bei mir beendet sich nur der eMule-Client, die Internetverbindung bleibt offen.

Zitat:

Die Festplatte geht dabei kurz aus.

Tritt bei mir nicht auf.

Zitat:

Ist mir kürzlich erst wieder passiert, deswegen hab ich die Mod wieder gekickt. Abstürze jeglicher Art habe ich normalerweise nie.

Achte doch mal darauf was du vorher am System gemacht hast. Vielleicht fällt dir was auf und du kannst den Fehler reproduzieren.

Also ich konnte den 4er ziemlich sicher crashen, wenn ich aus der Shared Files Liste eine Datei gelöscht habe, wo jemand gerade im Up war...

Deshalb habe ich dort eine Prüfung eingebaut, die alle ausm Up und der Queue für dieses File schmeißt, bevor das gelöscht wird. Etwa so:

Code:

BOOL CSharedFilesCtrl::OnCommand(WPARAM wParam, LPARAM /*lParam*/)

...

BOOL delsucc = FALSE;

theApp.clientlist->RemoveClientsOnQueueForThisFile(myfile); //check for clients on queue or d'ling when file is deleted

if (!PathFileExists(myfile->GetFilePath()))

...

Code:

void CClientList::RemoveClientsOnQueueForThisFile(CKnownFile* delfile) //check for clients on queue or d'ling when file is deleted - 1018

{

    int iNumQueue = 0;

    DebugLog(LOG_MORPH, _T("Removing all clients on queue for file '%s'."), delfile->GetFileName());

    for (POSITION pos = list.GetHeadPosition(); pos != NULL;) {

        CUpDownClient* client = list.GetNext(pos);

        if (client->CheckAndGetReqUpFile() == delfile) {

            if (client->IsDownloading()) {

                theApp.uploadqueue->RemoveFromUploadQueue(client,_T("File deleted by user;"), true, true);

                iNumQueue++;

            }

            else if (theApp.uploadqueue->IsOnUploadQueue(client)) {

                theApp.uploadqueue->RemoveFromWaitingQueue(client, true);

                iNumQueue++;

            }

        }

    }

    DebugLog(LOG_MORPH, _T("Removed %i clients."), iNumQueue);

}

Der overhead selbst bei tausenden in der queue ist minimal im Vergleich zur gewonnenen Sicherheit, finde ich.

Wenn ich mich recht entsinne, gab's vorher immer 'ne Exception in file->GetUpPriority() in CUploadListCtrl:: DrawItem. Deshalb habe ich da zu Beginn noch sowas wie

Code:

try { //try to avoid crash on removed file

        file->GetUpPriority();

    }

    catch (...) {

        if (client)

            theApp.uploadqueue->RemoveFromUploadQueue(client,_T("File exception during upload;"), true, true);

        if (file && !PathFileExists(file->GetFilePath()))

            theApp.sharedfiles->Reload();

        return;

    }

eingebaut. Das half im Test sogar immer wieder gegen das Löschen oder Verschieben im Dateiexplorer, ohne daß der Muli davon weiß. Was ja eig. kein vernünftiger Mensch macht. Und da ich vernünftig bin (http://mitglied.lycos.de/SDT62/web/heiligenschein.gif), habe ich es eben nur ein paar mal getestet und kann nicht garantieren, daß der Muli sich trotzdem nicht noch an anderer Stelle verabschiedet bei solch infamen Aktionen.

Für mich ist der StulleMule - schon immer, und auch deshalb nehm ich ihn ja - einer der crashsichersten Mulis überhaupt. :clap

erstmal danke für deine code vorschläge. denkst du, dass wir dann nicht auch im morphxt so arbeiten sollten oder passiert das nur im stullemule¿ im übrigen hab ich es auch schon manchmal gemacht und das einzige was dann passierte war, dass statt dess dateinamen nun "?" da stand und der client rausflog sobald der buffer leer war.

danke auch nochmal für's lob.