Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nautibuoy]

I use MC as a dedicated server/renderer on my audio only system but also like to listen to my music library on my home cinema system, located in a separate room, an there's the rub.

I use MC's DLNA functionality to send music to the home cinema system and Gizmo to control what is playing. The renderer is a Denon AVR1912 home cinema amp. The problem is that connection to the renderer is inconsistent, sometimes it simply doesn't appear as a zone and on other occasions I can play a few tracks and then it will simply drop out and I'm unable to reconnect.

To be honest, I don't think it is actually a MC problem but in Windows, but I'm hoping someone may have a pointer to resolving the issue. Why do I think it's a Windows problem? Well...

on the laptop on which I'm typing this I, in Windows I can see all of the devices on my network and the Denon appears as a device when I power it on, and it stays visible until it is powered off. The laptop is running 64bit Windows 7 Professional. The laptop connects to the network via wifi.

on my MC server, in Windows I can see all of the devices on my network except the Denon, which sometimes connects when it's powered on but will subsequently drop out after a seemingly random period and then not reconnect until powered off/on, sometimes several times. Obviously MC can only see the Denon when Windows sees it. The server runs 64bit Windows 7 Ultimate. The server connects to the network via Powerline adaptor/Ethernet.

on my partners office PC in Windows I can see all of the devices on my network except the Denon, which sometimes connects when it's powered on but will subsequently drop out after a seemingly random period and then not reconnect until powered off/on, sometimes several times.. The runs 64bit Windows 7 Home Edition. The PC connects to the network via wifi

All the Windows computers seem to have the right services running, network detect switched on etc.

I also have a Windows Home Server (2008) that I use for backups. If I put some music files on it the Denon will happily connect to it and play them though the interface is pants.

Thanks for any pointers you may be able to offer.

Ray

Network hub is a WD MyNet 750, which is DLNA & uPnP certified.

[AndrewFG]

Possibly the same problem as mentioned here http://yabb.jriver.com/interact/index.php?topic=84358.msg576250#msg576250

[bob]

In addition, you may want to try disabling Windows Media Services on the PC with the problem. Also, if there are multiple network interfaces on the machine with version 19 you can disable the ones that aren't used for DLNA under Media Network->Advanced settings.

[nautibuoy]

Yes it does sound similar to that issue...

My network is totally DHCP, no static addressing, and there are no duplicates showing. Have checked the network settings on the renderer and they all look fine.

The server running MC19 only has a single, Ethernet, network interface. Its network settings also look fine.

I've disabled the Windows Media Player Network Sharing service on the MC server. I have also unchecked the setting in MC's Media Network settings that allows a renderer to control MC - I wondered if there was some sort of interaction going on.

I'm running an experiment at the moment to see if there is a dependency with MC; I've powered on the renderer but have left it idling with nothing playing. I've shutdown MC. I'll try to monitor if the renderer stays connected in Windows and, if not, try to gauge how long it stayed connected and to detect any event that triggers the disconnection.

Ray

[nautibuoy]

Well, something has changed but the problem remains, if narrowed somewhat.

After a couple of hours the renderer was still showing on the network view of the MC server. So, I turned on MC and started playing an album. After a few tracks replay stopped on the renderer. I checked the MC server and MC was no longer showing the rendered, however, it was still shown on the Windows network map. I restarted MC several times but it wouldn't reconnect to the renderer though it remains visible on the windows map.

Thoughts?

I'm away on business for a couple of days now so will follow up later in the week.

Ray

[AndrewFG]

Thoughts?

Just a thought: could your renderer have just renewed its DHCP lease and been given a different IP address than what it had before?

[nautibuoy]

Just a thought: could your renderer have just renewed its DHCP lease and been given a different IP address than what it had before?

I had a look at the DHCP leases and the time remaining suggest that this wasn't a factor.

Have just got back so will do some analysis over the tomorrow and over the weekend.

Thanks

Ray

[keithsonic]

As Andrew has pitched in with a link to my post I have been trying for several days to rectify this problem.
It is not a Windows problem (I think) as BubbleSoft keeps working even when the renderer (Chord DSX) drops from the Playing Now window.
It is also not an address problem as I am using DHCP and all addresses are unique.
Like Ray once the renderer is dropped the music continues for a short time, presumably until Gizmo makes a call to the server.
The renderer always drops immediately when my wife turns on her laptop and her PC appears as a library - hiding the library has no effect as it is still there. I have turned off all Windows network sharing options on her PC to no avail. Just loaded Windows 8.1 with no success.
What I really need to be able to do is to prevent MC seeing other libraries apart from the Main Library but I can't see an option for this.
Perversely this problem disappeared with v19.0.41 but has reappeared since v51 - is there any way to rewind so I can check that this is an update issue and not a change I have made?
Keith
 

[nautibuoy]

Taking this from the ground up to try and isolate the issue, yesterday I powered on the renderer in the morning and left it all day but without trying to play any music. As far as I can tell (I obviously didn't sit and watch it all day) the renderer remained as a Media Device in the Windows network map. and in MC's 'Playing Now' section for the whole day.

Later today (its early Sunday morning here at the moment) I will play some music (using an album I know has been playing when the dropout has occurred previously) and monitor what happens.

I am fairly certain that it isn't a network configuration or addressing issue. I also don't believe it is dependent on MC version as I've been encountering the issue for some time, back to V17. On the evidence of yesterday's test it would also appear that Windows is stable too?

Will MC be doing any processing of the files or simply passing them to the renderer? Music files are FLAC and renderer can handle FLAC upto 24bit 96KHz.

More to follow?

[AndrewFG]

Will MC be doing any processing of the files or simply passing them to the renderer? Music files are FLAC and renderer can handle FLAC upto 24bit 96KHz.

In your case MC is most probably not processing the file. But whether MC is processing the file or not, this would not be the cause of your dropouts. The dropout is probably due to a failure of the UPnP SSDP discovery process, which has nothing to do with the (HTTP) file serving process.

Apropos SSDP. I think you are saying that your renderer remains visible when your LAN has minimal traffic, and only drops out (disappear from MC) when the LAN traffic rises (??) Now SSDP uses UDP packets, whereas the other command & control parts of the UPnP stack use TCP sockets. Whereas TCP is robust against traffic overloads and interference, the UDP part is quite sensitive to interference. So you need to check if any of the other devices on your LAN are generating a lot of UDP traffic because this certainly has the potential to overwhelm MC's ability to discover your renderer. You also need to check the settings on your router and/or wifi access point in case they are filtering UDP packets or failing to route them properly. Or an even simpler explanation might be that your wifi is suffering high radio interference; the TCP protocol has workarounds to resend packets lost due to interference, whereas UDP packets are simply lost.

[nautibuoy]

Thanks Andrew. I mentioned the processing because I have a sneaking suspicion that the issue has recurred on the same tracks; it's something I'm looking to test shortly.

I will check the router as you suggest, though I don't think the load on the network is ever significant it is likely to be at its highest when playing music via DLNA. There's very seldom any significant concurrent load from other devices. I know the issue isn't wifi interference as all the data transfers are done over cabled Ethernet (via Powerplug adaptors) which are operating at well over 300mbps. Wifi is only used for comms. to the tablet on which Gizmo sits.

Ray

[nautibuoy]

I checked the router and there are no rules or filtering configured as far as I can see so, unless there's something unseen happening inside the black box, that looks OK.

Things got away from me yesterday so I had no opportunity to test some music tracks but will do so soon.

For completeness, when I play music to the home cinema amp there is very little load on the network; our lap/desktop PCs connect wirelessly and only then for 'light' browsing (no gaming, downloading etc.). There is a short peak when our lap/desktops get backed up to the home server daily but that is early each morning. Apart from the MC music server and the DLNA renderer there is a Satellite PVR connected to the Powerplug Ethernet network that we do pull movies and on demand TV down from the Internet to but when the renderer is switched to play music the PVR is automatically switched to standby. To me network configuration or load doesn't seem to be an issue.

Ray

[nautibuoy]

This evening I turned on the DLNA renderer and it quickly appeared in both Windows and MC. An hour later it was still showing in both. I started playing a track and after about 5mins playback stopped. Investigation showed that MC had stopped working. The renderer was still showing in Windows. Restarting MC (several times) would not reconnect to the renderer. I restarted the MC server (several times) after which neither Windows or MC could see the renderer until I restarted the server with the renderer turned off, after which connection was re-established and music could be played on the renderer.

I played the same track again and after 5mins playback stopped again (track is 5mins long) and the connection issues described above were repeated exactly.

As suggested, I'm going to reinstall MC 19.0.41 shortly, currently using MC 19.0.54, to see if that helps; I'll use the same track as above.

Ray

[nautibuoy]

Have downgraded to MC 19.00.41 and tried repeating the above; playback lasted a little longer (around 7mins), and then the following message popped up in MC:

"There was a problem controlling the selected DLNA device. Double-check your device, server and network settings."

I have not seen that message before.

Windows then reported that MC had stopped working. The renderer could still be seen in Windows. Having restarted MC it would not connect to the renderer. Rebooting the MC server restored connectivity.

I have not tried leaving MC in a failed state to see if it eventually recovers connectivity when something times out or the like.

It's late now but will retest tomorrow evening to see how consistent the behaviour is.

Ray

[AndrewFG]

"There was a problem controlling the selected DLNA device. Double-check your device, server and network settings."

This means that MC was unable to send an HTTP SOAP command to your renderer. This means that either the renderer has crashed, stopped responding or gone offline.

I have not tried leaving MC in a failed state to see if it eventually recovers connectivity when something times out or the like.

The CPU thread within MC that issues such HTTP SOAP commands may freeze if it encounters such an error. Especially if MC was able to open a socket connection to the renderer and send the command (meaning the renderer is partly alive), but that MC is then left waiting for a response from the renderer (meaning the renderer is definitely not fully functional). In such case, that CPU thread will "hang", and this sometimes causes other parts of MC to also "hang".

If I may say so, I think that MC is not completely perfect when it comes to thread isolation, thread synchronisation, and killing and cleaning up dead threads. However this is very tricky stuff to program properly and to debug, so I "forgive" MC for such imperfections. I know this from my experience in writing Whitebear, which is also I admit not perfect in this respect...

Anyway, it is indeed worthwhile waiting a minute or two to see if MC does recover.

PS one reason why, when you kill and restart MC, that it may not be able to talk to the renderer, could be that the "hung" TCP socket connection between your PC and the renderer may not have been cleanly closed, and indeed the Windows IP stack may be holding open the socket to the renderer, and thus preventing anything else from opening a socket to the renderer. In other words, I suspect that the renderer is also not perfect when it comes to thread isolation, thread synchronisation, and killing and cleaning up dead threads...

[nautibuoy]

Thanks Andrew.

Just to update on latest experiences, playing albums this evening has been having exactly the same outcome as before; a short period of playback followed by the message I mentioned yesterday, Renderer still visible in Windows but restarting MC will not reconnect it. I believe that there is further consistency emerging in that the error occurs between tracks.

I think that aligns with your comments as changing tracks will, presumably, be when there commands are exchanged between MC and the renderer.

You've also confirmed my suspicion that the renderer might be part of the problem. The renderer firmware is up to date btw.

Are we saying that this is the end of the line? If so I guess there may be alternatives, something that I can use as a standalone source device for the home cinema amp - suggestions?

Ray

[nautibuoy]

After about 15mins I restarted MC and it was able to see the renderer, I've just started an album playing.

I guess I may as well upgrade MC to the latest version again now.

Ray

[AndrewFG]

^^

That the renderer remains visible in WMP after MC has encountered the error is no surprise. It means the renderer's discovery server is running but it's Http server is not performing.

Also that the error occurs around the time of changing tracks makes sense because this is when MC is sending SOAP commands..

Now I assume that the renderer has passed Upnp certification tests so it must be more or less Ok. So the only open possibility is that MC may be sending its commands timed in such a way that the renderer can't handle it. This is beyond my ken so hopefully someone from JRiver can comment.

PS perhaps you have MC set to use SetNextAvTransportUri when in fact the renderer doesn't support that action??

[bob]

..
PS perhaps you have MC set to use SetNextAvTransportUri when in fact the renderer doesn't support that action??

Or it's one of the broken implementations.
You could try turning it off in the DLNA controller options (right-click on the zone).

[nautibuoy]

Thanks Gents, I'll give it a try.

Ray

[nautibuoy]

I can report some improvement; I've had uninterrupted playback for up to about 30mins today. I'm still getting dropouts though but recovery does seem to be a bit quicker.

Ray

[bob]

I can report some improvement; I've had uninterrupted playback for up to about 30mins today. I'm still getting dropouts though but recovery does seem to be a bit quicker.

Ray

You could try the other controller option, disabling transport events.

[nautibuoy]

I was wondering about that Bob. I'll let you know.

I was thinking of listing all of the DLNA settings I now have configured in case there might be anything obviously wrong.

Ray

[AndrewFG]

I was thinking of listing all of the DLNA settings I now have configured in case there might be anything obviously wrong.

Every option is there for a reason, so none of them is "wrong". You just have to find the right combination of options that works for your particular renderer.

Renderer manufacturers seem to be in a competition for the quirkiest implementation of UPnP DLNA that nevertheless still passes the certification tests.
I could write a book about this. But it would be a very boring one