Print

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

[sorepinky]

Hi.  I've been using MC since version 17.  I have JRemote on Apple as well as Android, and like them both (Apple version is a lot better and Android still fails to bring up Last.FM artist bios most of the time), but I also really like to use BubbleUPnP as a control point sometimes.

I run audio only and have never wanted any of the video features.

About 2 stable versions ago in MC20 and still in 21.0.2, MC is failing to properly follow a stop command from BubbleUPnP correctly and is generally very sluggish.  When Stop is pressed on BubbleUPnP the next track begins about 10 seconds later.

I have taken this up with Bubbleguuum and sent him a log file.  His response is as follows:

"Thank you for the log.

The log shows that when you stop the track, MC takes 8s to notify the 'Stopped' state to BubbleUPnP.
BubbleUPnP has a timeout of 5s waiting for that state and consider all other 'Stopped' events
for track advance.
Not sure why this is taking so long. On my setup, MC send the 'Stopped' state immediately although I must do some more testing letting it run for longer.
You can try enabling 'Settings > UPnP Tweaks > Detect external stop'as a workaround.
Disable it if you notice side effects.

Cheers,
Bubblesoft"

I tried Bubbleguuum's suggested workaround, but it did not help.

I have MC installed on 3 Windows PCs and the behaviour is the same on all and with two different Android installs of BubbleUPnP.

As an aside, BubbleUPnP can control my Pioneer N-50 without this problem.

I don't recall reconfiguring anything on MC, so I was wondering if you guys have any ideas.  Thank you.

[JimH]

Are you also starting playback from Bubble or are you starting it another way?

[sorepinky]

Starting using Bubble.  MC on PC1 serving to itself.  Or MC on PC2 loading library from PC1.  Bubble as control point only - select library from PC1, renderer either MC on PC1 or PC2.
Strange behaviour only in past couple of months.  Have big library of over 1500 albums all on PC1 HDD.

PS...might get my friend "yoda" on this forum to ask Hilton to come over to sus' this out one day.  I used to be a member of that Sydney audio club (until I got fed up rating expensive cables that do nothing you can't do with Jaycar cables).  They both attended last Sunday's meeting (where I see there were more and more silly cables!).  ha ha.    

PPS (sorry).. also no third party antivirus.  Just using Windows' built in Firewall/Defender/Security Essentials (Win 7 and 8.1).

[JimH]

If you're using MC as a server on one PC and a client on another, they need to be the same version.

[sorepinky]

Yep.  Always have the same version - now 21.0.2 on all PCs.  Behaviour happens when PC2 (and PC3) is/are switched off and just using Bubble to control MC on PC1 to play from its own library to itself.  Anyway I like JRemote on the iPad and it works without any glitches whatsoever.  Just thought there might be some MC setting I'm missing to get Bubble to work properly again with it.  Maybe issue is on the bubble side. I don't know.

[AndrewFG]

First of all let me say that I don't have any hard evidence for this, but the following is a gut feeling..

Background: I also have sometimes seen cases where MC is very slow in sending status change notifications to my DMR Analyser (DMRA) application. The DMRA is also a kind of Control Point. But I have never really been able to track down why, because the behaviour comes and goes.

My gut feeling: I think, (but cannot definitely prove), that the delay is not actually due to MC; but rather due to my firewall application (in my case Norton). I think that the firewall is somehow trapping MC's NOTIFY messages, and throttling back the data transfer until it has checked if the contents are Ok (and it could even be that the firewall is sending some kind of fingerprint of the NOTIFY message contents to its home server on the cloud, before it finally allows it to pass through to its destination).

I think one might be able to check this by a) obviously, by just disabling the firewall application, or b) more sophisticatedly, with the firewall running, and using say WireShark, check for a time delay between the moment when MC opens the socket to the Control Point, and the moment when the NOTIFY actually comes through..

As I say, all the above is rather speculative...

[sorepinky]

Thanks for thoughts.  Norton!  You're kidding right?  
Anyway I just turned Windows Firewall off for a few minutes.  Still the same.
Just got a notification that Windows 10 is ready for PC1.  Maybe the problem will go away after that, but I doubt it given that the behaviour is identical on Windows 7 and 8.1.
Must run Veeam Endpoint backup first!

[JimH]

Andrew,
As you describe it, I think that would be the antivirus part causing the problem, not the firewall.  If it's taking too long to check the file, it could block MC from playing it.

[sorepinky]

OK just installed Windows 10.  What a breeze.  Only slight problem was the Thesycon driver for the Berkeley Alpha USB, but running the install program in compatability mode sorted that out.  Had to reinstall MC but it came up with a message to say to do it anyway.

Problem persists.  Will look at antivirus.  Am not running any third part antivirus.  Just Windows Defender now.

Edit.  Just temporarily turned off the "real time protecton" in Defender and it did not help.  JRemote and Gizmo working fine.

[AndrewFG]

I think that would be the antivirus part causing the problem, not the firewall.  If it's taking too long to check the file, it could block MC from playing it.

The OP's problem was nothing to do with whether MC can serve files. The issue is that MC's NOTIFY messages when its status changes from PLAYING to STOPPED are not getting through to the 3rd party Control Point before the CP itself times out. But whether you choose to call this a firewall or antivirus topic is irrelevant; my suspicion is the firewall / antivirus is holding back the NOTIFY messages until it is sure that the content is not bad; and you may just as easily call that function "firewall" or "antivirus"...

[sorepinky]

Another test:  It works fine when one instance of MC is pushing to another, so it seems that MC is notifying the 'Stopped' state to an MC controller, so how come it is taking 8 seconds to notify the 'Stopped' state to Bubble?  Or maybe Bubble just "thinks" it's taking 8 seconds and the problem lies with Bubble??  It's driving me nuts.  Bubble has worked with MC for me for years and suddenly this has rendered (ha ha) it useless.

[AndrewFG]

Did you actually try turning off your firewall / antivirus software temporarily?

[sorepinky]

Yes.  This does not seem to be a Windows Firewall or Defender issue.

[JimH]

Some security software can still cause problems when it is "disabled".  Uninstalling antivirus software is the only certain way to rule it out.

[AndrewFG]

I have a suggestion. You say that in your network when you try to push from Bubble to MC there is a problem, but when you push from MC to MC there is not. So that gives a 1:1 vote about where the problem could be. Therefore I suggest that you download the DMRA test application from my sig, and see if that is able to push to MC. Please report the test log file here, plus any other observations.

[sorepinky]

Done.  I ran the test for the Lenovo PC renderer in the music room from the PC that serves the library here in the study. Thx.  

Mmm.  I agree that waste-of-space software like Zone Alarm Security Suite and Norton ought to be completely uninstalled permanently, but I'm really not willing to completely uninstall the built-in Windows 10 Firewall and Defender features and leave my PCs as sitting ducks just to get this working.  It should work fine with a standard Windows install.  I'm starting to think it's Bubble's fault.  

Cheers, Ian

[AndrewFG]

Let's see the result of the test before you start uninstalling software and things..

[AndrewFG]

Ok. I got the log file. Many thanks. However I was hoping for the test log file and not the Http log file that you sent me. So could you please also send me the test log?

Nevertheless I was able to dig into your Http log and as far as I can tell, MC is working perfectly against the DMRA test application; specific events are as follows:

• 15:08:29.115  DMRA issues #SetAVTransportURI command (track duration=00:00:28.000)
• 15:08:29.302  DMRA issues #Play command
• 15:08:29.458  MC notifies TRANSITIONING
• 15:08:29.662  MC notifies PLAYING
• << expected end of play time >>  15:08:57.662 = 15:08:29.662 + 00:00:28.000
• 15:08:51.553  MC notifies TRANSITIONING
• 15:09:01.054  MC notifies STOPPED
• << delay stopped status vs. expected end of play time >>  0:0:3.392 = 15:09:01.054 - 15:08:57.662

In other words, MC executes the #Play command within 0.360 seconds. It gives 0.150 seconds early warning "TRANSITIONING" concerning impending change to Playing state. It gives 7 seconds early warning "TRANSITIONING" concerning impending return to Stopped state. And it finally completes the transition to Stopped status withinn 3.39 seconds of the estimated end of play time. And I certainly don't see any evidence of anti virus / firewall applications artificially holding back the notifications.

NEVERTHELESS your OP problem did admittedly relate to the case where the Control Point (Bubble) sends an early manual #Stop command to MC. And this case is not one that is explicitly tested by my DMRA application. So it is indeed still possible that in that particular case MC might not be issuing its "TRANSITIONING" and "STOPPED" notifications in a timely manner. But I think someone at JRiver (bob) will need to check into this and respond accordingly..

[JimH]

Here's another Bubble user with a problem:
http://yabb.jriver.com/interact/index.php?topic=99964.msg692631#msg692631

Andrew, please let me know if you would like the threads merged.

[JimH]

I'm really not willing to completely uninstall the built-in Windows 10 Firewall and Defender features and leave my PCs as sitting ducks just to get this working.

No one is suggesting that you leave your machine permanently without AV, but it is the only way to eliminate the possibility that the AV is causing the problem.

In this particular case, AndrewFG is on it, so you'll probably soon have a better idea of where the problem is.

[AndrewFG]

Andrew, please let me know if you would like the threads merged.

Hmm. It is not obvious that they relate to the same issue. So better keep them separate for the time being. (??)

[bob]

Keeping this as simple as possible, one MC PC with one local library, first I need to know the DLNA server settings in MC (which template, audio format settings, etc).
Next, is this consistently reproducible?
Third, what file types are you playing?

[sorepinky]

Sorry for sending wrong file, but I cannot see where to create another log file type within the test software*.  I did run a test and it played an MP3 to the Lenovo install of MC21.  I watched the Lenovo with Remote Desktop and it did play.  The software interface reported:

Playing media item #1
  Media type=mp3
  Mime=audio/mpeg
  Bits=16
  Channels=2
  Rate=44100
  Duration=28
Play success => Start Ok / Stop Ok

*  oops.  OK I think maybe I did fumble my way to creating the file and will email it to you now.

Cheers.

Addend:  I looked at the other thread and think that I agree with klapaciuss that the general sluggishness of MC under Bubble control started around the time of the MC20 update that he refers to.

[AndrewFG]

Ok. I got your email with the renderer report thank you. That report also confirms that the playing of the test MP3 file worked perfectly.

Your original problem was that when Bubble sends a Stop command, it takes MC 8 seconds before notifying a state change to the Stopped state. This is something that my DMRA application does not test. And bob is I think now volunteering to have a look at that specific case, and he asked some specific questions about your settings and the type of file that you were trying to push from Bubble to MC. We can take part of the answer to bob's questions from the DMRA report below. However you need to inform Bob about the track that you were trying to push (media format, bit depth, channels, sample rate).

Code: [Select]

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

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

[sorepinky]

All of my files are stereo (2 channel) FLACs, either ripped from CD using dBPowerAmp as 16/44 (or the occasional HDCD that ends up as 24/44), or downloaded as 24 bit 96kHz or various others.  The behaviour when using Bubble to push from MC to MC is the same for all of my music files.

A thing that I do notice is that when I press Stop when using either Gizmo or JRemote, the little animated spectrograms at the top of the MC interface at either side of the track info subside quite rapidly.  When I press Stop when using Bubble, the animations just hang there in a kind of frozen state for a much longer time.

I should also state that exactly the same behaviour happens consistently when using Bubble to control MC on PC1 to play to itself.  It is not related to the library being on PC1 and the other player being on PC2.  I tried to use the Whitebear program to run another set of tests on PC1 only, but it reported the Associated MC DLNA Server as "<FORBIDDEN>:  Media Center 21 Renderer, from Media Center 21 ( on this computer )".

Also it is not just misbehaviour after pressing Stop with Bubble.  Even say selecting the next track causes long delays where the graphic spectum analiser at the top of the MC interface hangs for a long time.

IMO, something happend at a late upgrade of MC20.

As mentioned earlier, the problem is not present when using Bubble to play from the MC library on PC1 to a Pioneer N-50 network audio player.  Apart from it's lack of gapless support, the Pioneer is responsive and the sluggishness and strange behaviour of starting to play the next track after Stop is pressed on Bubble is not present.

It therefore appears to me that the problem is in MC's DLNA Renderer when controlled with Bubble.

Anyway I'm not here to whinge - just help as I am happy to use JRemote.  I have created a txt file for the Pioneer and will email it FYI.

[AndrewFG]

I should also state that exactly the same behaviour happens consistently when using Bubble to control MC on PC1 to play to itself.  It is not related to the library being on PC1 and the other player being on PC2.  I tried to use the Whitebear program to run another set of tests on PC1 only, but it reported the Associated MC DLNA Server as "<FORBIDDEN>:  Media Center 21 Renderer, from Media Center 21 ( on this computer )".

Aha.

Just an explanation about this "FORBIDDEN" message..

Of course it is allowed to use UPnP/DLNA functionality to push a track from a library server (DMS) running on one instance of MC (running on one PC) to a remote media renderer (DMR) running on another instance of MC (running on a different PC).

But it makes no sense to use UPnP/DLNA functionality to push a track from a library server (DMS) running on an instance of MC to a media renderer (DMR) running on the same instance of MC. The reason is that MC can spool the music samples internally from its library directly to its audio driver output, and so there is absolutely no point choosing a roundabout route of pushing the track out of its DMS back into its own DMR. Indeed MC actually hides its own renderers on the same machine, to prevent the user from even contemplating doing that. Therefore my DMRA test application reports such a combination (MC DMS pushing to itself) as "forbidden".

The fact that you mention this point, makes me wonder if you are indeed trying to use Bubble as a Control Point to command MC to serve tracks from its own DMS to its own DMR. Can you please confirm?

If that is the case (MC serving to itself), then it is indeed quite possible that you may encounter errors. Because as mentioned above, MC is not actually designed to serve to itself, and certainly I doubt that anyone at JRiver would have evaluated such a test case. I can imagine several possible problems -- namely a) at the network level it means that the same network card is opening a TCP socket to another port on the same network card, and there may thus be pipelining issues within the network card driver, b) such self routing behavior might indeed arouse the suspicions of a firewall or a/v program, c) if the Bubble CP is also on the same machine as MC then the TCP routing might be done via the loopback IP address 127.0.0.1 rather than the PC's external IP address, and again depending on your PC this may or may not work, d) if the TCP routing is indeed going over 127.0.0.1 then the renderer's NOTIFY messages (which are UDP mono-casts) would also be routed via 127.0.0.1 and so may also be suffering from routing anomalies, and last but not least e) it may be that MC's server and client threading model may not be designed for serving to itself, and that the two threads may be blocking each other and (presumably) hitting time outs.

The potential problems a) thru d) are network / routing issues that JRiver would not really be able to solve; whereas the potential problem e) may be something that JRiver could possibly address.

[sorepinky]

Yes I have been using Bubble as a Control Point to command MC to serve tracks from its own DMS to its own DMR for several years without issue, but after a late build of MC20 it all went weird.  There had been no other changes to my router or anything.  Just one day it went whacko.  I'm now using MC21 and it's the same.

I have been using Bubble for years as it was the most stable controller for Android available and is still the best interface for older Android hardware.  JRemote is now the better answer for newer devices, but there would be plenty of people out there with older Android tablets like my Toshiba Thrive.

Also and as already noted, the behaviour change was identical on PC2 (Lenovo) at that MC20 upgrade.  When using Bubble there, Bubble sees the library on PC1 and sees all the other renderers in the house (MC on PC1, Pioneer N-50 and MC on PC2) and can push from PC1 to any of them.  Now only the Pioneer stops properly when Stop is pressed on Bubble whereas PC1 and PC2 start playing the next track after about 8 or 10 seconds.  General responsiveness to any Bubble command slowed big time on PC1 and PC2.

This was never the case using MC18, MC19 or earlier builds of MC20.

BTW Pause works fine - very responsive, select next track very slow.

I just tried this using MC21 (now build 4) as renderer on a third PC - a Sony Vaio laptop - and it's exactly the same...  slow and next track plays after stop.

[AndrewFG]

Thanks for the additional reports. However I suggest we focus on fixing your original issue (MC DMS -> Bubble CP -> MC DMR) rather than confusing the discussion playing around with other combinations.

I tried out your configuration myself (MC DMS running on MC21 on a Windows 10 PC -> Bubble CP running on a Samsung Android phone -> MC DMR running on the same MC21 on the same Windows 10 PC). And in my case it worked absolutely perfectly. Indeed it seemed almost too good to be true. And indeed I discovered a very interesting thing (it is too good to be true), because when you tell MC to serve a track to itself it sees that the track is indeed on its own server so instead of serving the track to itself from its HTTP server to its HTTP client it bypasses the whole HTTP procedure and simply plays the track locally. You can tell this by looking at MC's Playing Now screen, which shows it playing a file name ( "C:/ something" ) rather than a track URL ( "http:// something" ). I was surprised to see this behavior and I think it is really rather cool..

But back to your original question which was: When MC is playing to itself as described above, and the Bubble CP sends a Stop command to the MC DMR, why does it take MC 8 seconds before it sends its NOTIFY STOPPED status back to the Bubble CP?

To answer this question, can you please tell us some more about a) your network equipment, topology and settings, b) the O/S of the two devices concerned, c) format and attributes of the track you were pushing, and on what drive is it located, and d) details of any firewalls or a/v software running on the two devices concerned.

[sorepinky]

Well yes Bubble is a very slick piece of work.

I just typed up a huge summary of my set-up and then thought "stuff it" and did another test.  Anyway going with my hunch that the problem is in the MC renderers, I have FINALLY found it!!!  

OK it is in the JRiver's Stop and Pause settings under Tools -> Options -> Audio -> Stop, Seek & Skip.

I use gapless and also like Stop as Fadeout: (Fast) and it works perfectly under Gizmo and JRemote, but this is where it goes bananas under Bubble control.

Changing it to Stop: Immediate solves the problem (but leaves you with a setting you don't want for JRemote etc.).

Now I can't say with 100% certainty when I set that to Fadeout (fast) and if that's when the problem started, or if something changed within MC after earlier builds of MC20, but if it did, can JRiver look at it and maybe put it back?

Thank you Andrew for showing an interest in this.  At least others will now know how to fix it in the meantime.

Give it a try with Fadeout and you will see exactly what I have been on about.

I will tell Bubbleguuum.

Cheers,
Ian

[AndrewFG]

Well yes Bubble is a very slick piece of work.

I will tell Bubbleguuum.

Actually this clever behaviour is not due to slickness in Bubble but rather due to slickness in MC. Give praise where praise is due.

Congratulations on finding the cause of the problem. It is a classic example of the law of unintended consequences. The guys at JRiver made a cool decision to make remote control playing work more like local playing. But it took along some baggage that should not in this case have been taken..

I would say there is no need to inform Bubbleguuum, since he has nothing to do. Instead let us take this thread to its proper conclusion, and persuade the JRiver guys to make a fix..

[sorepinky]

I thought it went without saying that MC is slick.

Software that is IMO "unslick" like Zone Alarm and Acronis get uninstalled around here.

Anyway I told Bubbleguuum for his info. coz' he's a nice guy.

Cheers.

[AndrewFG]

Actually on second thoughts, there may indeed be something to tell Bubbleguuum about...

I did not actually do the tests, but I suppose that when Bubble sends the Stop command, MC pretty quickly sends a NOTIFY TRANSITIONING status message, and that, depending on how long a fade out setting you have set in MC options, it sooner or later sends a NOTIFY STOPPED message.

Your problem was because Bubble times out waiting for the STOPPED status. And I suspect that Bubble is not taking the TRANSITIONING message as an acknowledgement that its Stop command succeeded. So Bubbleguuum might want to think about tracking the TRANSITIONING state too.

Admittedly tracking of the TRANSITIONING state can be a bit tricky, since there are often other valid reasons why a renderer may go into this state (for example if there are bandwidth issues that cause buffering delays). So it might not be a perfect solution. But it is worth looking into anyway.

Also I will have a look into the DLNA specifications tomorrow, since I seem to recall that there is a regulation about the maximum time window between (say) a Stop command and the respective NOTIFY STOPPED message. If that is the case, then both MC and Bubble may need to modify their code to respect that regulation. I will report back after I have re read the specifications..

EDIT: the following is a quote from the DLNA Guidelines:

7.4.1.6.16.1   [GUIDELINE] If a UPnP MediaRenderer enters the TRANSITIONING state, it shall change to the state desired by the control point within 30 s. The longest period of time that a MediaRenderer device is permitted to remain in the TRANSITIONING state is 30 s.

[sorepinky]

Good man...  anyway I have directed Bubbleguuum to this thread.

Also FYI, I just remembered that the crossfade was working under Bubble control up to a certain build of MC20 (and/or possibly Bubble build too).  I remember it because although the fade-out part of say Track 1 worked, the fade-in part (supposed to cross nicely with the fade-out) of Track 2 didn't.  Rather Track 2 came in at full volume from it's beginning.  A "proper" cross-fade always worked/works under Gizmo and JRemote (which I appreciate are dedicated JRiver controllers).

[AndrewFG]

UPNP has two playing modes, namely basic and gapless.

In basic mode the CP pushes an individual track, waits until that track has played, then pushes the next, and so on. So in this mode a fade over is impossible. At best you would get a fade out at the end of each track, but the next track will start as if it is a complete new play operation (which indeed it is).

OTOH in gapless mode, the CP pushes a pair of tracks (the current and the next one), waits until the current track has played, then the next track becomes the current, and then the CP pushes the following next track, and so on. In this mode fade over is entirely possible.

If you noticed a behaviour change due to some build of MC or Bubble, it could be that the combination switched back from using gapless mode (with fade over) to basic mode (without). I think that MC has supported gapless since v19. But perhaps Bubble stopped using gapless mode against MC at some time?

[sorepinky]

Bubble has in its "UPnP Tweaks" settings an "Enable gapless control" check box that I always have checked.  Likewise I have always had the Enable gapless feature of MC checked.  When you press Play at the beginning of an album on Bubble, Track 1 appears on the MC interface and plays.  A second later, Track 2 appears below it ready for transition.  It works fine.

The bahaviour change that I describe is not related to the gapless transition from the end of a track to the beginning of the next track, but what happens when you press Next or Stop during play.  When it was working under older builds of MC 21 and prior, that was where the cross-fade wasn't quite correct, but it nevertheless stopped or got you to the next track as desired.  Now it just doesn't work properly at all unless you select "Stop: Immediate" in MC settings.

[AndrewFG]

Quote from SorePinky:  OK it is in the JRiver's Stop and Pause settings under Tools -> Options -> Audio -> Stop, Seek & Skip. I use gapless and also like Stop as Fadeout: (Fast) and it works perfectly under Gizmo and JRemote, but this is where it goes bananas under Bubble control. Changing it to Stop: Immediate solves the problem (but leaves you with a setting you don't want for JRemote etc.).

Ok. I did my own tests and I can confirm that what Sorepinky describes also happens on my setup too. Namely that setting Stop, Seek & Skip. to Stop as Fadeout: (Fast) does indeed cause MC to delay sending its NOTIFY STOPPED message by about 7.5 seconds. I find it odd that a fast fadeout of the order of 1..2 seconds should delay the notification by so much as 7.5 seconds, but there it is.

Nevertheless, after careful consideration I am not convinced that MC is really "guilty", nor that Bubble is really "innocent". As you can see from the two quotes below, if Bubble does not receive a NOTIFY STOPPED message within 5 seconds of sending a #Stop command, then it interprets the late arriving NOTIFY STOPPED message as indicating a track change (that makes sense to me). However the DLNA guidelines say that a renderer must send its NOTIFY STOPPED message within 30 seconds, and indeed MC is sending a NOTIFY TRANSITIONING message within a few seconds of the #Stop command and also it is sending a NOTIFY STOPPED message within 30 seconds too. So both parties are right somehow.

From Bubbleguuum:  The log shows that when you stop the track, MC takes 8s to notify the 'Stopped' state to BubbleUPnP. BubbleUPnP has a timeout of 5s waiting for that state and consider all other 'Stopped' events for track advance.

From DLNA Guidelines:  If a UPnP MediaRenderer enters the TRANSITIONING state, it shall change to the state desired by the control point within 30 s. The longest period of time that a MediaRenderer device is permitted to remain in the TRANSITIONING state is 30 s.

So how to proceed?

Personally I think that

1) Bubble should be more lenient about handling of delayed NOTIFY STOPPED messages. I think it should try to recognise the #Stop => NOTIFY TRANSITIONING => NOTIFY STOPPED pattern, and therefore not misinterpret NOTIFY STOPPED messages in that context as signifying a track change.

and

2) MC should send its NOTIFY STOPPED message sooner. Given that the fade on stop feature is a nice feature to have, I think it is reasonable to have a certain delay between the NOTIFY TRANSITIONING and NOTIFY STOPPED messages. I guess a fade out of 3..5 seconds is good enough. So I would expect MC to not extend the period between the NOTIFY TRANSITIONING and NOTIFY STOPPED messages by more than 3..5 seconds either.

[bob]

Ok. I did my own tests and I can confirm that what Sorepinky describes also happens on my setup too. Namely that setting Stop, Seek & Skip. to Stop as Fadeout: (Fast) does indeed cause MC to delay sending its NOTIFY STOPPED message by about 7.5 seconds. I find it odd that a fast fadeout of the order of 1..2 seconds should delay the notification by so much as 7.5 seconds, but there it is.

Nevertheless, after careful consideration I am not convinced that MC is really "guilty", nor that Bubble is really "innocent". As you can see from the two quotes below, if Bubble does not receive a NOTIFY STOPPED message within 5 seconds of sending a #Stop command, then it interprets the late arriving NOTIFY STOPPED message as indicating a track change (that makes sense to me). However the DLNA guidelines say that a renderer must send its NOTIFY STOPPED message within 30 seconds, and indeed MC is sending a NOTIFY TRANSITIONING message within a few seconds of the #Stop command and also it is sending a NOTIFY STOPPED message within 30 seconds too. So both parties are right somehow.

So how to proceed?

Personally I think that

1) Bubble should be more lenient about handling of delayed NOTIFY STOPPED messages. I think it should try to recognise the #Stop => NOTIFY TRANSITIONING => NOTIFY STOPPED pattern, and therefore not misinterpret NOTIFY STOPPED messages in that context as signifying a track change.

and

2) MC should send its NOTIFY STOPPED message sooner. Given that the fade on stop feature is a nice feature to have, I think it is reasonable to have a certain delay between the NOTIFY TRANSITIONING and NOTIFY STOPPED messages. I guess a fade out of 3..5 seconds is good enough. So I would expect MC to not extend the period between the NOTIFY TRANSITIONING and NOTIFY STOPPED messages by more than 3..5 seconds either.

Since I personally dislike fadeout it's just about the first thing I disable when installing MC which explains why I wasn't able to reproduce this issue.

Does this work with MC setup as both the renderer and server or does it need a separate server to reproduce?

[AndrewFG]

Does this work with MC setup as both the renderer and server or does it need a separate server to reproduce?

The problem occurs with just one instance of MC i.e. the CP tells MC server to push to the MC renderer on the same instance...

[bob]

The problem occurs with just one instance of MC i.e. the CP tells MC server to push to the MC renderer on the same instance...

Thanks, I'll need to set this up in the debugger. We don't see any reason for the longer delay.

[sorepinky]

The problem also occurs with two instances of MC - i.e. with Bubble controlling MC on PC2 to play from an MC library on PC1.

[bob]

The problem occurs with just one instance of MC i.e. the CP tells MC server to push to the MC renderer on the same instance...

Just reproduced it. Still checking...

[bob]

Just reproduced it. Still checking...

Fixed in the next build (>= 21.0.10)

[AndrewFG]

Brill. Thanks bob.

[sorepinky]

Ditto.  Looking forward to seeing if the cross-fade works properly...  shall report. 

[bob]

Brill. Thanks bob.

Thanks for your diagnosis and the reports from sorepinky. Made it a lot easier to track down!

[sorepinky]

Just downloaded 21.0.11 and it's working well with BubbleUPnP again.  Very responsive actually.

Probably a DLNA thing that you can do nothing about, but the crossfade still doesn't work when selecting a new track with BubbleUPnP part way through a playing track.  Fade-out works, but the next track comes in at full volume (no fade-in across the fade-out).  AFAIK it never did.

Cheers.  This is awesome.  

[AndrewFG]

Probably a DLNA thing that you can do nothing about, but the crossfade still doesn't work when selecting a new track with BubbleUPnP part way through a playing track.  Fade-out works, but the next track comes in at full volume (no fade-in across the fade-out).

Hmm. Actually I think that MC could indeed possibly make this work better. There are two use cases, namely a) regular playing and b) gapless playing.

In case a) the CP waits for the current track to end before it pushes the next track to play. The CP pushes a series of SetAVTransportURI commands one by one. In this case a fade in of a following track is not possible. Each SetAVTransportURI command must be considered as a fresh start, so each track must start at full volume.

In case b) the CP pushes a "first" track plus a series of "next" tracks. The CP pushes a single SetAVTransportURI command followed by a series of SetNextAVTransportURI commands. In this case it would (in theory) be possible for MC to do a fade in on tracks that have been pushed by the SetNextAVTransportURI command, and a full volume start on tracks that have been pushed by the SetAVTransportURI command.

This could be a feature request for a future version of MC. Perhaps Bob can comment on this?

[bob]

Hmm. Actually I think that MC could indeed possibly make this work better. There are two use cases, namely a) regular playing and b) gapless playing.

In case a) the CP waits for the current track to end before it pushes the next track to play. The CP pushes a series of SetAVTransportURI commands one by one. In this case a fade in of a following track is not possible. Each SetAVTransportURI command must be considered as a fresh start, so each track must start at full volume.

In case b) the CP pushes a "first" track plus a series of "next" tracks. The CP pushes a single SetAVTransportURI command followed by a series of SetNextAVTransportURI commands. In this case it would (in theory) be possible for MC to do a fade in on tracks that have been pushed by the SetNextAVTransportURI command, and a full volume start on tracks that have been pushed by the SetAVTransportURI command.

This could be a feature request for a future version of MC. Perhaps Bob can comment on this?

I'll take a look with Matt and see how this is supposed to work...

[sorepinky]

Just wondering how that's going.   

[sorepinky]

Also on the latest stable build of MC21 the track change "switch tracks" with standard gapped does not work properly.  As a trial with a single instance of MC playing from its own interface to the PC sound card and with track change set on Standard (gapped) with say 5 seconds there is no 5 second gap.  It just goes straight into the next track.

Maybe the whole thing needs looking at.