View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017717 | MMW 5 | UPnP / DLNA | public | 2021-04-02 15:46 | 2021-04-28 09:19 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0017717: MM5 UPnP server often becomes inaccessible after MM5 is running for an extended period | ||||
| Description | Very 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 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2335 | ||||
| related to | 0011531 | closed | Ludek | MMW v4 | Server is not seen after resume from computer sleep for some users/client apps |
| related to | 0015000 | closed | rusty | MMW v4 | Sync: Device scan do not find MMW server |
| related to | 0012157 | closed | Ludek | MMW v4 | UPnP server stops after a while |
| related to | 0017770 | closed | Ludek | MMW 5 | Unresponsive window on clean install / crash 539F6172 |
| related to | 0017792 | closed | Ludek | MMW 5 | Crash EFEFFECD after 10 minutes of running (in some environments - regression 2335) |
|
|
There isn't enough info in the log to see why the server became inaccessible / undiscoverable. I enabled full logging in this UPnP.dll : https://www.dropbox.com/s/of85sv78qhiagn3/UPnP.dll?dl=0 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 http://127.0.0.1:<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 |
|
|
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. |
|
|
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 127.0.0.1 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. |
|
|
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 239.255.255.250:1900 and it should start to work again) Similar workaround we used in the past while solving 0011531 |
|
|
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. |
