Print

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

[AndrewFG]

Hi bob,

Another user observed the following behaviour with MC pushing tracks to Whitebear...

Backgound: In MC you set up an initial Play To playlist with say three tracks in it e.g. [A, B, C], and A is playing say half way through the track, and you then insert an extra track D so the playlist becomes [A, D, B, C].

Result: When track A has finished playing, track B plays. The Squeezeboxes show metadata for track B. MC shows metadata for track D apart from the track length info which is that for track B. In the MC player view the green active player icon is on track D.

I guess this is because MC pushes track A via SetAvTransportURI and track B via SetNextAvTransportURI, but when the user inserts track D before track B into MC's playlist, it should update the id of the next track by pushing track D via SetNextAvTransportURI.

Or ??

[bob]

Sounds correct. Hopefully the renderer will do the right thing when it gets another setnext while it's already got one in the queue...

[AndrewFG]

Sounds correct.

Soo. I think this should be an improvement for you to make in MC. Or ??

Hopefully the renderer will do the right thing when it gets another setnext while it's already got one in the queue...

Indeed. The risk is probably when the current track is very close to the end, and there may not be sufficient time for it to ditch any prefetched stream data and start a new prefetch. At the worst though I expect that the track transition would just end up being a bit gappy...

[bob]

Soo. I think this should be an improvement for you to make in MC. Or ??

Yeah, just something else to add to the growing list...

[vagskal]

A friendly Bump!

Any progress on this? I am still affected by it.

[bob]

A friendly Bump!

Any progress on this? I am still affected by it.

It REALLY is on the to do list. Just been buried by server work lately.

[vagskal]

OK, thanks for the reply. Sounds promising.

[AndrewFG]

Just been buried by server work lately.

Hi bob,

To try to help your workload, here are the use cases which I think need to be addressed.

All three use cases apply only to the case where MC18 is working with a renderer which supports SetNextAvTransportUri (I think it already works perfectly on renderers which do NOT support SetNextAvTransportUri).

Case #1 - (User inserts a track to play next)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A is currently playing.
User Action:  User inserts track C to play next.
MC Response:  MC18 shall select track C via SetNextAvTransportUri.

Case #2 - (User presses Skip Next)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A is currently playing.
User Action:  User presses Skip Next button.
MC Response:  MC18 shall send the Next command. No other direct action is needed, however the renderer will change tracks, and that change will itself trigger MC to send its next SetNextAvTransportUri command as usual.

Case #3 - (User presses Skip Previous)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A has played through, and playing has advanced to track B. MC18 has then selected track C via SetNextAvTransportUri.
User Action:  User presses Skip Previous button.
MC Response:  MC18 shall select track A via SetAvTransportUri, send the Play command, and select track B via SetNextAvTransportUri.

[bubbleguuum]

Hi bob,

To try to help your workload, here are the use cases which I think need to be addressed.

All three use cases apply only to the case where MC18 is working with a renderer which supports SetNextAvTransportUri (I think it already works perfectly on renderers which do NOT support SetNextAvTransportUri).

Case #1 - (User inserts a track to play next)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A is currently playing.
User Action:  User inserts track C to play next.
MC Response:  MC18 shall select track C via SetNextAvTransportUri.

Case #2 - (User presses Skip Next)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A is currently playing.
User Action:  User presses Skip Next button.
MC Response:  MC18 shall send the Next command. No other direct action is needed, however the renderer will change tracks, and that change will itself trigger MC to send its next SetNextAvTransportUri command as usual.

Case #3 - (User presses Skip Previous)

Prior State:  MC18 has selected track A via SetAvTransportUri, sent the Play command, and selected track B via SetNextAvTransportUri. Track A has played through, and playing has advanced to track B. MC18 has then selected track C via SetNextAvTransportUri.
User Action:  User presses Skip Previous button.
MC Response:  MC18 shall select track A via SetAvTransportUri, send the Play command, and select track B via SetNextAvTransportUri.

Good summary of the cases of maintaining next track consistency in playback.

There's also case #4:  Track A is playing, Track B is next and track C follows.  If user remove track B from playlist, track C should be played next.

For simplicity, #2 and #3 can be handled the same way with this sequence: SetAVTransportURI, Play, SetNextAVTransportURI.

[AndrewFG]

For simplicity, #2 and #3 can be handled the same way with this sequence: SetAVTransportURI, Play, SetNextAVTransportURI.

Sorry but I don't agree with that. In case #2 MC should definitely send a Next command, because if the player supports gapless transitions it will already have cued (or pre-cached) the next track, so the transition can be gapless. Whereas if it does SetAVTransportURI, Play, SetNextAVTransportURI, the transition will be slower and will also have a gap.

PS case #2 is almost identical to what happens if you do a Seek to (almost) the end of the current track; you should let the player handle the track transition naturally, and not force things...

[bubbleguuum]

Sorry but I don't agree with that. In case #2 MC should definitely send a Next command, because if the player supports gapless transitions it will already have cued (or pre-cached) the next track, so the transition can be gapless. Whereas if it does SetAVTransportURI, Play, SetNextAVTransportURI, the transition will be slower and will also have a gap.

In my view, gapless is only meaningful in the context of playing gapless 2 related seamless tracks part of a gapless album.
Nobody is going to complain for a small gap when manually hitting Next or Prev.
As for prefeteching, MC and many other players prefetch about 10s before the end of the current track.

[AndrewFG]

Nobody is going to complain for a small gap when manually hitting Next or Prev.

Nobody except me ;-)

IMHO wherever it is possible to improve responsiveness, it is the duty of the software writer to do so...

[bob]

Hey people, we've discovered the source of the multiple scrobbling and pre-scrobbling and what it comes down to is SetNext.
It works like this, when the renderer requests a track from our DLNA server, we scrobble it.
When the controller (us or some other controller) sends the next track to the renderer with setNext sometimes the renderer requests the track immediately (while the other track is still playing). I assume this is because the renderer is looking at tag info (looks like this is what the Bravia does) or perhaps for buffering.

Our server has no way of knowing that the renderer is being controlled with setNext support or that it's requesting the next track when the first is still being served.

This results in early scrobbles of the next track to play and double scrobbles of the track playing if the server reopens the first file after requesting part of the second with a range request (very common).

We kicked around some ideas to try and alleviate this some and the one we came up with was to keep track of the last two file requests by a device and only scrobble if the track isn't one of the two already requested. Of course, if you play a single in a loop or a two track loop it will miss some scrobbles if the track length is shorter than the scrobble timeout.

What do you all think of this approach?

[vagskal]

I am not sure I understand, but I am confident that Andrew will, so listen to him.

If the proposed solution means that the only time when scrobbling is wrong, premature or late is when the same track is played several times in a row and when two tracks are looped several times, that sounds acceptable to me. Another, or a supplementary, solution would be to introduce an option to disable scrobbling when playing to a DLNA device (so the user can chose to enable scrobbling on that device instead, if applicable).

Thanks for looking into the scrobbling issue (and the add next issue, I hope)!

[AndrewFG]

Our server has no way of knowing that the renderer is being controlled with setNext support or that it's requesting the next track when the first is still being served.

This results in early scrobbles of the next track to play and double scrobbles of the track playing if the server reopens the first file after requesting part of the second with a range request (very common).

Hmm. Cool...

I have seen players that before they do the main GET for playing a track, will do a preliminary GET, presumably to read the HTTP Content-Type and Content-Length headers, and or to read RIFF headers and meta data preambles. But for this preliminary GET the player prematurely kills the socket connection before the full audio data has been sent. I have also even seen players that do two preliminary GET's; the first GET fetches the start of the track and detects if the server supports the HTTP Accept-Ranges header, and if so, the player does a second preliminary GET with a Range: bytes=-50000 (say) to fetch last 50k bytes (say) at the end of the track, presumably to acquire any meta data.

Note: I have seen this behaviour on players that do not support SetNextAVTransportUri (so please don't blame that poor function again for something that is not its fault).

In the two above cases, I suppose MC is scrobbling the track two or three times (once or twice for the preliminary GET(s) and once for the main track download)? Furthermore, obviously every time the user does a Seek within a track, (at least a Seek to a position that has not already been downloaded into local cache), the player will kill the current GET connection, and start a new GET with the respective Range: bytes=1234- header. And I suppose such additional GETs would also add to MC's scrobble count?

{ By the way, Whitebear does one preliminary GET to parse Content-Type, Content-Length, Accept-Range headers and the RIFF header (if any). And then does one GET to fetch the track. Plus one GET for each Seek to a track position not already downloaded. }

I noticed the word "part" in your message above. So perhaps one approach would be to only scrobble a track when there has been a GET that succeeded in downloading the full Content-Length of the track without being killed prematurely? But note that if a user was to play (say) the first and the last one minutes of a three minute track, then such a track would not be scrobbled. So perhaps you need to set an algorithm that only scrobbles a track when (say) in total more than half of its Content-Length has been downloaded by one or more GETs?

This sounds like a nightmare...

[bubbleguuum]

Scrobbling tracks at the Media Server level is kind of doomed as it has not sufficient info to consider a track played, and can only do guess work which will be wrong in some cases.

In foo_upnp a track is only scrobbled if the Media Server has served all bytes for a file.

And even that is not sufficient with the following scenarios:

1. stream request is from a user downloading a file, not playing it (server has no way to know)
2. stream request is from a renderer doing full file buffering like WMP

1. can be maybe workarounded by taking into account the duration for serving the full file and not scrobbling if duration is too low.
2. can be workarounded by excluding renderers known to do full file buffering from scrobbling at all

[AndrewFG]

And even that is not sufficient with the following scenarios:

1. stream request is from a user downloading a file, not playing it (server has no way to know)
2. stream request is from a renderer doing full file buffering like WMP

Apropos "server has no way to know" -- You could perhaps check with your CP's GetPositionInfo.CurrentTrackUri to see if the Url was being played. Of course it would not necessarily prove that the whole track had been played. Unless you would monitor GetPositionInfo.CurrentTrackUri over the whole track duration...

[vagskal]

If there is no way to scrobble properly from MC in this case, it seems reasonable and fair to offer the user a way to opt out (i.e. an option to not scrobble tracks played to DLNA devices). Such an option would also provide added benefit to certain users (those wanting to have a DLNA device always scrobble both tracks pushed from MC and tracks played locally on the device, and avoid duplicate scrobbles when MC pushes the track).

[bob]

If there is no way to scrobble properly from MC in this case, it seems reasonable and fair to offer the user a way to opt out (i.e. an option to not scrobble tracks played to DLNA devices). Such an option would also provide added benefit to certain users (those wanting to have a DLNA device always scrobble both tracks pushed from MC and tracks played locally on the device, and avoid duplicate scrobbles when MC pushes the track).

Probably makes sense to add a disable switch as a server specific option.

The reason the multiple GET's don't mess it up now is that we have a timeout for multiple GET's of the same file. Still though, it's not idea for all of the reasons you guys outlined above.

SetNext messes up the timeout logic.

I suppose there are some renderers that scrobble? I don't recall seeing any of the hardware ones do it.