Print

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

[DJLegba]

Problem: When MC is used as a DLNA renderer it starts out responding in a timely manner, but eventually the responses become so late that the DLNA controller either gives up or gets confused.

I wrote about this issue with MC 25 here: https://yabb.jriver.com/interact/index.php/topic,123164.msg853074.html#msg853074
At that time I thought I was only seeing the problem with my Pixel 3 XL Android 10 phone, but since then I've also seen it happen when using Bubble on my Samsung Android 9 tablet. And in that thread I wrote that I wasn't seeing Bubble's Bye-Bye events from the Samsung, but I was wrong.

This may be difficult to track down because there are at least three systems in play: MC, BubbleUPnP, and Android. However,

• Bubble never has this problem when streaming to my Naim Muso
• It happens with devices running Android 9 and 10
• It can always be fixed by restarting MC

I've tried force stopping Bubble and restarting the Android devices, but the only way to resolve the problem is to restart MC. I was hoping that MC26 might not be affected, but I'm still seeing the problem.

[AndrewFG]

What do you mean by “response time”? i.e. responding to what?

[DJLegba]

I sent a BubbleUPnP log to Bubblesoft and this is what they had to say:

The log shows that:

- BubbleUPnP instructs MC to play a track
- MC requests immediately the stream
- but it takes forever (tens of seconds) for MC to report it is in the PLAYING state, thus that playback has started.

The result is that when the renderer is configured for gapless playback, the second track will begin to play but Bubble still shows the info for the first track, and the Play/Pause icon is in the "start Play" state. After some delay (typically 25 seconds or longer), Bubble will toggle the control into the "Pause playback" state (which means it has finally heard from MC that playback has started). After the second track finishes, there will be a long pause, and then the first track will start to play again.

When gapless is turned off, it's easier to see what's going on. After the track ends there will be a long pause before the next track starts to play. I've seen pauses for one minute or longer.

If I restart MC this behaviour stops, for a while at least. I haven't been able to determine what causes it to go bad again, although my typical usage suggests it could have something to do with using JRemote to control playback on "Player".

Incidentally, this is what your utility has to say about the JRiver renderer:

Device Description Url=http://192.168.86.33:52103/DeviceDescription.xml
HTTP Server Header=Windows, UPnP/1.0 DLNADOC/1.50, JRiver/26, JRiver Internet Reader/2.0 (compatible; Windows-Media-Player/10)
Description=JRiver DLNA Renderer
Friendly Name=NUC
Manufacturer Name=JRiver, Inc.
Manufacturer Url=http://192.168.86.33:52103/https://www.jriver.com
Model Name=Media Center
Model Number=26.0.12
Presentation Url=http://192.168.86.33:52199/Panel/
Serial Number=c0-3f-d5-68-09-07
UPnP Device Type=urn:schemas-upnp-org:device:MediaRenderer:1
UPnP Media Renderer version=1
Unique Device Name=uuid:20e68194-0d9b-475e-9f9d-e154c6168b78
X_DLNADOC Element=DMR-1.50
Service Url for ConnectionManager=http://192.168.86.33:52103/ConnectionManager/scpd.xml
Service Url for AVTransport=http://192.168.86.33:52103/AVTransport/scpd.xml
Service Url for RenderingControl=http://192.168.86.33:52103/RenderingControl/scpd.xml
Common Renderer Type=JRiver Media Center
AVT:GetDeviceCapabilities action=Supported
AVT:GetMediaInfo action=Supported
AVT:GetPositionInfo action=Supported
AVT:GetTransportInfo action=Supported
AVT:GetTransportSettings action=Supported
AVT:SetNextAVTransportURI (gapless play)=Supported
AVT:SyncPlay (synchronous play)=NOT Supported
RC:GetVolume action=Supported
RC:SetVolume action=Supported
AVT:Event Subscription=Missing Notification
RC:Event Subscription=Succeeded
HTTP User Agent (client)=Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.3; WOW64; JRiver Internet Reader/2.0) UPnP/1.0
Play test file result=Play success => Start Ok / Stop Ok / Muted / Subscribe error

[AndrewFG]

^
>> Play test file result=Play success => Start Ok / Stop Ok / Muted / Subscribe error

The Subscribe Error message says that the DMRA encountered a problem when subscribing to receive status change notifications from MC. This means that either a) MC is rejecting the SUBSCRIBE request, or b) not sending an initial NOTIFY response (in time). This is a very unexpected message since in my experience MC is usually impeccable concerning event subscriptions. My initial hypothesis is that you have av software, or firewall, that is blocking or delaying the subscription / response process. I suggest to temporarily disable your av or firewall, and test it again.

[DJLegba]

I restarted MC yesterday and have used it quite a bit today, controlling playback directly with MC or with JRemote2, but not with Bubble. After reading your post I ran your test again and got the following:

Play test file result=Play success => Start Ok / Stop Ok / Muted

Then I started playing an album via Tidal, and while listening to the first track I turned off the Windows firewall on the NUC. The second track played fine, but playback stopped after that. I ran your test again, and it's still showing

Play test file result=Play success => Start Ok / Stop Ok / Muted

I restarted MC, reconnected with Bubble, and started playback again. So far, five tracks in, no problem. This is typical of what I have been seeing, so I doubt Windows Firewall is a factor. The subscribe failure (which I haven't seen again) could be something that happens when MC's DLNA renderer is experiencing other problems.

[DJLegba]

Is no one else using MC as a DLNA renderer? As another test, I downloaded Audirvana 3.5.3 for Windows and configured it to play to my MC server over the network. Same problem - it queues two tracks, which is normal for gapless DLNA playback, but after the first track has ended it moves to the second track without queuing another. After the second track ends it waits for a while and then plays the first track again. I really think there is something fundamentally broken with MC's DLNA renderer. (I'm using MC 26.0.14 64-bit right now, but I've been seeing this problem since I first started trying to use MC this way with version 25).

[DJLegba]

I have an MC server in one room and an MC client in another. I use an Android phone, an Android tablet, and a Windows computer at my desk to control playback. It seems that at any given time, one of those devices will have no trouble with an app streaming to one of the MC instances via DLNA. Right now Bubble on my Android phone is working fine with the MC server. A while ago it was the tablet. I'm wondering if MC is trying to send DLNA responses to the wrong controller.

[bob]

I have multiple Id's at home both NUC and IdPI's using MC25 as a DLNA renderer gaplessly and never seen the issue you describe.
I've done this with JRemote as well as other instances of MC on all three platforms.
When MC pushes to a MC renderer it's doing DLNA/uPnP just as any other uPnP controller would.

I'm wondering if you have multiple active network interfaces on your MC renderer??

[DJLegba]

I have multiple Id's at home both NUC and IdPI's using MC25 as a DLNA renderer gaplessly and never seen the issue you describe.
I've done this with JRemote as well as other instances of MC on all three platforms.
When MC pushes to a MC renderer it's doing DLNA/uPnP just as any other uPnP controller would.

I'm wondering if you have multiple active network interfaces on your MC renderer??

The MC renderer doesn't have a WiFi adapter, so there is only one network interface. It's a headless dedicated MC server as well, and I never use it for anything else (except see below).

I don't see the issue with JRemote or when MC pushes to a client MC (I have a DAC on the master and a DAC on the client). My goal here is to use an app to send streams from Tidal to my DAC via MC. Neither JRemote nor MC can connect to the Tidal library. I understand why Jim has made this decision, so I'm not complaining about it. However, to achieve this goal I can use BubbleUPnP on my Android phone and tablet, connect to Tidal's library, and direct content to an MC DLNA renderer. This was working well for me when I used only the tablet as a control app. As soon as I started mixing use between the phone and the tablet I began to encounter the problem described earlier.

After much experimenting and troubleshooting (I even downloaded Wireshark, and the traffic capture did not support my theory that MC was somehow caching the control app's IP address) I was ready to just use the Tidal app and cast to a Chromecast Audio and take the optical output from there into the DAC. In fact, I did this for a while but the CCA's optical output didn't sound as good. So as a last resort I installed the BubbleUPnP server on the NUC that runs my MC server and created an OpenHome renderer from the MC renderer. This has worked very well - I can use the BubbleUPnP app on both the phone and the tablet, with the advantage that they both see and can control the queue at the same time.

I realize what I've said makes it sound like the problem is with the BubbleUPnP app, but I've worked with their tech support and the Bubble log is definitely showing that when I experience the problem Bubble is seeing a very long lag in the responses from MC.

[bob]

The MC renderer doesn't have a WiFi adapter, so there is only one network interface. It's a headless dedicated MC server as well, and I never use it for anything else (except see below).

I don't see the issue with JRemote or when MC pushes to a client MC (I have a DAC on the master and a DAC on the client). My goal here is to use an app to send streams from Tidal to my DAC via MC. Neither JRemote nor MC can connect to the Tidal library. I understand why Jim has made this decision, so I'm not complaining about it. However, to achieve this goal I can use BubbleUPnP on my Android phone and tablet, connect to Tidal's library, and direct content to an MC DLNA renderer. This was working well for me when I used only the tablet as a control app. As soon as I started mixing use between the phone and the tablet I began to encounter the problem described earlier.

After much experimenting and troubleshooting (I even downloaded Wireshark, and the traffic capture did not support my theory that MC was somehow caching the control app's IP address) I was ready to just use the Tidal app and cast to a Chromecast Audio and take the optical output from there into the DAC. In fact, I did this for a while but the CCA's optical output didn't sound as good. So as a last resort I installed the BubbleUPnP server on the NUC that runs my MC server and created an OpenHome renderer from the MC renderer. This has worked very well - I can use the BubbleUPnP app on both the phone and the tablet, with the advantage that they both see and can control the queue at the same time.

I realize what I've said makes it sound like the problem is with the BubbleUPnP app, but I've worked with their tech support and the Bubble log is definitely showing that when I experience the problem Bubble is seeing a very long lag in the responses from MC.

That's a pretty complicated setup.
First you are playing streams, not individual files it seems.
Second you are using the BubbleUPnP server to translate the stream to MC via DLNA on the localhost address as I understand it.
For testing, it might be interesting of you used Bubble on a different computer to front end the MC renderer and see if the behavior remains the same.

I did do some playing around with this in the past and it worked fine for me, with file based playback at any rate.

[DJLegba]

That's a pretty complicated setup.
First you are playing streams, not individual files it seems.
Second you are using the BubbleUPnP server to translate the stream to MC via DLNA on the localhost address as I understand it.
For testing, it might be interesting of you used Bubble on a different computer to front end the MC renderer and see if the behavior remains the same.

I did do some playing around with this in the past and it worked fine for me, with file based playback at any rate.

When I encountered the problem I tested with files (copied an album to my phone and tablet) and I observed the same behaviour. So files/streams were the same.

I only added the BubbleUPnP server in a last-ditched attempt to make things work - which it did. Before that the setup was not complicated. I was using a control app on my phone or tablet, sending either streams or local files to an MC renderer.

I have moved the BubbleUPnP server from the MC renderer to another computer, this time with a WiFi connection. It appears to be working, but as I said, I wasn't have trouble when using Bubble server. It was added to solve the problem.

If you're interested in trying to reproduce the problem, don't install Bubble Server anywhere. Install the BubbleUPnP Android app on two different devices and use both devices to play local files to an MC DLNA renderer.

[RoderickGI]

I use an Android phone, an Android tablet, and a Windows computer at my desk to control playback. It seems that at any given time, one of those devices will have no trouble with an app streaming to one of the MC instances via DLNA. Right now Bubble on my Android phone is working fine with the MC server. A while ago it was the tablet. I'm wondering if MC is trying to send DLNA responses to the wrong controller.

This was working well for me when I used only the tablet as a control app. As soon as I started mixing use between the phone and the tablet I began to encounter the problem described earlier.

I was going to ask if you ever see this problem when you use one controller, and only one controller, during playback. But you have sort of answered that question already. Maybe you could confirm that. Remember, MC will be acting as a Controller if you use it to manage playback, so you can't use Bubble and MC for tests. It has to be only Bubble, or only MC, or only JRemote.


Why? I've seen a MC Renderer get into trouble when one Controller starts playback, and then another takes over management, or even just looks up the currently playing tracks. It seems that switching Controllers does cause a bit of a problem. But that is consistent with my understanding of DLNA, and not necessarily a MC problem.

[DJLegba]

I was going to ask if you ever see this problem when you use one controller, and only one controller, during playback. But you have sort of answered that question already. Maybe you could confirm that. Remember, MC will be acting as a Controller if you use it to manage playback, so you can't use Bubble and MC for tests. It has to be only Bubble, or only MC, or only JRemote.


Why? I've seen a MC Renderer get into trouble when one Controller starts playback, and then another takes over management, or even just looks up the currently playing tracks. It seems that switching Controllers does cause a bit of a problem. But that is consistent with my understanding of DLNA, and not necessarily a MC problem.

I recall that we have talked about MC crashing when JRemote takes over from Bubble, or vice versa, if something is playing or even in the queue. It doesn't happen all the time, but often enough that we both make a conscious effort to avoid this. For that reason, I've been in the habit of stopping playback and clearing the queue before exiting Bubble (the app).

If you haven't tried Bubble Server serving MC as an OpenHome renderer you should give it a shot. You can see and manage the queue from all your control points at the same time. Right now I'm using Bubble on the tablet to play an album from Tidal via MC, and I can see the current track and the next in the queue with JRemote2 on my Android phone. When I look at the metadata in JRemote I see the stream is a flac file sent to MC on port 58050 and the image file is coming from the Bubble app on my tablet.

[RoderickGI]

If you haven't tried Bubble Server serving MC as an OpenHome renderer you should give it a shot.

Well, one potential issue is that OpenHome isn't completely compatible with DLNA. They say that themselves. Also, MC isn't an OpenHome Renderer. But maybe that is just the terminology you are using? Perhaps AndrewFG can clarify.

I'm afraid I have too much to do at the moment to start mucking around with Bubble Server.

You can see and manage the queue from all your control points at the same time.

That is also a concern, because the queue should belong to the Renderer, and not the Controller. As I understand it, a Controller sends a list of files to play to the Renderer, with the server address for each, and the Renderer then requests those file from the DLNA Server, as required. So the queue is on the Renderer, not the Controller. Of course the Controller can add to, or replace the Renderer queue, or check the status, and various other things, but the queue doesn't belong to the Controller. That is another point of difference.

However, my knowledge of this level of DLNA functionality is through observation and not study, so I could be wrong. Again, Andrew is the expert.

[DJLegba]

That is also a concern, because the queue should belong to the Renderer, and not the Controller. As I understand it, a Controller sends a list of files to play to the Renderer, with the server address for each, and the Renderer then requests those file from the DLNA Server, as required. So the queue is on the Renderer, not the Controller. Of course the Controller can add to, or replace the Renderer queue, or check the status, and various other things, but the queue doesn't belong to the Controller. That is another point of difference.

Ah, well with DLNA the queue belongs to the Controller, but with OpenHome it belongs to the renderer. I think that explains why I'm not seeing the problem with Bubble Server's OpenHome renderer. And there must be some set of conditions when MC and the DLNA controller don't communicate properly, leading to my problems described at the top of the thread (trouble using two different DLNA controllers).

[bob]

I was going to ask if you ever see this problem when you use one controller, and only one controller, during playback. But you have sort of answered that question already. Maybe you could confirm that. Remember, MC will be acting as a Controller if you use it to manage playback, so you can't use Bubble and MC for tests. It has to be only Bubble, or only MC, or only JRemote.


Why? I've seen a MC Renderer get into trouble when one Controller starts playback, and then another takes over management, or even just looks up the currently playing tracks. It seems that switching Controllers does cause a bit of a problem. But that is consistent with my understanding of DLNA, and not necessarily a MC problem.

That is correct and the logic is as follows:
Since DLNA doesn't have a way to arbitrate between multiple controllers, MC assumes that it is the active controller if it was used to generate the last transport command (play/stop).
If some other controller for example sends a stop MC has no way to know that the track hasn't simply transitions and it will happily send the next track.
It gets even more complicated if you are using gapless playback since there is likely to be a second track in the SetNextURI buffer.

If MC isn't used to send the transport commands it will simply monitor what is occurring on that DLNA zone and display the cover art and track progress if it's the current zone.