Expose "View Files" (browse peer shared files) results over EC for amuleGUI/amuleweb/amuleapi

[ghysler]

Attempting to "View Files" of ED2k users in the aMuleGUI application shows these log entries:

2026-07-10 14:54:16: User xxx shares directory 'eMule'
2026-07-10 14:54:16: User xxx shares directory '!Incomplete Files'
2026-07-10 14:54:33: User xxx sent sharedfiles-list for directory 'eMule'
2026-07-10 14:54:33: User xxx sent sharedfiles-list for directory '!Incomplete Files'
2026-07-10 14:54:33: User xxx finished sending sharedfiles-list

However, the retrieved file listings can not be viewed anywhere within the application. I would expect the results to show up as a new tab in Searches, but nothing appears there. I tried requesting the files from multiple users over the course of multiple days, but the behavior is the same every time.

aMule 3.0.1 on Docker 29.1.5 Linux
aMuleGUI 3.0.1 on Windows 11

[got3nks]

Thanks for the detailed report, @ghysler — you've actually found the exact boundary of the feature. "View Files" (browsing a peer's shared files) is currently monolithic-only: it isn't wired through the External Connect protocol, so amuleGUI, amuleweb and amuleapi can't display the results.

What's happening under the hood: amuleGUI does send the request to amuled over EC, and the daemon carries it out — that's why you see the sent sharedfiles-list / finished sending lines (those are the daemon's own log, relayed to your GUI's log view). But the daemon stores the returned listing in a per-client bucket that the EC search-results response never serializes, and the code that creates the "user (N)" tab under Searches is compiled only into the full aMule client, not amuled. So the data arrives at the daemon and simply has nowhere to go over EC.

So this isn't a config issue or a regression — it's a missing capability in the remote-GUI path. In the meantime, running the monolithic aMule (not amuled + amuleGUI) will show the file listing in a Searches tab as you expected.

I'll re-file this as an enhancement: surfacing browsed file lists over EC so amuleGUI/amuleweb/amuleapi can display them. No firm timeline, but it's a reasonable gap to close.

[got3nks]

Good news, @ghysler — this is now fixed and merged (#520).

"View Files" is wired through External Connect: amuleGUI, amuleweb and amuleapi now show a browsed peer's shared files as a tab under Searches (with an incremental progress bar), exactly where you expected them. The listing travels over EC as its own search, keyed to the peer.

One detail that matters for your setup (amuled in Docker + amuleGUI on Windows): the feature is capability-gated, so both sides have to be on the new build — a new amuleGUI talking to an old amuled simply falls back to the old no-tab behaviour. So there are two pieces to update:

• amuleGUI (Windows): available from the Windows packages of the latest build — ARM64 · x64.
• amuled (the Docker daemon): the daemon needs updating too. ngosang's Docker image with the new daemon is expected to land Monday (2026-07-20); once it's published, pull the updated image.

With amuleGUI and amuled both updated, browsing a user's files will show the listing as a Searches tab.

[ghysler]

Fantastic work @got3nks !
I did not expect this to be implemented before the next stable release, so this is a really nice surprise :)

Excited to test this once the new Docker developer image lands tomorrow. If any issues arise, I will let you know.

[ghysler]

@got3nks
I just did some testing with the new builds. First off: the feature works properly. Thank you again for implementing this.

One small regression found:

After right clicking on a row in either the Shared Files list (top) or Client list (bottom), after ~2-5 seconds all clients disappear from the Client list (bottom) - sometimes a few rows remain visible. The context menu shows and keeps working, but the clients are just invisible. Left clicking anywhere else in the Shared files panel restores the Client list again.

Other observations:

1. Requesting the file list of the same client twice in a row, with the previous result tab still present in the Search panel, will not switch to the related Search tab
2. Requesting the file list of the same client twice in a row, duplicates the file list in the previous result tab (assuming the file list did not change)
3. Selecting multiple clients and right-clicking still gives the option to "View Files", but this does not result in any action

For 1) and 2) combined, my preference would be that the user will be sent to the previous result tab after requesting the file list of the same client twice. This way the user is reminded that the request was already processed. Only after the previous result tab is closed by the user, the file list request should be sent to the client again. This also prevents the file list from being duplicated in the same result tab.

For 3) I guess the "View Files" option should be greyed out, when multiple rows are selected.

I would be happy to create new issues for any of these, if required.

[got3nks]

@ghysler Thanks — precise report, and the disappearing client list is the one I want to nail first.

This turns out to be the same family as #478. The bottom Client list is the same custom-drawn list control, and on Windows a Freeze/Thaw refresh can leave the just-updated rows unpainted until a scroll or click forces a repaint — which is exactly why left-clicking brings them back. The #478 fix only covered scrolling and keyboard navigation; this is the same bug reached through the periodic/async data refresh instead, so it slipped through. On your remote setup the peer data arrives a couple of seconds after you click, so the blank lands right after the right-click.

Here's a test build with the fix — portable .zip, just unzip and run amulegui.exe, no install:

• Windows x64 (your arch): download
• Windows ARM64: download

This one is GUI-only — no daemon change — so you can point it straight at your current Docker amuled; no need to wait for a new image. (It's built off today's master, so it also carries the View Files feature.)

If the client list stays visible through the right-click and the async refresh that follows, that confirms it.

On your other three observations — the same-client re-request not switching to the existing tab (1), the duplicated file list (2), and "View Files" doing nothing on a multi-selection / not being greyed out (3) — those are all real and worth doing, but they're separate from the repaint bug. I'd like to keep this change focused on the ghost entries and handle 1–3 as a follow-up. No need to open separate issues unless you'd rather track them that way; I've got them noted.

[ghysler]

@got3nks Good morning :)
Thanks for the attempt at fixing the disappearing client list.

Just performed some tests with the provided build. Unfortunately the issue remains. Though on average, it now takes ~15 seconds before the client list disappears. Sometimes still within a few seconds, sometimes almost 30 seconds.

[got3nks]

Thanks for the detailed testing, @ghysler — that feedback was really useful. A fair bit has landed since those builds:

On what you found:

• Clients disappearing from the bottom list a few seconds after right-clicking — fixed in Virtual-list GUI lists: live column sorting + fix blank paint under open menus #540. It was a wxMSW repaint issue: while the context menu holds the event loop, the list's layout is only recomputed on idle, so any row-count change under the open menu left it painting blank until you clicked away. It now recomputes immediately, so it no longer blanks with a menu open.
• (1) + (2) View Files not switching to the existing tab, and duplicating the list — addressed in fix(gui): make View Files switch to an open browse tab and browse each selected peer #539: requesting a peer's files now switches to the already-open browse tab instead of opening a second/duplicate one.
• (3) Multi-select "View Files" doing nothing — also fix(gui): make View Files switch to an open browse tab and browse each selected peer #539: selecting several clients and choosing View Files now browses each selected peer.

Other improvements in this area since your test:

• The Shared Files, Downloads and Clients lists moved to a virtual-list model (scales to 100k+ rows) with live column sorting — rows re-order as their values change (Virtual-list GUI lists: live column sorting + fix blank paint under open menus #540).
• The statistics panel under the shared files (Requests / Accepted / Transferred) was corrected: it shows the selected file's real per-file numbers, the bars are meaningful again, it works in every "show clients" mode, and it updates instantly on selection, including multi-select (fix(gui): correct the shared-files statistics panel #543).
• Browsing a friend's shared files was fixed too.

Could you give it another run? A fresh Windows amuleGUI build is attached to the CI packaging run for this merge (scroll to the Artifacts section) — grab windows-installer-x64, or windows-installer-arm64 if you're on ARM: https://github.com/amule-org/amule/actions/runs/29826817453. Connect to your daemon and let us know whether the blanking and the View Files behaviours are sorted, plus anything else you spot.

[ghysler]

This build does not launch on Windows 11 x64. The amulegui process crashes after launch.
Rolled back to 3.0.1-205 for now.

From Windows Event Viewer:

Faulting module name: amulegui.exe, version: 3.0.1.1, time stamp: 0x6a5f5b6c
Exception code: 0xc0000005
Fault offset: 0x00000000001ceef0
Faulting process id: 0x5D2C
Faulting application start time: 0x1DD1908FF8A8BB3
Faulting application path: C:\Program Files\aMule\bin\amulegui.exe
Faulting module path: C:\Program Files\aMule\bin\amulegui.exe
Report Id: 3b3a5c3e-6046-4957-bff7-069d6ab534df
Faulting package full name: 
Faulting package-relative application ID: