Print

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

[AndrewFG]

Hi bob,

When MC is pushing gapless playback to a renderer via the SetAvTransportUri plus SetNextAvTransportUri procedure, it exhibits unexpected behaviour when the user presses MC's seek next or previous track buttons.

When one moves MC's progress bar to a position close to the end of a track, it sends a seek (time position) to the renderer; and the renderer moves to that postion, plays on to the end of the track, and then starts playing the following track (the one that had been set by SetNextAvTransportUri); and then MC sends the next SetNextAvTransportUri as you would expect.

However, if one presses the seek next track button, MC does not follow the above algorithm; rather it forces a new SetAvTransportUri (thus erasing the two current-plus-next entries in the renderer's playlist). First of all, this means that the skip to the next track is not gapless. Furthermore, (and much worse), once you have done such a skip next track command, it seems that MC switches off using the gapless SetAvTransportUri plus SetNextAvTransportUri procedure entirely thereafter -- all subsequent track transitions are pushed via SetAvTransportUri only (SetNextAvTransportUri is no longer used), and so gapless playback gets sacrificed for all subsequent track transitions in the playlist.

Note: Obviously you have to force a new SetAvTransportUri if the user presses the seek previous track button. But also in this case, it seems to switch off MC from using gapless SetAvTransportUri plus SetNextAvTransportUri procedure thereafter, and so again gapless playback gets sacrificed for all subsequent track transitions in the playlist.

[bob]

It looks like the skip logic is conflicting with the logic that tries to detect broken renderers. I'll check into it. Thanks for the detailed report!

[AndrewFG]

It looks like the skip logic is conflicting with the logic that tries to detect broken renderers. I'll check into it. Thanks for the detailed report!

Hi bob,

I am starting to experiment (as promised) with adding .pls and .m3u support to Whitebear. After studying the issue, one question for me is, how the CP determones the correct point in time when it shall send the next SetNext command.

1) When a renderer is playing single tracks, the CP polls GetPositionInfo, (or subscibe to LastChange::CurrentTrackUri), and when a CurrentTrackUri change event occurs, the CP uses this to trigger the next SetNext.

2) If the CP sends Next() or Seek(Track+1) this causes a CurrentTrackUri event exactly as if the track had played out, and so triggers the next SetNext exactly as in 1).

3) If the CP sends Previous() or Seek(Track-1), and assuming the player had a previous track to play, this also causes a CurrentTrackUri event, but this event should not trigger a SetNext, because the "next" track is the one we are just leaving.

4) If the renderer is playing a .m3u or .pls playlist, CurrentTrackUri change events will occur whenever the renderer moves forwards or backwards through the playlist. But change events within the playlist should not trigger a SetNext. Indeed, analog to 1) & 2), only change events over the boundary from the last track in the current playlist to the first track in the next playlist should trigger a SetNext. And, analog to 3), change events over the playlist boundary in the opposite direction should also not trigger a SetNext, because the "next" playlist is the one we are just leaving.

It is amazingly hard to get my head around all the permutations. And indeed in MC you are trying to double guess whether the renderer supports SetNext, so probably you have even more permutations to handle.

=> Can you please share with us the logic that you currently use for triggering SetNext? Perhaps an open discussion may help us to resolve the "perfect" logic that works with all permutations...

[bob]

Sorry for the slow reply, been doing mostly server work lately so I'm somewhat behind on these issues.

Once we control a zone, and we are in the playing state, we check to see if nexturi is implemented in GetMediaInfo (this happens about 5 seconds after a track starts to play on the renderer).
If it is and if there is a next item in our playlist, we send the uri and metadata with setnext.
If nexturi isn't supported or the setnext call fails, we don't try again until the track advances the old fashioned way.
We won't try setnext again until our current track changes (as updated by the GetPositionInfo calls).

rinse and repeat.

[AndrewFG]

We won't try setnext again until our current track changes (as updated by the GetPositionInfo calls).

Just to be completely sure: in your above-mentioned GetPositionInfo call, can you confirm that it is the TrackUri (or the TrackNumber, or the TrackLength, or the TrackMetadata) that you use as the indicator that the track has changed? I suppose that under normal circumstances, when a track changes, then all of these arguments would show a change, but who knows?

[bob]

Yes that's correct, it's trackuri from getpositioninfo. Remember when we were talking about it during development and I was using getmediainfo. You suggested that might not be supported as well as getpositioninfo (and it turned out I found devices on which it wasn't working right).

[AndrewFG]

Once we control a zone, and we are in the playing state, we check to see if nexturi is implemented in GetMediaInfo (this happens about 5 seconds after a track starts to play on the renderer).
If it is and if there is a next item in our playlist, we send the uri and metadata with setnext.
If nexturi isn't supported or the setnext call fails, we don't try again until the track advances the old fashioned way.
We won't try setnext again until our current track changes (as updated by the GetPositionInfo calls).

rinse and repeat.

Ok. I am considering now the scenario where the CP passes a .pls url in SetAvTransportUri...

The renderer obviously unwinds the pls file contents into a series of music track urls that it puts in its internal play list, which it starrts to play. GetPositionInfo will return each of the track urls in turn, and GetMediaInfo will return the original .pls url throughout.

If SetNext is supported then it can line up a second .pls (or regular music track) to play after the first .pls is finished. In this case GetPositionInfo will return a different url as the player moves through each track in playlist #1 and then also in playlist #2. Whereas GetMediaInfo will either return the url of .pls #1 or the url of .pls #2 depending upon whether the current playing track is in playlist #1 or #2.

So, it seems to me that you should not be using a change in the (track) url reported by GetPositionInfo to trigger the SetNext call. Instead, you should be using a change in the (.pls or track) url reported by GetMediaInfo to trigger the SetNext. Or ??

[bob]

Unfortunately, there are broken devices that don't implement  GetMediaInfo properly so I can't use it. The Sony Media Player is one such IIRC.

[AndrewFG]

Unfortunately, there are broken devices that don't implement  GetMediaInfo properly so I can't use it. The Sony Media Player is one such IIRC.

Ok. Understood. And Sony is a member of the UPnP forum steering committee too; shame on them...

I think that when you are monitoring GetPositionInfo (or indeed GetMediaInfo) you should not only detect when the media url changed, but you should also check what it changed to...

I was doing some tests with two CPs (MC18 and the Intel Tool) controlling one renderer (Whitebear) in parallel. The case that I am testing is when MC18 pushes one track with SetAVt.. and subsequent tracks with SetNext. If the Intel CP sends a Next command, then the track URI changes, and MC18 detects that change via GetMediaInfo and advances the display in its own playlist; so far all is as it should be. However if the Intel CP sends a Previous command, the track URI also changes, and again MC18 detects that change via GetMediaInfo, and again it advances the display in its own playlist. In other words, the renderer is playing the prior track whereas MC18 is displaying the subsequent track...

[bob]

Ok. Understood. And Sony is a member of the UPnP forum steering committee too; shame on them...

I think that when you are monitoring GetPositionInfo (or indeed GetMediaInfo) you should not only detect when the media url changed, but you should also check what it changed to...

I was doing some tests with two CPs (MC18 and the Intel Tool) controlling one renderer (Whitebear) in parallel. The case that I am testing is when MC18 pushes one track with SetAVt.. and subsequent tracks with SetNext. If the Intel CP sends a Next command, then the track URI changes, and MC18 detects that change via GetMediaInfo and advances the display in its own playlist; so far all is as it should be. However if the Intel CP sends a Previous command, the track URI also changes, and again MC18 detects that change via GetMediaInfo, and again it advances the display in its own playlist. In other words, the renderer is playing the prior track whereas MC18 is displaying the subsequent track...

I think what we'll do for this case is to detect the change and if it's to something other than what we expect, dis-engage from actively controlling the device and go into the passive display mode.

[AndrewFG]

I think what we'll do for this case is to detect the change and if it's to something other than what we expect, dis-engage from actively controlling the device and go into the passive display mode.

Yes. That makes a lot of sense.