by Barry4679 » Fri Dec 18, 2020 2:18 am
Ludek wrote: ↑Thu Dec 17, 2020 6:40 am
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
[quote=Ludek post_id=475719 time=1608205244 user_id=7319]
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.
[/quote]
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:
[list]in a situation where the "random" port range is blocked, you silently auto-start the invisible temporal server, using a blocked port ==> No music[/list]
[list]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 [/list]
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:
[list]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?[/list]
[list]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[/list]
[list]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[/list]