Print

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

[MaxA]

Hi all,

Every time I start JR I need to go and turn off it. How I can do that once forever?

[AndrewFG]

If your renderer fails to support it (i.e. it proactively returns an error message if MC tries to call that method) then MC will disable it. So the answer to your question is (dare I say it) “buy a renderer which does support it”..

[MaxA]

buy a renderer which does support it

That's really easier to give such recommendation than to add simple checkbox with the label "Always disable SetNext Support" to options.

[AndrewFG]

That's really easier to give such recommendation than to add simple checkbox with the label "Always disable SetNext Support" to options.

There is no point in such a checkbox. The fact is that SetNext is disabled because it does not work on your renderer. And repeatedly and naively trying and failing, will not change that fact.

[Hendrik]

There is no point in such a checkbox. The fact is that SetNext is disabled because it does not work on your renderer. And repeatedly and naively trying and failing, will not change that fact.

I think you mis-read the initial post. He doesn't want to force it on, he wants to force it off. Although I don't see why disabling it wouldn't work already?

[AndrewFG]

^
Imho wanting to force disable off is the same as wanting to force enable on. But perhaps he can clarify?

[RoderickGI]

And repeatedly and naively trying and failing, will not change that fact.

Love your work Andrew. 

[Scobie]

Although I don't see why disabling it wouldn't work already?

I think this is the point, he turns it off but for some reason it doesn't stick and he has to do it every time MC restarts.

[MaxA]

Although I don't see why disabling it wouldn't work already?

May be I didn't explain too clear. I can turn it off and the player works in gapless mode well, but sometimes I found that in can make the self turn on. Not clear why. So I'm tryng to find the way to prevent this sudden enabling of the option.

[MaxA]

May be I didn't explain too clear. I can turn it off and the player works in gapless mode well, but sometimes I found that in can make the self turn on. Not clear why. So I'm tryng to find the way to prevent this sudden enabling of the option.

Yes, you're right

[RoderickGI]

So it sounds like the Renderer supports SetNext, and Gapless works fine.

However, sometimes MC doesn't get the appropriate response from the Renderer when it queries its capabilities, perhaps only at startup, or during playback, so it disables SetNext support automatically.

Maybe the automatic disabling process is too rigid. Maybe a message should popup when MC wants to disable it, asking for confirmation (with a message in simple language). Maybe it should be well documented in the log as to why it is disabled, so that the cause can be investigated.

[MaxA]

So it sounds like the Renderer supports SetNext, and Gapless works fine.

However, sometimes MC doesn't get the appropriate response from the Renderer when it queries its capabilities, perhaps only at startup, or during playback, so it disables SetNext support automatically.

Yes, you're right. That happens exactly on start up. I'm starting, just have the JRiver player in the list, than APlayer Media Renderer appears and sometimes SetNext option is turned off if it was disabled before, but sometimes it can be checked. Dependency is not clear. That's the link to the Player/Renderer: http://vv.uka.ru/aplayer_eng.html. Readme: http://vv.uka.ru/readme_en.pdf
May be that will be usefull.

[RoderickGI]

Do you always turn the Renderer on before starting MC?

If not, try doing that for a while. Start the Renderer, give it a minute, then start MC. See if that makes a difference.

[MaxA]

Do you always turn the Renderer on before starting MC?

Renderer included to startup, MC - no.

[AndrewFG]

Can you please download the DMRA from my sig, run the test, and post the renderer report here.

[MaxA]

Can you please download the DMRA from my sig, run the test, and post the renderer report here.

Hope that's what do you need


DMR Report (by Whitebear) for AP Renderer Device
================================================

Device Description Url=http://192.168.1.3:1351/
HTTP Server Header=UPnP/1.0 DLNADOC/1.50 Platinum/1.0.5.13
Description=APlayer Media Renderer Device
Friendly Name=APlayer Media Renderer
Manufacturer Name=Plutinosoft LLC
Manufacturer Url=http://www.plutinosoft.com
Model Name=AP Renderer Device
Model Url=http://www.albumplayer.ru
UPnP Device Type=urn:schemas-upnp-org:device:MediaRenderer:1
UPnP Media Renderer version=1
Unique Device Name=uuid:3CA50632-4E12-4865-B460-1D926BABBC75
X_DLNADOC Element=DMR-1.50
Service Url for AVTransport=http://192.168.1.3:1351/AVTransport/3CA50632-4E12-4865-B460-1D926BABBC75/scpd.xml
Service Url for ConnectionManager=http://192.168.1.3:1351/ConnectionManager/3CA50632-4E12-4865-B460-1D926BABBC75/scpd.xml
Service Url for RenderingControl=http://192.168.1.3:1351/RenderingControl/3CA50632-4E12-4865-B460-1D926BABBC75/scpd.xml
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=Succeeded
RC:Event Subscription=Succeeded
HTTP User Agent (client)=Lavf/57.83.100
Play test file result=Play success => Start Ok / Stop Ok


Media Center DLNA Server Advanced Settings
==========================================

DLNA=Off
DLNAExtra=Off
Enable bitrate Field=Off
Filter international characters=Checked
Include session ID=Off
Playstation 3 Compatible=Off
Present Caption Resources=Off
Present Small Artwork=Off
Present Subtitle Resources=Off
Skip Child Count=Checked
Use flat URLs=Checked
Use full URLs=Checked
WMC Compatible=Off


Declared Supported Audio, Image & Video Formats
===============================================

http-get:*:audio/mpegurl:*
http-get:*:audio/mpeg:*
http-get:*:audio/mpeg3:*
http-get:*:audio/mp3:*
http-get:*:audio/x-mp3:*
http-get:*:audio/mp4:*
http-get:*:audio/x-mp4:*
http-get:*:audio/ogg:*
http-get:*:audio/x-ogg:*
http-get:*:audio/vorbis:*
http-get:*:audio/flac:*
http-get:*:audio/x-flac:*
http-get:*:audio/x-aiff:*
http-get:*:audio/aiff:*
http-get:*:audio/wav:*
http-get:*:audio/x-wav:*
http-get:*:audio/x-ms-wma:*
http-get:*:audio/x-mpegurl:*
http-get:*:application/ogg:*
http-get:*:audio/mp4a-latm:*
http-get:*:audio/mp4a:*
http-get:*:audio/x-mp4a:*
http-get:*:audio/wavpack:*
http-get:*:audio/x-wavpack:*
http-get:*:audio/aac:*
http-get:*:audio/x-aac:*
http-get:*:audio/dff:*
http-get:*:audio/x-dff:*
http-get:*:audio/x-dsf:*
http-get:*:audio/dsf:*
http-get:*:application/octet-stream:*
http-get:*:audio/alac:*
http-get:*:audio/x-alac:*
http-get:*:audio/ape:*
http-get:*:audio/x-ape:*


Evaluated Supported Audio Formats
=================================

audio/mpeg   MP3   Fuzzy   *   2   *   No
audio/mp3   MP3   Fuzzy   *   2   *   No
audio/x-mp3   MP3   Fuzzy   *   2   *   No
audio/mp4   AAC_ISO   Fuzzy   *   2   *   No
audio/x-mp4   AAC_ISO   Fuzzy   *   2   *   No
audio/flac   FLAC   Fuzzy   *   *   *   Yes
audio/x-flac   FLAC   Fuzzy   *   *   *   Yes
audio/x-aiff   AIFF   Fuzzy   *   *   *   Yes
audio/aiff   AIFF   Fuzzy   *   *   *   Yes
audio/wav   WAV   Fuzzy   *   *   *   Yes
audio/x-wav   WAV   Fuzzy   *   *   *   Yes
audio/x-ms-wma   WMABASE   Fuzzy   *   2   *   No
audio/dff   DFF   Fuzzy   *   *   *   Yes
audio/x-dff   DFF   Fuzzy   *   *   *   Yes
audio/x-dsf   DSF   Fuzzy   *   *   *   No
audio/dsf   DSF   Fuzzy   *   *   *   No
audio/alac   ALAC   Fuzzy   *   *   *   No
audio/x-alac   ALAC   Fuzzy   *   *   *   No
audio/mpegurl      Undefined            
audio/mpeg3      Undefined            
audio/ogg      Undefined            
audio/x-ogg      Undefined            
audio/vorbis      Undefined            
audio/x-mpegurl      Undefined            
audio/mp4a-latm      Undefined            
audio/mp4a      Undefined            
audio/x-mp4a      Undefined            
audio/wavpack      Undefined            
audio/x-wavpack      Undefined            
audio/aac      Undefined            
audio/x-aac      Undefined            
audio/ape      Undefined            
audio/x-ape      Undefined            

[AndrewFG]

Ok. So it says SetNext is supported. So I wonder why MC thinks that it fails. I think the next step would be to run a Wireshark capture to observe MCs call to SetNext, and your renderers actual HTTP response code.

[DJLegba]

MaxA, what version of Media Center are you running? There was a release that disabled SetNext when it shouldn't have. I can't remember what version, but it happened to me too. They fixed it pretty quickly, so this is not likely to be your problem, but it's worth checking.

[MaxA]

MaxA, what version of Media Center are you running? There was a release that disabled SetNext when it shouldn't have. I can't remember what version, but it happened to me too. They fixed it pretty quickly, so this is not likely to be your problem, but it's worth checking.

26.0.91. Installed after the thread was opened. Looks like it's Ok now past 3-5 days, but I didn't know anything about the update. I'll watch and report the result.

[MaxA]

I think the next step would be to run a Wireshark capture to observe MCs call to SetNext, and your renderers actual HTTP response code.

NP, but what is the Wireshark?

[JimH]

Google

[RoderickGI]

SetNext was fixed in
26.0.73 (5/5/2020)
6. Fixed: Fix SetNextAvTransportURI which was broken by displaying the audio path on transcoded streams sent to DLNA renderers.

Maybe MC isn't detecting the capabilities of the Renderer correctly at the moment.

[MaxA]

SetNext was fixed in
26.0.73 (5/5/2020)
6. Fixed: Fix SetNextAvTransportURI which was broken by displaying the audio path on transcoded streams sent to DLNA renderers.

Maybe MC isn't detecting the capabilities of the Renderer correctly at the moment.

Ok, I'll watch this issue during week or two and report with any result. That's my headache last several years.

[MaxA]

Tested more than week. Working stable. Sometimes renderer playlist lost previous session data on start and I got empy list. That problem disapeared suddenly. Looks like that was related issue.

Thanks for your work!

[MediaDemon]

Hi, I'm still having this problem. My DLNA renderer is Bubbleupnp (android) version 3.4.8 and each time I go to play something after not using the system for a day or two the Disable SetNext Support option is ticked on my JRiver server (version 26.0.107). Similar to MaxA, my renderer handles gapless just fine if I can just keep this option unticked and I do not have any gapless problems when using a different DLNA server (android).

The server runs 24/7 as does the renderer so I'm not sure when the renderer capabilities are checked. Once I have unticked this option it seems to remain unticked for my entire playback session over multiple playlist instances. It's only when I come back to it after a period of time - sorry I can't be more specific at this time.

I know version 27 is imminent so is it best to wait for this version and test again or should I start looking for a different android renderer? Any suggestions for one that is compatible?

[RoderickGI]

Version 27 is already here. Currently up to MC27.0.18 https://yabb.jriver.com/interact/index.php/topic,127068.0.html


Are you playing to the BubbleUPnP Local Renderer?
What Android device are you running BubbleUPnP on? (I'm running on a Sony phone, Android 9.)
Do you have Gapless playback turned on for the Local Renderer?
In BubbleUPnP on your Android device, select the hamburger menu "More", the Gear wheel for settings, scroll down to Local Renderer and select it, scroll down to Gapless playback and tick the box.

I have that ticked in BubbleUPnP, and play to the Local Renderer on the phone.
AndrewFG's Digital Media Renderer Analyser says BubbleUPnP supports SetNextAVTRansportURI (gapless play).

But MC keeps ticking the "Disable SetNext Support" setting for me as well.
I haven't tried to analyse the issue in detail, but the setting doesn't get ticked if I just let the Playlist play, or if I use the Next or Previous buttons in MC, but if I use the Seekbar to jump near the end of a track, it gets ticked immediately. There may be some logic to that, but it is annoying. It doesn't happen if I seek back or forth as long as the new position isn't near the end of the file, so not within the time MC would normally send the next file to the BubbleUPnP Renderer.
EDIT1: MC also does Disbales SetNext if I restart BubbleUPnP and then start Playback to the phone again. Not when BubbleUPnP connects, but when I start playback. That certainly should not happen.

There may be other conditions that make MC tick that box. Perhaps anything that interferes with sending the next URI to the Renderer in a timely manner. If you work out more conditions that make it happen, or can confirm the ones above, report it and JRiver may be able to fix the issue.

EDIT2: With all the mucking around I did above, Gapless playback wasn't working properly anyway. The audio was being cut off just before the end of the track. I was testing with short tracks that made this obvious. So maybe Gapless isn't really working properly in BubbleUPnP, or maybe that is also a MC issue.


I guess this post sheds some more light on the above posts in this thread. MC is turning off SetNext when it really shouldn't.

[AndrewFG]

^
This just underlines what I have been suggesting for years. Namely that MC should incorporate some of the test code from my DMRA. This would allow MC to preset the most appropriate settings for any specific renderer. Of particular benefit would be a) determining if the renderer does or does not support SetNext, and b) determining what media formats “sinkProtocolInfo” that MC is allowed to push to the renderer. (There are a few other minor settings that could be determined too). I envision that MC could run these DMRA tests once automatically when a new renderer is discovered, and (if necessary) re-run them thereafter on manual command.

[MediaDemon]

Hi,

In answer to RoderickGI's questions:

Are you playing to the BubbleUPnP Local Renderer?
Yes

What Android device are you running BubbleUPnP on? (I'm running on a Sony phone, Android 9.)
I am using an "android box" (H96 Max X3 8k Ultra HD - Android 9)

Do you have Gapless playback turned on for the Local Renderer?
Yes

A couple of other things I should mention:
1) I am currently running the renderer with OpenHome mode enabled. This is so that playlist advance will still work even if the control point is not present (required when using my android DLNA server).

2) When playing from the JRiver DLNA Server I am using JRemote as the control point.

As JRiver does not support OpenHome I assume having this option enabled on my renderer is irrelevant. When playing from the JRiver DLNA Server there is certainly no local playlist stored on the renderer, the server seems to be taking care of track advance etc. but could the OpenHome option be causing an issue with the Disable SetNext feature? I'll try turning it off and report back in a few days.

[RoderickGI]

I am using an "android box" (H96 Max X3 8k Ultra HD - Android 9)

Okay, that is an Android box rather than an Android TV box, so using BubbleUPnP on it should be identical to what I tested on my Sony Xperia Android 9 phone. My observations above should be relevant to your situation. As they are both based on UPnP there is overlap between OpenHome and DLNA, but I have no idea if the OpenHome setting would cause any issues. I guess your testing will show that.

So you have the one Android box, and run both a DLNA Server and BubbleUPnP DLNA Renderer on it, by the sound of it. Although that DLNA Server would be separate to the BubbleUPnP Server installation I would guess, as BubbleUPnP Server is not a DLNA Server. I thought for a bit there that you were running BubbleUPnP Server on the Android box to get the OpenHome Renderer setting, but then I found the setting in the BubbleUPnP Client Local Renderer settings.


You could just run JRemote2 on that box, which would likely work correctly with Gapless playback. But then you would have to control it directly, as it isn't based on DLNA and doesn't accept a DLNA Controller input. It uses MCWS commands.

I have noticed when I play to BubbleUPnP on my phone that Gapless doesn't actually work properly. The last moment or so of all Tracks are cut off, rather than playing consecutive Tracks without a gap. I have a Playlist of short Tracks which have audio right up to the end, so I can hear this clearly. So maybe BubbleUPnP doesn't actually support Gapless properly, and that is what MC is detecting, so it disables SetNext support. If I disable SetNext support myself and play the Playlist, all Tracks are played correctly to the end with virtually no gap anyway.

So maybe MC is doing the correct thing, or trying to, and it is BubbleUPnP reporting that it supports SetNext, when it doesn't properly, that is the problem here.

[MediaDemon]

Hi,

Thanks for your feedback. Your assumptions about my set up are not quite right. I'm using the H96 android box as just a DLNA Renderer (running BubbleUpnp). I'm using JRiver MC as the DLNA server on a Win 10 PC. But I need a separate way of selecting what to play as I have no simple way of directly accessing the renderer in my setup.

So I either:
1) Run the BubbleUpnp Server overlay on top of the JRiver DLNA Server on on the server PC (to support the OpenHome feature) and run BubbleUpnp on android phones/tablets as DLNA Control Points. OpenHome enables use of multiple simultaneous Control Points - which I like.
Or;
2) Run JRemote2 on an android phone/tablet as a remote into the JRiver DLNA Server on the PC which plays directly to the DLNA Renderer.

However, of late BubbleUpnp has become less stable for me and has a few other limitations which is why I moved to using JRemote2. So it looks like I need to replace the BubbleUpnp Renderer to get reliable gapless playback. Does anyone have any suggestions for a good android DLNA renderer with true gapless support? I can live without OpenHome support.

Thanks.

[RoderickGI]

BubbleUPnP does seem to be getting lots of fixes recently, based on the number of times I see updates, and the changelogs. Maybe they will get around to fixing gapless playback, if it is their issue.

Does anyone have any suggestions for a good android DLNA renderer with true gapless support?

I've never looked, so can't recommend anything. Hopefully, someone else will.

[bob]

Version 27 is already here. Currently up to MC27.0.18 https://yabb.jriver.com/interact/index.php/topic,127068.0.html


Are you playing to the BubbleUPnP Local Renderer?
What Android device are you running BubbleUPnP on? (I'm running on a Sony phone, Android 9.)
Do you have Gapless playback turned on for the Local Renderer?
In BubbleUPnP on your Android device, select the hamburger menu "More", the Gear wheel for settings, scroll down to Local Renderer and select it, scroll down to Gapless playback and tick the box.

I have that ticked in BubbleUPnP, and play to the Local Renderer on the phone.
AndrewFG's Digital Media Renderer Analyser says BubbleUPnP supports SetNextAVTRansportURI (gapless play).

But MC keeps ticking the "Disable SetNext Support" setting for me as well.
I haven't tried to analyse the issue in detail, but the setting doesn't get ticked if I just let the Playlist play, or if I use the Next or Previous buttons in MC, but if I use the Seekbar to jump near the end of a track, it gets ticked immediately. There may be some logic to that, but it is annoying. It doesn't happen if I seek back or forth as long as the new position isn't near the end of the file, so not within the time MC would normally send the next file to the BubbleUPnP Renderer.
EDIT1: MC also does Disbales SetNext if I restart BubbleUPnP and then start Playback to the phone again. Not when BubbleUPnP connects, but when I start playback. That certainly should not happen.

There may be other conditions that make MC tick that box. Perhaps anything that interferes with sending the next URI to the Renderer in a timely manner. If you work out more conditions that make it happen, or can confirm the ones above, report it and JRiver may be able to fix the issue.

EDIT2: With all the mucking around I did above, Gapless playback wasn't working properly anyway. The audio was being cut off just before the end of the track. I was testing with short tracks that made this obvious. So maybe Gapless isn't really working properly in BubbleUPnP, or maybe that is also a MC issue.


I guess this post sheds some more light on the above posts in this thread. MC is turning off SetNext when it really shouldn't.

It's been quite a long time since MC has disabled SetNext upon failure.
Now it will only disable that option for devices that report it as NOT_IMPLEMENTED when getting the MediaInfo from the device.

Some time ago MC changed from sending the next track when near the beginning of the track being played to a calculated distance from the end of the track being played. This was in response to the way Volumio was accepting the next track. If the next track was sent during the time it was buffering the current track (which appears to have changed in Volumio) then the playing track immediately changed.

Part of the issue here is that SetNextAVTransportURI has some limitations as you can see above. Also, it's always going to be an issue if you seek within the last 20 seconds or so of the current playing track.

[RoderickGI]

It's been quite a long time since MC has disabled SetNext upon failure.

My mistake. That was a while ago.
24.0.36 (6/20/2018)
10. Changed: DLNA, change SetNext controller option disabling so that device errors don't disable SetNext only disable it if the renderer reports that it's not implemented.

Now it will only disable that option for devices that report it as NOT_IMPLEMENTED when getting the MediaInfo from the device.

In that case I'll look for communications from BubbleUPnP that tell MC SetNext is not supported.

But the behaviour I reported does occur, even though DRMA reports SetNext is supported, and Device Spy lists SetNextAVTransportURI in the AVTransport Desc.xml file.


EDIT:
Before I started looking for NOT_IMPLEMENTED communications I had to get MC to see BubbleUPnP on the phone. That has been problematic in the past. I had to force it to appear by playing files from MC to the local BubbleUPnP Renderer, and then after a while BubbleUPnP on the phone would appear in MC.

But I just realised that BubbleUPnP on the phone was also appearing as a Server in MC, and found that BubbleUPnP was running a Local Media Server.  I turned off that Local Media Server and the problem with SetNext being turned on disappeared. But alas, that wasn't a total solution. The problem still happened, but it was less often.

To find the setting and turn the Local "Media Server" off in BubbleUPnP:
"More > Settings > Local and Cloud" must be on. If it isn't the Local Media Server won't be running anyway. If you turn off "Local and Cloud" the Local Media Server appears to get turned off.
With "Local and Cloud" turned on, a three dot menu can be accessing either by choosing "Select library" in the top left corner if Local and Cloud is not already selected as the library, or in the top right corner if Local and Cloud is already selected as the library. Then select "Settings" and you will see a settings for a "Local Media Server". That will now be enabled. If "Advertise on LAN" is also enabled, then a "BubbleUPnP Media Server" library will appear in MC.

If both the "Local Media Server" and "Advertise on LAN" are selected the problem (MC ticks the "Disable SetNExt Support" setting) happens regularly.
If  the "Local Media Server" is enabled and "Advertise on LAN" is not, the problem seems to happen less often, but still happens on restarting playback to BubbleUPnP on the phone.
With "Local and Cloud" disabled, and hence  the "Local Media Server" is disabled, the problem still happens sometimes when a new Playlist is started in MC, or when playback is stopped for the current Playlist and the restarted.
Clicking the Seek Bar near the end of a track no longer causes the problem. Ever.
I was using short (10 to 30 second) tracks for testing earlier. Maybe that contributed to the issue with Gapless not working correctly.

The bad news is that with "Local and Cloud" disabled I can't play local (on the phone) files using BubbleUPnP.

So it looks like I will still have to look for NOT_IMPLEMENTED communications from BubbleUPnP to MC. Currently it looks like a BubbleUPnP problem.


Anyway, the good news is that the BubbleUPnP Renderer appears quickly and reliably when the BubbleUPnP "Local Media Server" is disabled.

[RoderickGI]

Anyway, the good news is that the BubbleUPnP Renderer appears quickly and reliably when the BubbleUPnP "Local Media Server" is disabled.

It seems I was a bit optimistic about that. BubbleUPnP still took a long time to show up after it had been closed and unused for some time. Sigh.


Anyway, I found a packet using Wireshark that seems to be BubbleUPnP on the phone telling MC that NextURI is not implemented. Is that what I should be looking for Bob?

This packet was sent shortly after playback was requested by MC.
EDIT: Actually, I just worked out how to save just the TCP Stream for the request and response that shows the issue, if you care to have a look. I've attached the Wireshark log to this post.

If this packet is what triggers MC to tick the "Disable SetNext Support" setting, then I can ask BubbleUPnP why that response is being sent.


================================================================================================
No.     Time           Source                Destination           Protocol Tgt Port Tgt MAC               Src Port Length Info
   2648 162.872953     192.168.0.11          192.168.0.10          HTTP/XML 50275    6c:f0:49:ef:0c:93     58645    691    HTTP/1.1 200 OK

Frame 2648: 691 bytes on wire (5528 bits), 691 bytes captured (5528 bits) on interface \Device\NPF_{AB5DF851-F1B0-4E61-B4D8-2DBECD8B6A15}, id 0
Ethernet II, Src: SonyMobi_3b:4f:39 (84:c7:ea:3b:4f:39), Dst: Giga-Byt_ef:0c:93 (6c:f0:49:ef:0c:93)
Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.10
Transmission Control Protocol, Src Port: 58645, Dst Port: 50275, Seq: 202, Ack: 931, Len: 637
[2 Reassembled TCP Segments (838 bytes): #2646(201), #2648(637)]
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Ext: \r\n
    Server: Linux/4.4.148-perf UPnP/1.0 BubbleUPnP/3.4.13\r\n
    Content-type: text/xml;charset=utf-8\r\n
    Date: Fri, 09 Oct 2020 01:06:27 GMT\r\n
    Content-Length: 637\r\n
    Connection: Keep-Alive\r\n
    \r\n
    [HTTP response 1/8]
    [Time since request: 0.013306000 seconds]
    [Request in frame: 2644]
    [Next request in frame: 2650]
    [Next response in frame: 2651]
    [Request URI: http://192.168.0.11:58645/dev/ba784573-ca6a-b7bd-0000-00002db86ac5/svc/upnp-org/AVTransport/action]
    File Data: 637 bytes
eXtensible Markup Language
    <?xml
    <s:Envelope
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
        <s:Body>
            <u:GetMediaInfoResponse
                xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
                <NrTracks>
                    0
                    </NrTracks>
                <MediaDuration>
                    00:00:00
                    </MediaDuration>
                <CurrentURI>
                    </CurrentURI>
                <CurrentURIMetaData>
                    </CurrentURIMetaData>
                <NextURI>
                    NOT_IMPLEMENTED
                    </NextURI>
                <NextURIMetaData>
                    NOT_IMPLEMENTED
                    </NextURIMetaData>
                <PlayMedium>
                    NONE
                    </PlayMedium>
                <RecordMedium>
                    NOT_IMPLEMENTED
                    </RecordMedium>
                <WriteStatus>
                    NOT_IMPLEMENTED
                    </WriteStatus>
                </u:GetMediaInfoResponse>
            </s:Body>
        </s:Envelope>

================================================================================================

[bob]

It seems I was a bit optimistic about that. BubbleUPnP still took a long time to show up after it had been closed and unused for some time. Sigh.

Anyway, I found a packet using Wireshark that seems to be BubbleUPnP on the phone telling MC that NextURI is not implemented. Is that what I should be looking for Bob?

This packet was sent shortly after playback was requested by MC.
EDIT: Actually, I just worked out how to save just the TCP Stream for the request and response that shows the issue, if you care to have a look. I've attached the Wireshark log to this post.

If this packet is what triggers MC to tick the "Disable SetNext Support" setting, then I can ask BubbleUPnP why that response is being sent.

Yes, that's exactly what turns it off.
BTW, IIRC enabling that is an option in BubbleUPnP and it's off by default.

[RoderickGI]

Thanks Bob.

Yes, I believe it is the "Gapless playback" setting in the "Local Renderer" settings. I have that turned on but it seems to make no difference.

I shall ask BubbleUPnP about this.

[RoderickGI]

While I'm waiting for a response from BubbleUPnP.

@AndrewFG
The DMRA reports that SetNextAVTransportURI is supported, yet the Wireshark trace shows that it is not implemented. The BubbleUPnP "desc.xml" file for the AVTransport UPnP Service, viewed via Device Spy, includes a SetNextAVTransportURI section, which mentions NextURI. It also includes a GetMediaInfo section that mentions NextURI. I don't understand if the values in those sections actually mean SetNext is supported though.

Is that all that the DMRA looks for to report SetNextAVTransportURI is supported, or does it send a GetMediaInfo Request to the Renderer to confirm support?

I guess I could run another Wireshark trace for the DRMA analysis and take a look. But not just now.

[RoderickGI]

Good news MediaDemon, MaxA, and everyone else reading.

My post to one of the BubbleUPnP support sites resulted in acknowledgement of the problem, and a promise to fix it. Apparently, the fix is trivial, so it should happen soon.

Watch for any version of BubbleUPnP above 3.4.13, and check its changelog.

[bob]

Good news MediaDemon, MaxA, and everyone else reading.

My post to one of the BubbleUPnP support sites resulted in acknowledgement of the problem, and a promise to fix it. Apparently, the fix is trivial, so it should happen soon.

Watch for any version of BubbleUPnP above 3.4.13, and check its changelog.

Great, thanks for pursuing this!

[RoderickGI]

BubbleUPnP version 3.4.14 is out now, and has the fix:

"Fixed playing gapless to the Local Renderer using JRiver Media Center for control not working."

I haven't tested it yet. MediaDemon, perhaps you could check it out?

EDIT: I just noticed, that the changelog that popped up showed the same version number, 3.4.13. But once installed the version is 3.4.14, which is also what is shown on the Play Store.