View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011774 | MMW v4 | DLNA/UPnP | public | 2014-01-21 22:42 | 2014-04-29 12:41 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1.1 | Fixed in Version | 4.1.1 | ||
| Summary | 0011774: Intermittent failure to find MMW Server | ||||
| Description | Failure to find the MMW server seems to be a recurring problem--sometimes it'll work, and then later it won't: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75117 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=74733 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75164 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75120 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75008&start=15#p381963 Besides the above, there are also other complaints of this in the Play store. The only thing that seems to have helped some users is to restart MMW and reboot the device, but that workaround shouldn't be required if it's an MM problem. Any ideas? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1700 | ||||
| related to | 0011531 | closed | Ludek | MMW v4 | Server is not seen after resume from computer sleep for some users/client apps |
| related to | 0011925 | closed | Ludek | MMW v4 | Media Server stopped after hibernation |
| has duplicate | 0011741 | closed | marek | MMA | Going back to file list from server duplicates list |
| related to | 0011381 | closed | marek | MMA | Documentation: Some users can't see MMW UPnP server |
| related to | 0011971 | feedback | rusty | MMW v4 | MediaMonkey fails to terminate (1697) |
|
|
From what I read from the forum posts it really seems that the reasons are various (as is usual in home network enviroment) For some users disconnecting/reconnecting to WiFi helped, for another user connecting to different AP helped, for another user reboot of AP helped, for another user changing MMW port helped, for another user phone reboot helped, for another MMW restart and phone reboot helped. We can hardly cover them all and issues like this are common (e.g. I also need to restart my router on occassion, but this is general network issue not related to MMW). Therefore we should solve by a good troubleshooting KB article covering all possible reasons/workarounds/solutions. Also writing that "restart MMW and reboot the device" helped is no information for us. So what helps phone reboot or MMW restart? Is MMA the only app that cannot see the server or all android apps doesn't see MMW server? If all android apps, do they see other servers on network? Is MMW server invisible by all devices or just by the phone (that needs reboot?) ? |
|
|
I have changed logging of connection process to see whether MMA discovers at least any upnp devices in this situations (build 222). |
|
|
In build 222, logs from cling upnp library are stored too. So we will be able to see all upnp search messages that might be helpful in this case. We will be able to see what devices are communicating with MMA. |
|
|
New logs posted. See: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75117#p382703 |
|
|
I have discovered that this is an Android bug on ICS devices. There is a same exception in same situation in the log. Re. google groups there is no way how to workaround it. It was fixed in JB 4.2 MR1. It is caused by 3 digits interface index. This way a parsing error occurs. This kind of index is not common and occurs in specific situations only. It is not clear when. I think that the interface gets another index on device restart. https://code.google.com/p/android/issues/detail?id=34022 |
|
|
Also, another related issue point out by Marek that can affect ICS users: https://code.google.com/p/android/issues/detail?id=33661 |
|
|
I have received new log from LowLander. According this log there, MMA doesn't see MMW because of failure during parsing of DeviceDescription.xml. This is probably the situation when restart of MMW helps. Cling reports following UPnP violation in UPC field: DeviceDetails: UPnP specification violation, UPC must be 12 digits: 00000-00001 UPnP specification: UPC Optional. Universal Product Code. 12-digit, all-numeric code that identifies the consumer package. Managed by the Uniform Code Council. Specified by UPnP vendor. Single UPC. I've looked at my DeviceDescription.xml and this field is missing. It is optional. Do you know any way how it can occur there in such format ? |
|
|
MMW doesn't add UPC to DeviceDescription.xml, as discussed offline with Marek, it was most probably another media server on the network. |
|
|
From another log, I see that there might be some freeze in parsing of response. It is not the same issue, because server was visible but browsing failed. I have added some logs to build 229. |
|
|
LowLander, could you please send me new logs, when you observe this situation. I will check logs of other users, that I will receive meanwhile. |
|
|
Another possible instance from a longtime user: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=75634 |
|
|
It seems to happen when another DLNA server is selected. 230 is slow to show server content when that is done (switching between DLNA servers). I did get a connection failed, but saw that Windows reconnected to the network (only PC to do so). This seems to be very coincidental. After reconnect I just got a black screen selecting the MediaMonkey server, next attempt showed content. (log send from MMA). |
|
|
Re. mcow issue, I would like to summary my research. I am quite clueless what is wrong and I don't know whether it is possible to fix here anything. Maybe you will have some idea. 1. mcow doesn't see MMW server in MMA. - I can confirm that by examination of log. The only messages from PC's IP are M-SEARCH messages that are most probably sent by MMW. No response on MMA's M-SEARCH is received. - At the beginning MMA sends M-SEARCH messages to discover other devices. The structure is following: M-SEARCH * HTTP/1.1 MX: 3 MAN: "ssdp:discover" HOST: 239.255.255.250:1900 ST: ssdp:all According UDA 1.1 it is ok. This message is sent 5 times (according UDA 1.0 it should be sent more than once) with 500 ms delay (UDA 1.1 recommends few hundred milliseconds). 2. He can see other upnp devices on network in MMA - I can confirm that too. I can see response and processing of device description of his NAS. 3. he claim that can see MMW in UPnPlay application - I've examined the M-SEARCH message of UPnPlay app. And it is similar: M-SEARCH * HTTP/1.1 ST: upnp:rootdevice MX: 3 MAN: "ssdp:discover" HOST: 239.255.255.250:1900 - the difference is that they specify the search target as upnp:rootdevice, i.e. they search only for root devices that is a subset of our ssdp:all. - they send it only once but it is against UDA recommendations. Btw. for connecting to selected device, we use following M-SEARCH to search only devices with entered uuid. But it doesn't filter the devices anyway: M-SEARCH * HTTP/1.1 MX: 3 MAN: "ssdp:discover" HOST: 239.255.255.250:1900 ST: uuid:de94ab6c-721b-46a1-fd2f-be1c6e54eeac So the only thing I can do is to adjust the "ST" filter. I don't know whether it is possible that MMW won't respond on ssdp:all but responds on upnp:rootdevice. I will create new build with changed ST. I have reduced the number of M-SEARCH messages to 2. I will send it to mcow. |
|
|
I can replicate this as follows: 1) Set MMW to run mediasharing as a service 2) Close MMW 3) Initiate Wi-Fi sync via MMA to make sure that it works as expected 4) Make PC go to sleep (I set this via the power options > Advanced settings > so that I could manually trigger sleep by pressing the power button) [5) Initiate Wi-Fi sync (This step isn't necessary) --> MMW server can't be found as expected since the PC is asleep] 6) Wake the PC, and initiate Wi-Fi sync OR attempt to browse the server with BubbleUPnP --> MMW server can't be found!! Upon running services.msc, it seems that the reason for the problem is that although the MediaMonkey Service is set to Automatic, for some reason it doesn't always restart when the PC wakes from being asleep* 7) Run MMW 8) Initiate Wi-Fi sync or browse via BubbleUPnP --> Server can be found again 9) Terminate MMW, and Initiate Wi-Fi sync --> Sync works *I suspect that the issue occurs whenever the PC awoken from sleep mode, but the user has not logged in (since the MediaMonkeyService is configured to run as .\<Username> , and typically, the system is configured to lock out the <Username> whenever the system goes to sleep). That would explain why the service isn't automatically restarted--but I'm not sure that it explains why it was terminated. EDIT: My hypothesis is wrong. Sometimes, the MediaMonkeyService is running, and even when it is, the server can't be found. i.e. the repro steps above are accurate, but I'm not sure why. I'll upload MMW debug logs to the ftp server in case they're of use. EDIT2: No debug logs uploaded since they're useless (MMW doesn't log anything for the MediaMonkeyService). |
|
|
Unfortunatelly so far I haven't been able to replicate, despite the account is password protected (or not), the server starts to work immediatelly after wake up even if I haven't typed my account password, i.e. without logging into the account (as expected). Tried sleep, hybrid sleep, hibernation, all worked fine. Tested on Win7 x64, Rusty tested on Win 8.1 Solving with Rusty via IM. Note: If one wants to catch debug log for the service, need to run DbgView as admin and check menu Capture -> [x] Global Win32 |
|
|
Generated debug log, however, I doubt that it contains anything useful: 3 Initial sync: Line 4210-14840 4 Terminate mmw: Line - 15634 5 Sync using service: Line 15635 - 26251 6 7 8 Restart and sync using service: - 27332 8 2nd attempt to sync using service: nothing at all was logged (despite the fact that task manager shows both MediaMonkeyService and MediaMonkey running. Log posted to ftp |
|
|
As found over IM with Rusty, reverting 0011531 solves the issue, solving further... |
|
|
Fixed in build 1699 (to be confirmed by Rusty) |
|
|
Confirming fix using steps from 0011774:0039933 I confirmed on two devices Nexus 7 and LG L5 |
|
|
@Peke, Note that you tested 1698, but it was fixed in 1699 so I guess it needs to be confirmed by the users+Rusty (who could replicate) in 1699. |
|
|
Tested build 1699 and this still isn't working. i.e. Sync when MMW is running: works Sync when MMW has been terminated: works Sync after machine has been put to sleep and MMW is terminated: fails Unfortunately there were no debug logs generated--possibly because of the ?regression? that seems to have been introduced: 1 Run MMW and initiate wi-fi sync --> 1 instance of MMW is running 2 Close MMW and initiate wi-fi sync --> 2 instances of MMW are running 3 Run MMW and initiate wi-fi sync --> 3 instances of MMW are running 4 Close MMW and initiate wi-fi sync --> 3 instances of MMW are running etc... Note: I happened to be testing wi-fi sync, but it's not necessary to initiate a wi-fi sync to cause all these extra instances of MMW to run. |
|
|
As discussed over IM, it happens only when MM is running as service and the multiple instances issue is most probably related to 0011971 that Rusty observes on his system. As for the original issue (inaccessibility of server after wake up from PC sleep), this one is also reproducable only when MM is running as service and I was also able to replicate this (seems one of 10 attempts on my machine), seems to be very random, solving... |
|
|
Fixed in build 1700. |
|
|
Verified 1700 I tested 20+ times |
|
|
Seems to be working in 1700. |
|
|
User lostpirate has now permanent issues with connecting to MMW (YEK-558768). He will create a MMW log for it. |
|
|
Closing again, the server discovery issue no longer occurs for the user from ticket YEK-558768 |
