Restart the client, keep your progress

Classic eMule forgets a great deal when it closes. eMule Qt writes the parts that matter to disk and puts them back: your download sources, the peers waiting in your upload queue, your Kad buddies and your statistics.

Download sources come back

Each download’s best sources are saved beside the part file and re-injected shortly after startup — up to 20 sources per file, kept for 24 hours, so the list survives an overnight restart rather than a coffee break. Sources are ranked best-first, with peers holding a part you still need at the top, and the list is topped up from the previous save so a source that has just gone quiet is not forgotten immediately. Because nothing is marked dead at startup, every restored source gets an attempt.

The practical effect: instead of waiting on a server source request or a Kademlia lookup before the first byte moves, the download reconnects to peers it was already talking to. Restored sources are tagged SLS in the Transfers and Clients panels, so you can see it happening. Every restored address is re-checked against the IP filter and ban list on load, since the file is untrusted input.

Your upload queue keeps its places

“Nothing is lost” is about the peers waiting in your queue. Neither official eMule nor the mods ever persisted the upload queue, so a peer that had waited two hours went back to zero the moment you restarted. eMule Qt stores the waiting list — with the wait time each peer had earned — and restores it, preserving the relative order. Times are written as elapsed seconds and rebased onto the live clock on load, which is what makes them survive a restart at all.

Restored peers are added to the list and deliberately not dialled, and the time you were offline counts towards “how long since we last heard from you” but not towards accrued wait time — you were down, so they were not really queued. Peers currently holding an upload slot are not stored; they return to the back of the queue and re-ask straight away.

Your place in other queues

The other direction is protected by the network itself. An uploader keeps a waiting peer for one hour after its last re-ask before purging it, and eMule Qt re-asks every 29 minutes. Since peers know you by your user hash, not by the connection, a restart costs you nothing as long as you are back and re-asking inside that window: at least half an hour, up to a full hour if you restarted right after a re-ask. The restored download sources are what make that work — they are contacted shortly after startup instead of after a fresh source search, so the re-ask arrives in time and you keep your place in their queue.

Kad buddies come back for firewalled clients

A firewalled client needs a Kad buddy — an open node that relays callbacks to it — or other firewalled peers cannot reach it. Free buddy slots are rare, and classic eMule starts every session with a fresh buddy search that usually asks the same full neighbours again. eMule Qt remembers the nodes that offered to be your buddy (up to 16, for 14 days, in kadbuddies.dat) together with whether the last session ended firewalled. If it did, the remembered buddies are asked right after Kad connects, most recent buddy first, instead of waiting for the first buddy search about five minutes in. They are also asked first at every later buddy search. A node that does not answer is dropped, and the early ask is skipped once eMule Qt finds you are open this time.

And your graphs

Statistics history is collected in the core rather than in the window, so your bandwidth traces survive a GUI restart, and two interfaces attached to one daemon see the same picture.

Back to all features