View Issue Details

IDProjectCategoryView StatusLast Update
0011774MediaMonkey (current)DLNA/UPnPpublic2014-04-29 12:41
Status closedResolutionfixed 
Product Version4.1 
Target Version4.1.1Fixed in Version4.1.1 
Summary0011774: Intermittent failure to find MMW Server
DescriptionFailure to find the MMW server seems to be a recurring problem--sometimes it'll work, and then later it won't:

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?
TagsNo tags attached.
Fixed in build1700


related to 0011531 closedLudek MediaMonkey (current) Server is not seen after resume from computer sleep for some users/client apps 
related to 0011925 closedLudek MediaMonkey (current) Media Server stopped after hibernation 
has duplicate 0011741 closedmarek MediaMonkey for Android Going back to file list from server duplicates list 
related to 0011381 resolvedmarek MediaMonkey for Android Documentation: Some users can't see MMW UPnP server 
related to 0011971 feedbackrusty MediaMonkey (current) MediaMonkey fails to terminate (1697) 



2014-01-22 10:48

developer   ~0039338

Last edited: 2014-01-22 10:50

View 4 revisions

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?) ?


2014-01-22 14:28

developer   ~0039341

I have changed logging of connection process to see whether MMA discovers at least any upnp devices in this situations (build 222).


2014-01-24 00:12

developer   ~0039360

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.


2014-02-04 22:35

administrator   ~0039512

New logs posted. See:


2014-02-05 15:11

developer   ~0039517

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.


2014-02-05 16:29

administrator   ~0039519

Also, another related issue point out by Marek that can affect ICS users:


2014-02-19 16:18

developer   ~0039672

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:
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 ?


2014-02-20 11:04

developer   ~0039686

MMW doesn't add UPC to DeviceDescription.xml, as discussed offline with Marek, it was most probably another media server on the network.


2014-02-20 12:12

developer   ~0039688

Last edited: 2014-02-20 12:20

View 2 revisions

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.


2014-03-05 08:26

developer   ~0039774

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.


2014-03-06 04:02

administrator   ~0039789

Another possible instance from a longtime user:


2014-03-06 04:09

developer   ~0039790

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).


2014-03-15 11:37

developer   ~0039883

Last edited: 2014-03-15 15:13

View 3 revisions

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:
 MX: 3
 MAN: "ssdp:discover"
 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:
 ST: upnp:rootdevice
 MX: 3
 MAN: "ssdp:discover"

 - 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:
 MX: 3
 MAN: "ssdp:discover"
 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.


2014-03-20 19:27

administrator   ~0039931

Last edited: 2014-03-20 19:50

View 4 revisions

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).


2014-03-20 20:55

developer   ~0039932

Last edited: 2014-03-20 21:12

View 8 revisions

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


2014-03-20 21:37

administrator   ~0039933

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


2014-03-20 22:14

developer   ~0039934

As found over IM with Rusty, reverting 0011531 solves the issue, solving further...


2014-03-21 01:07

developer   ~0039935

Fixed in build 1699 (to be confirmed by Rusty)


2014-03-21 09:14

developer   ~0039943

Confirming fix using steps from 0011774:0039933 I confirmed on two devices Nexus 7 and LG L5


2014-03-21 10:58

developer   ~0039960

Last edited: 2014-03-21 10:58

View 2 revisions

@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.


2014-03-21 18:28

administrator   ~0039964

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

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.


2014-03-21 20:45

developer   ~0039966

Last edited: 2014-03-21 20:46

View 2 revisions

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...


2014-03-21 22:40

developer   ~0039967

Fixed in build 1700.


2014-03-23 15:49

developer   ~0039979

Verified 1700 I tested 20+ times


2014-03-24 01:46

administrator   ~0039984

Seems to be working in 1700.


2014-04-25 12:30

developer   ~0040107

User lostpirate has now permanent issues with connecting to MMW (YEK-558768). He will create a MMW log for it.


2014-04-29 12:41

developer   ~0040126

Closing again, the server discovery issue no longer occurs for the user from ticket YEK-558768