Unable to play to Sonos using MM5 ... works OK from MM4

[Barry4679]

I can play to Sonos using MM4, when setup like this

From MM5 I get this error message when playing the same Sonos unit

MM5 can play the these tracks to its Internal Player without problem.

Here is how 5 is configured for the items that seem relevant to me ... all much the same as MM4

I took a debug log file, and PM's to Ludek and Peke

MM5 version is 2281

[Ludek]

Hi,
in your debug log I see that MM5 served this file
\\NAS\flac\Adele\21\02.flac
as
http://192.168.0.134:12371/ItemID=309.flac

Then it waited for the "Guest - Sonos Play:1 Media Renderer" to start playback, but the renderer reported status TRANSITIONING for 10 seconds, but then it reported status STOPPED without asking for the file stream.

So by evidence Sonos had a trouble accessing the file for some reason (not decoding).

Could you please generate debug log also from MM4 (where it works) so that I compare the logs to see what might be the difference? I guess that the only difference could be the served IP address or port.

Thanks!

[Barry4679]

I tried playing to Sonos again from MM4 ... works immediately.
Unable to create debug log as it is not a debug version of MM.

Installed portable latest beta of MM4 (1914) debug version ... unable to play to Sonos ... sent you the debug log
Checked my production version of MM4 ... is version 1910.

Installed portable version of debug v1910 MM4 ... unable to play ... sent you the debug log.

Checked firewall ... cannot see anything that may account for this.

nb: for this test I used a different Sonos unit than the MM5 test for the log that you have ... someone is asleep close to that one atm
nb2: when I installed the two extra versions of MM4 I did not let the wizard complete, because I didn't want to disturb file associations etc .. no problem with that?

Any other Sonos owners reading this?
You can render|play to Sonos from MM5?
Anything you had to setup?
Thoughts?

[Ludek]

OK, wating for the logs from MM4, must be something with the firewall rules (I guess).
Probably installing MM4/MM5 to a brand new folder/location and accepting the UAC prompt to create the MM auto-conf firewall rules solves the issue ?

[Barry4679]

OK, wating for the logs from MM4, must be something with the firewall rules (I guess).
Probably installing MM4/MM5 to a brand new folder/location and accepting the UAC prompt to create the MM auto-conf firewall rules solves the issue ?

OK I will look at it in the morning. I will reinstall MM4, and allow the wizard to complete.

I don't hold much hope. .. When I installed MM5 I would have allowed the wizard to complete. ... [question] the wizard is invoked when importing data and settings from MM4?. .. If no, then maybe the wizard did not run. ... After i installed, and imported data from MM4, I decided to delete MM5.db because it had imported logical corruption from MM4. So I deleted the migrated MM5.db, which forced MM5 to build a new database, and then I rescanned my NAS ... so maybe a firewall setting step was bypassed ... we shall see tomorrow.

[Barry4679]

Allowing your install wizard to complete did not fix the issue.

I looked harder at my Firewall rules. The UI is crappy, but I now see that the default action, which is being applied to new installs, is to "open designated ports" ... So I must not have designated enough ports to be opened ... which do you use? Is documented somewhere?

I have ports open that are described as being required for Windows Media Player Network Sharing Service ... these are not enough?

The version of MM4 that is working OK, for MM to share to Sonos, was set to open ports for All Devices for that installation of MediaMonkey. I presume that MM created that rule? I think that I would have only opened it for the local network. ... or maybe someone helped me when I first got Sonos & MM about 12 years ago.

Summary of outcome:

• I am waiting for info about which ports need to be open

• that will resolve the issue

• the error message (flac cannot be decoded) is unhelpful ... could be improved to something directing people to their firewall rules?

• I was going to say that the Install Wizard did not auto-configure as you seem to be expecting .... but now I am not so sure ... One annoying "feature" of Ventis programs is that they are prone to opening action dboxes underneath the active program at the top of the z-order ... there are many instances of this ... it happened here also ... I have just noticed that there is a Windows Escalation dbox sitting underneath MM4 ... maybe that would have opened the port for me?

• it would be better if the MM UI waited for response to that Windows Escalation .. and if this not possible, maybe you could issue a dbox telling people that you are attending to their Firewall rules, and that they should expect and attend to a message opened by the Windows OS

• opening the ports to "all devices" seems excessive ... why not just to devices within the home network?

{UPDATE] I sent a PM with download link to debug log where MM5 accessed Sonos OK ... maybe will help you see which ports are needed ... When it was failing Sonos seemed to complain about port 20831 ... is that a weel known port?

[Ludek]

FYI: Replied via the private message.

[Barry4679]

Firstly, as you may have noticed I am no expert regarding Firewalls, Ports, networking etc.

From observation today (btw please tell me if I am wrong):

1. the MM4/MM5 server is not relevant when using MM5 to play to a remote Renderer, like Sonos ... I can play to Sonos when the Server is stopped
2. I can play to Sonos without turning any ports on, if the LAN is set as a Home Network
3. it Is more difficult if LAN is set as a WORK Network:
   • in this situation MM4 or MM5 seem to try to connect using a random port ... If I watch my Sonos controller I can see the port that MM is trying to use
   • if I open that port for the MM program, I can play successfully
   • but if I then close and restart MM5 it uses a different random port, and I can't play to Sonos

#A: Is there configuration so that I can direct MM5 to use a constant port for this Use Case?

#B: Could the error message on the MM5 side be improved?

• the error message on the Sonos side is better than the MM5 error ... can the MM5 error message be improved to suggest a connectivity issue, or even better, theFirewall and mention the port number?

• Timeout: the Sonos reports the error in about 10 seconds ... MM5 takes about 15 seconds ... 15 seconds seems too long

#C: One other issue:

• if I configure MM to output to a Sonos

• then close MM5

• then power off the Sonos

• then start MM5

• I see this notification message

• ===> MM5 auto-reconfigures itself to stream to the Internal Player .... and stays that way after I turn the Sonos on, or I restaert MM5

• ??? Is that intended ... does not seem to be a good idea

[Ludek]

#A: By default MM utilizes its own media server to share the local files with Sonos, it is in Options > Media Sharing.
If you disabled the default media server then it is creating temporal invisible media server with the random port as you found (to be able to serve the local files to Sonos).

So answer is yes: Enable the default MM server and configure the port to any value you like and then add this port as allowed to your firewall, MM does not use the well known ports as it would interferre with the others servers on the PC, e.g. Windows Media Player is using TCP port 2869 for its server (as you can see in your McAffee firewall settings).

#B: There is no way for MM to know whether Sonos is not playing the files because it is an unsupported format or whether it has a trouble to access it (due to the firewall issue)

#C: Yes, this is intended

[Ludek]

Anyhow I agree that it is hard to realize for users what's going wrong, so this needs to be documented, added as https://www.ventismedia.com/mantis/view.php?id=17232

[Barry4679]

#A: By default MM utilizes its own media server to share the local files with Sonos, it is in Options > Media Sharing.
If you disabled the default media server then it is creating temporal invisible media server with the random port as you found (to be able to server the local files to Sonos).

I tried your Media Server as first thing I did, because that is what you suggested elsewhere. ... opened the ports that you suggested, plus the port used by the MM Server. ... I could not get to play tracks on Sonos.

• but now I can .... so I felt stupid ... tried to see what went wrong earlier today

• I then shut down your server (via Tools|Options|Library|MediaSharing).

• and tried to play a track to Sonos ... it failed as expected

• I restarted the server (nb. MM5 is kept running through all these steps)

• ===> unable to play ... waited a long time ... still fails ... Sonos error message is indicating you are using the random-port Media Server

• ===>[ maybe you are not shutting down the random-port server when I (re)start your proper server?

I think that this could be what happened to me this morning. ... should be fixed?

I stop|start MM5 and it is now working OK.

#B: There is no way for MM to know whether Sonos is not playing the files because it is an unsupported format or whether it has a trouble to access it (due to the firewall issue)

Then why are you so definitive in your error message? ... "flac cannot be decoded" ... in my case that was confusing false information leading to incorrect direction of inquiry and investigation

#C: Yes, this is intended

I don't think that this helped either. ..ie.:

• nothing playing

• change FireWall rules trying to get something to work

• frustration ... it used to work, but now it doesn't ... restart MM5 ... turn Sonos off and on ... etc ... stress

• then I notice that you have silently altered my configuration ... changed from Render to Sonos to render to Internal Player ... and I have no PC speakers turned on .. !!

• ===> I think that you "helpful" new thing added several hours to my job of understanding how everything works

Also it stuffs up my configuration each time start MM5 when my Sonos is turned off.
Unless you have a good reason, please reconsider.

[Ludek]

#A tracked as https://www.ventismedia.com/mantis/view.php?id=17232

#B tracked as https://www.ventismedia.com/mantis/view.php?id=17234

#C tracked as https://www.ventismedia.com/mantis/view.php?id=17235

[Barry4679]

#A tracked as https://www.ventismedia.com/mantis/view.php?id=17232

Just checking, because a point that I was trying to make appears to have been lost from your Mantis incident report.

if would user enable the default server while the temporal would be running for the casting then these two servers would be in conflict
But note that MM always uses the default configured MM server when available (i.e. in the default install)

My observation seemed to indicate that there was a conflict, and the temporal server was preferred . ... ie.

• play something when your server was down ==> temporal server is started

• start your server

• play some thing ==> your server is ignored ... the play is directed to the temporal server

• this is a problem when the random port used by the temporal is blocked

Also could you consider adding a configuration item where the user could configure a fixed override to the random port used by the temporal server? ... ie. an additional config item to the existing one for your server. ... this would handle the situation where a user has their Lan set to something other than "Home"

#C tracked as https://www.ventismedia.com/mantis/view.php?id=17235

You may think that the change to Internal Player will be obvious because suddenly music comes from computer speakers. ... But who has their computer speakers left on? .. I don't, because I don't want the computer shouting at me about some product I don't want, every time I browse to somewhere that is earning $advertisng. And I don't want Microsoft break by train of thought, by beeping all the time.

If you persist with this innovation shouldn't you update this dbox to alert the user that you have made a change.



I think that MM5 is being designed too much like an AI. ... ie. change my configuration if my remote Renderer is temporarily unavailable.
I am half afraid that I will wake up one morning to a message from MM5 saying "Housekeeping completed; 500gb returned to disk free pool. Deleted all tracks unplayed for 6 months".

[Ludek]

My observation seemed to indicate that there was a conflict, and the temporal server was preferred

No, there wasn't a conflict, the conflict would be if the two servers instances would have the same port.
When user (in the non-default config like you) disabled or deleted the default media server then I need to run the temporal server in the "invisible state" so that the server isn't availbale for browsing by DLNA clients (simply based on assumption that user disabled the sharing and does not wish to share anything).
And later when user configures or enables a new server then the server is started in the "visible state" and I cannot give it the same port as the running temporal server has -- because the two server instances would be in conflict. I also cannot stop the temporal server right after starting another server by user as MM already sent the track URIs with links to the temporal server.

What we can improve is the error messaging if the playback failure happens, in that case we should include the port number being used for the file casting. Added to https://www.ventismedia.com/mantis/view.php?id=17234

[Barry4679]

No, there wasn't a conflict, the conflict would be if the two servers instances would have the same port.
When user (in the non-default config like you) disabled or deleted the default media server then I need to run the temporal server in the "invisible state" so that the server isn't availbale for browsing by DLNA clients (simply based on assumption that user disabled the sharing and does not wish to share anything).
And later when user configures or enables a new server then the server is started in the "visible state" and I cannot give it the same port as the running temporal server has -- because the two server instances would be in conflict. I also cannot stop the temporal server right after starting another server by user as MM already sent the track URIs with links to the temporal server.

Thanks for taking time to provide me that info.

You mentioned in another post that the documentation may be improved ... The purpose for your Media Sharing Server should be part of that.

You may be wondering why a user would disable your default media server? I did primarily because I have MM4 running all the time. That obviously goes away when you release MM4, but up until recently I had the MM4 server turned off also, because I didn't want to share anything to my TV ... and if I do share to my Sonos I am unable to use anything that is shared due to deficiencies in Sonos support of DLNA, which you helped me identify some years ago. So I had it turned off to reduce useless clutter at the client end, and to reduce needless network chatter.

IMO the current MM5 UI strongly indicates what the Media Server's purpose is ... ie. being a Media Server for other client devices & apps, as indicated by the Shared Content tab, and the name Media Sharing. ... There is nothing to suggest that it is also used when MM is playing to a remote speaker... and this false conclusion is supported by the fact that music may still be played (FireWall willing) when your main media server is disabled.

That other thing I wanted to say regards the (maybe unavoidable?) consequences of what you described above:

• in a situation where the "random" port range is blocked, you silently auto-start the invisible temporal server, using a blocked port ==> No music

• so the user looks through Tools|options, and enables your Media Server, and opens its port ... clears playlist ... tries again to play ==> still no music ... because you are persisting with the hidden server which isn't working due to a blocked random port

This is cleared up if the user stops and restarts MM5 ... In my case I did do that, but you had silently changed my configuration to output to the Internal MM5 Player, and my PC had it sound turned off ===> No music ... so my confusion persisted

I know that you said that you would tweak that last bit. ... but:

• I am not sure that MM5 is better for you hanging onto that temporal server ... you could just close it before actioning the user request to start your main Media Server?

• if the user uses the port information in your new error message, and opens the required port ==> music plays ... but the problem re-occurs next time they restart MM5, because you will be using a different random port ... that is going to really confusing

• you said that you could not use the same port for temporal and main servers ... I was not suggesting that ... I was suggesting that the user have to option be able to specify, and open, another fixed port, one which is just used by the temporal server ===> That would have got me going a lot sooner ... ie. I could see that you have interest in those two ports, and I would have opened them ===> and your temporal server would have worked for me on my 1st try, without seeking support ... even if people do need to contact Support, or read a FAQ, it will be quicker just to tell them to open those two ports, as this will cover multiple scenarios; main media server running, or not running