View Issue Details

IDProjectCategoryView StatusLast Update
0017717MediaMonkey 5UPnP / DLNApublic2021-04-28 09:19
Reporterrusty Assigned To 
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0017717: MM5 UPnP server often becomes inaccessible after MM5 is running for an extended period
DescriptionVery often, if MM5 is running for an extended period of time (between 12 and 24 hours), the UPnP server becomes inaccessible and MMA is unable to sync. This does not occur consistently, but I've observed it 3 times when testing over the past week (4 times if 0017716 is related).

1 Run MMW5
2 After 12 hours (PC did not go to sleep), in MMA > Options > sync settings [Pixel 2 xl]
--> Connection failed! error. MMA log J28MH5717G
3 in MMA (and BubbleUPnP), attempt to connect via UPnP
--> Server is unavailable (i.e. not listed)
4 in Windows Media Player (running on the same desktop), check for MediaMonkey server
--> Server is not listed
5 Disable Windows firewall (around line 5050 or 5100 in the debug log) and perform steps 2, 3, 4 again
--> Same results (connection failure / server not listed)
6 Re-enable windows firewall and then restart MMW5 (line 5166)
7 in MMA > Options > sync settings [Pixel 2 xl] (line 8642)
--> Connection
8 in MMA (and BubbleUPnP, and WMP), attempt to connect via UPnP
--> Server is listed
TagsNo tags attached.
Fixed in build2335


related to 0011531 closedLudek MediaMonkey 4 Server is not seen after resume from computer sleep for some users/client apps 
related to 0015000 resolvedrusty MediaMonkey 4 Sync: Device scan do not find MMW server 
related to 0012157 closedLudek MediaMonkey 4 UPnP server stops after a while 
related to 0017770 closedLudek MediaMonkey 5 Unresponsive window on clean install / crash 539F6172 
related to 0017792 closedLudek MediaMonkey 5 Crash EFEFFECD after 10 minutes of running (in some environments - regression 2335) 



2021-04-03 11:15

developer   ~0062677

Last edited: 2021-04-03 11:22

View 2 revisions

There isn't enough info in the log to see why the server became inaccessible / undiscoverable.
I enabled full logging in this UPnP.dll :
So please replace your current UPnP.dll by the downloaded one and perform another test.
Note that the DbgView will be very verbose this time (because of the UPnP full logging).

Once the issue appears again then try to access<server port>/DeviceDescription.xml (as step 5.1) -- so that we know whether the issue is related to SSDP discovery or whether the server is really down.
And also please perform step 5.2: Check whether the WMP server is seen by MMA/ Bubble UPnP


2021-04-13 14:44

administrator   ~0062810

Last edited: 2021-04-13 15:03

View 7 revisions

This morning, the bug occurred!
- MMA/BubbleUPnP failed to connect to configure WiFi Sync or to see the UPnP server (even after the firewall was disabled)
- Similarly WMP failed to see the server with the firewall disabled
- After the above tests, I generated a devicedescription file as requested and then tried connecting to the UPnP server again via MMA/BubbleUPnP (unsuccessfully).
- After restarting MM5, WMP sees the UPnP server

Tested with build 2333 + custom UPnP dll (logs sent to Ludek)
MMA log ID: E7AD13Q4IF

Note: what's different in today's test vs the past couple of days is that I performed a wifi sync operation prior to running the test (during the same MMW5 session). The sync operation was successful, so I guess that upon completion of the sync operation or sometime after, something related to the wifi sync operation triggered an issue with the UPnP service.


2021-04-14 19:27

developer   ~0062816

Last edited: 2021-04-14 20:34

View 5 revisions

In the log I see
- WiFi sync was performed after 2 hours of logging
- after 8 hours of logging suddenly SSDP M-SEARCH request stopped to come (until then MM5 received M-SEARCH every 2 seconds in your network environment)
- after 20 hours of logging you requested DescriptionDevice.xml from

Traversing code in UPnP.dll and I still not see exact reason what went wrong after 8 hours that caused M-SEARCH to stop receiving.
Nevertheless I am preparing a workraound for detection that something has broken and restarting (rebind socket) of correpsonding part (SSDP listen task).
In my environment MM5 receives M-SEARCH every 10 seconds (every 2 seconds in your case) -- so something like detecting the interval runtime and use it as detection for a need to restart the SSDP listen task should work.


2021-04-15 10:18

developer   ~0062830

Last edited: 2021-04-15 10:19

View 3 revisions

Fixed in 2335.

If we don't receive a single M-SEARCH request for 30 minutes then SSDP listen task in UPnP.dll is re-started (i.e. the multicast UDP socket is re-bound to and it should start to work again)
Similar workaround we used in the past while solving 0011531


2021-04-21 10:38

developer   ~0062896

Verified 2238

Test was done on L3 Switch by deliberately dropping incoming M-SEARCH requests to PC but allowing outgoing. After 31Min UDP is rebound.

We will see if we need to lower that from 30 Min.