[fox88]

System health is not measured as uptime. Utilities chkdsk, dism and sfc should be used.

[mortbrad]

fox88, on 07 September 2024 - 06:19 PM, said:

System health is not measured as uptime. Utilities chkdsk, dism and sfc should be used.

Chkdsk is run semi-regularly, and the system is well maintained and up to date.

I have no stability issues including 2 older versions of eMule, so I wait until I get a minidump and you can tell me then if you think the system is to blame.

As of now this version is so unstable compared to 0.60 it's almost unusable, and it's already corrupted all the internal files because of crashing within 2-3 hours.

[Heliotropo]

My experience, however, is that version 0.70b and the previous one are completely stable. I have now spent more than 100 hours uninterruptedly with emule active. Most of the problems I had before have disappeared by improving my laptop and, in particular, the transmission speed of the main drive and peripherals (SSD, NVMe Sabrent, ports thunderbolt 4 at 40Gbps).

This post has been edited by Heliotropo: 08 September 2024 - 07:40 AM

[mortbrad]

fox88, on 07 September 2024 - 09:52 AM, said:

Upload dump to any file sharing service; the link could be given here or in PM.

I have a dump now but it seems I'm not allowed to PM or post the links, I guess I haven't posted enough to get around anti spam policies yet.

[theboss50]

@fox88: thank you very much for the v0.70b release !!!!

Unfortunately, despite the "GUI updates should be less hindered by high-speed download" change, new v0.70b GUI still hang when a file is downloaded at high-speed.

[mortbrad]

theboss50, on 17 September 2024 - 05:30 PM, said:

Unfortunately, despite the "GUI updates should be less hindered by high-speed download" change, new v0.70b GUI still hang when a file is downloaded at high-speed.

I've definitely seen this symptom, when downloading quickly GUI freezes, eMule is still using CPU but has no network or file activity and needs to be task killed to exit.

[theboss50]

mortbrad, on 20 September 2024 - 01:18 AM, said:

I've definitely seen this symptom, when downloading quickly GUI freezes, eMule is still using CPU but has no network or file activity and needs to be task killed to exit.

Not exactly: the GUI is frozen but almost always seems emule still works (tested only with MiniMule disabled), with file and network activity (no need to kill from more time)
I simply wait keeping emule minimized and at the end (when process has no more network activity) I can open GUI again and the file is downloaded correctly.
In last two versions the issue is a bit reduced (emule does not crash anymore) but it still happens always at high speed download (very boring).

This post has been edited by theboss50: 22 September 2024 - 06:36 PM

[awdrifter]

I hope you will add a LowID-to-LowID connection in future releases. I've been using eMule on and off for almost 20 years. Back then it wasn't really a big deal having LowID, because eMule was much more popular back then so HighID resources are much more available. But as the ed2k network dwindles, not having the ability to connect LowID to LowID really makes getting file much more difficult and it'll drive away even more users who are LowID. I think it'll soon get to the point where LowID to LowID connections are essential for sharing files on the ed2k network. More and more people are using 5G (home or mobile) internet and behind VPNs, so there will be a lot of users who are LowID and can't do anything about it. It's been 20 years, BitTorrent has figured this out, maybe eMule can copy their implementation and integrate it into eMule? I think it'll be a shot in the arm of staving off the decline for a little bit more.

[mortbrad]

mortbrad, on 08 September 2024 - 01:58 PM, said:

I have a dump now but it seems I'm not allowed to PM or post the links, I guess I haven't posted enough to get around anti spam policies yet.

I'm not sure at what point I may be able to upload or PM my crash dump, but I believe I have isolated the crash I see to only when the Transfers window is left open.

It seems if I go to servers window it doesn't crash. Seems there are other reports of GUI hang and unresponsiveness with fast downloads and I wonder if these are all related and something in the updating of Transfers window is the culprit.

[fox88]

Link is recognized by URL scheme; otherwise it is a plain text. Change the scheme.

[mortbrad]

fox88, on 25 September 2024 - 08:29 AM, said:

Link is recognized by URL scheme; otherwise it is a plain text. Change the scheme.

I'll figure that out, but I can confirm the crash I see is ONLY present if I leave the software running in Transfers window, runs for days and days if I change to another window.

Crashes within hours if I leave it on Tranfers window.