UPnP: demote routine LAN-discovery log lines from critical to debug - #627
Merged
mrjimenez merged 1 commit intoMay 15, 2026
Merged
Conversation
The SSDP discovery + service-walk paths log a handful of lines at
AddDebugLogLineC (critical -- always visible to the user), which on
busy home LANs fills stdout with messages the user can't act on:
- "Error retrieving device description from <url>: ..." -- transient
HTTP fetch failures from random LAN devices that announce via
SSDP but block HTTP from amule's subnet (mesh APs, multi-vlan
setups, IoT devices going offline)
- "Uninteresting service detected: '...'" -- emitted as amule walks
a downloaded description.xml; one line per service it doesn't
consume. Useful for debugging, noise for users
- "error(UPNP_DISCOVERY_ADVERTISEMENT_BYEBYE): ..." -- BYEBYE event
parse error, expected during LAN churn
- "Error getting SCPD Document from ..." / subscribe-error path --
routine, amule already retries
Demote those to AddDebugLogLineN. They stay accessible with
DebugLogTypes=UPnP enabled, but no longer surface to stdout for
users running the default log level. Keep user-actionable errors
(AddPortMapping/DeletePortMapping failures, "WAN Service not
detected" at port-map time) and success notifications (IGW
detected, SCPD retrieved, subscribed) at critical level so the
"is UPnP working?" UX is unchanged.
Reported by Stoatwblr in amule-project#622 -- a Zyxel mesh WAP that announces
SSDP rootdevice from a subnet whose HTTP is unreachable to amule
generated a steady stream of "Error retrieving device description"
lines. PR amule-project#623 already drops the per-leaf-service-NT noise; this
finishes the cleanup for the rootdevice case that amule-project#623 deliberately
lets through (rootdevice can't be classified without the XML).
Verified locally on macOS arm64: monolithic amule rebuilds clean.
Closed
|
That shut it up, thanks :) |
mrjimenez
pushed a commit
to mrjimenez/amule
that referenced
this pull request
Jul 27, 2026
…list (amule-project#627) Clicking a row on the download tab (and the shared-files / clients lists) tripped a debug-build assert: assert "!GetImageList(wxIMAGE_LIST_SMALL)" failed in OnGetItemImage(): List control has an image list, OnGetItemImage or OnGetItemColumnImage should be overridden. These lists own-draw their rows (OnDrawItem) but inherit a small image list from CMuleListCtrl. Once they moved to wxLC_VIRTUAL, wx started querying the per-item image while caching a line (on hit-test/click), and the generic wxListCtrl asserts when neither OnGetItemColumnImage nor OnGetItemImage is overridden. Release builds compile the assert out but still pay the pointless query. Override both in the base CMuleVirtualListCtrl to report "no image" (-1); the icons are painted by OnDrawItem, not by wx. Fixes it for all three virtual lists at once (download, shared files, clients).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The SSDP discovery + service-walk paths in
UPnPBase.cpplog a handful of routine lines atAddDebugLogLineC(critical — always visible to the user). On busy home LANs (mesh APs forwarding SSDP multicast but blocking HTTP, multi-vlan setups, IoT devices coming and going), these surface as a steady stream of warnings the user can't act on:Reported by @Stoatwblr in #622. PR #623 already drops the per-leaf-service-NT noise on the receive side; that intentionally lets
upnp:rootdeviceannouncements through because they're opaque from SSDP and amule has to fetch the XML to know whether the source is an IGW. When that fetch fails (which it will for any reachable-by-SSDP / not-reachable-by-HTTP device), the current code logs at critical level — wrong choice for routine LAN noise.Change
Demote 7 sites to
AddDebugLogLineN:"Error retrieving device description from ..."(UPnPBase.cpp:1285) — main spammer"Uninteresting service detected: '...'"(:607)"error(UPNP_DISCOVERY_ADVERTISEMENT_BYEBYE): ..."(:1363)"Error getting SCPD Document from ..."(:1761)goto error:path (:1768)Each remains accessible via
DebugLogTypes=UPnPfor actual debugging.Left at critical level (user-actionable / success notifications):
AddPortMapping/DeletePortMappingfailures — port-mapping can't succeed, user should know"Internet Gateway Device Detected"— confirms UPnP is working"WAN Service Detected"/"Successfully retrieved SCPD Document"/"Successfully subscribed"— once-per-router success milestonesValidation
macOS arm64: monolithic
amulerebuilds clean. No behaviour change — only log-level changes; the underlying discovery / port-mapping logic is unchanged.Refs #622.