Slow retrieval of remote log file in aMuleGUI

[ghysler]

Upon launching aMuleGUI, the application retrieves the remote server log file and displays its content in the "aMule Log" tab on the Networks page.

I noticed that the retrieval (or at least the updating of the log file view) is very slow. After a server restart with ~10k download queue size, it takes about 5 minutes to catch up on the server log entries which are mostly about the 'part' files that are being loaded during server startup.
Every time aMuleGUI is restarted, it needs to process the old server log entries again, which is why I am seeing old log timestamps being processed.
My workaround for now is to clear the contents of the log file once by clicking the "Clear" button, which allows me to see new log entries instantly.

aMule 3.0.1 on Docker Linux 29.1.5
aMuleGUI 3.0.1 on Windows 11

[got3nks]

Thanks — this is the same family as #414. The "aMule Log" tab does still fetch the full log on connect (that's intended), but two things made it crawl on a big backlog: the daemon streamed it 200 lines per poll, and the GUI re-applied the text style and scrolled to the end on every single line with no batching. So ~10k "loading part file" lines became thousands of RichEdit reflows — hence the ~5 minutes with the window frozen. (Your "Clear" workaround empties the file, so there's simply no backlog to replay.)

Fixed in #451, keeping the full-log-on-connect behaviour:

• the daemon now sends up to 5000 lines per poll (was 200), so a big backlog drains in a couple of polls instead of ~50;
• the GUI coalesces each poll's lines into a single repaint + one scroll, and stops re-applying the text style per line.

If you'd like to confirm before it's in a release, here's a Windows amulegui with the fix — grab the portable .zip for your architecture, unzip, and run amulegui.exe against your server (you'll need to be signed in to GitHub to download):

• x64 (Intel / AMD): https://github.com/got3nks/amule/actions/runs/29158877982/artifacts/8250371927
• ARM64 (Snapdragon / Windows-on-ARM): https://github.com/got3nks/amule/actions/runs/29158877982/artifacts/8250350641

A before/after on your 10k queue would be great — it should now catch up in seconds instead of ~5 minutes.

[ghysler]

@got3nks
Thanks for the quick response again. Here are my test results with this fix release 3.0.1-152:

After switching to the Networks, it now takes about ~30 seconds to load ~2500 lines of log, so the speed seems about the same.

Also noticed during parsing of the log file, only the last line of the log is shown on top. The rest of the window stays empty until I scroll up. This does not happen on 3.0.1-135 (the fix release for #414)

[got3nks]

One clarification before you test — the fix is in two parts, in different binaries:

• The amuleGUI Windows build above fixes the rendering side (the per-line work that froze the window), so the log tab will be responsive again regardless of your daemon version.
• The delivery side (200 → 5000 log lines per poll) is in amuled. The log is fetched on the stats poll (~once every 3 s), so at the old 200-line cap a ~10k backlog still takes a couple of minutes to arrive — just no longer with a frozen GUI.

So updating only amuleGUI already removes the freeze (the worst symptom); the full "catches up in a few seconds" result also needs amuled patched. Both land together in the next release once #451 is merged. If you build your own amuled image from source you can test the daemon side sooner — the change is a one-liner in src/ExternalConn.cpp on that branch.

[got3nks]

#451 is merged — I tested it myself and the fix is working.

If you'd like to install the latest build (which includes the fix) on your Linux server, you can grab the AppImage/Flatpak packages from the packaging run. They're under the first run attempt (the summary page shows only the re-run macOS jobs):

https://github.com/amule-org/amule/actions/runs/29162037854/attempts/1

In the Artifacts section, use appimage-x86_64 or flatpak-x86_64 (or the -aarch64 variants on ARM).

Or, if you run amuled in Docker, you can wait for @ngosang's docker-amule develop image — it's built from master and refreshes every Monday, so after the next build (Mon Jul 13) docker pull ngosang/amule:develop will include this fix.

[ghysler]

Sorry, my bad. I looked over the change on the daemon side.

I will wait for the updated Docker developer image. Thank you for implementing and testing the fix.

[ghysler]

@got3nks
I have just updated my Docker instance to the new develop image and can confirm the retrieval of the remote log file is now very fast 👍

Though the regression with the log display remains. Every time a new line is added, the log window goes blank. I need to scroll up to restore the log display. Do you want me to create a new issue for this?

[got3nks]

Though the regression with the log display remains. Every time a new line is added, the log window goes blank. I need to scroll up to restore the log display. Do you want me to create a new issue for this?

I'm unable to reproduce this issue on MacOS. Does it happen after a reconnection or also during normal operation?

[got3nks]

Root-caused and fixed in #471 (now merged). It's a real regression from the #451 batching change, and Windows-specific: EndLogBatch() scrolled the log view to the bottom while the control was still frozen, and on Windows a frozen wxTE_RICH2 control doesn't repaint its visible region until you scroll manually — so it came back blank on each new line. macOS/GTK tolerate scroll-while-frozen, which is why I couldn't reproduce it. The fix thaws the control before scrolling.

No need for a separate issue — it's covered by #471.

A Windows build with the fix (portable .zip) is attached to this CI run:

• x64: https://github.com/amule-org/amule/actions/runs/29255538775/artifacts/8281537614
• arm64 (only if you're on an ARM Windows device): https://github.com/amule-org/amule/actions/runs/29255538775/artifacts/8281601071

Unzip and run amulegui.exe against your core, then watch the log tab during normal operation — new lines should append and stay visible without needing to scroll up.