I've been playing a bit with the SetNextAVTransportURI function and am getting some success with WhiteBear however, I'd like to use AVTransport:GetMediaInfo to determine if the NextURI is empty however it seems broken in WhiteBear. Right now, it increments NrTracks properly from tracks 0 to tracks 1 to tracks 2 when going from stopped to SetAVTransportURI to SetNextAVTransportURI however when the track set by SetAVTransportURI stops playing it doesn't reflect the change (it stays at what it was before the track stopped playing). Also when the second track is finished, AVTransport:GetMediaInfo still stays at NrTracks = 2 and the original track URI's are still in CurrentURI and NextURI.
Also, a side issue, the CurrentURIMetadata and NextURIMetadata are both blank.
I think if you can clear up the AVTransport:GetMediaInfo issues we can get SetNextAVTransportURI working with WhiteBear.
Coool...
In the pre-release that you have, I already did some work on AVTransport:GetPositionInfo(), so for example AVTransportURI and AVTransportURIMetaData are properly updated. Also I tweaked the eventing so that LastChange:CurrentTrackURI and LastChange:CurrentTrackMetaData are updated. But you are quite right in observing that I did not touch AVTransport:GetMediaInfo yet :-( so I will get onto this right away, and post you a new build when it is ready. But it may be in about one week's time though...
Edit: your mention of NrTracks (and by analogy CurrentTrackNo) started me thinking about what the correct algorithms should really be here. As I read the specifications there should never be more than two entries in the playlist -- namely "current" and "next". And pointedly the specification makes no mention of "prior". So I think the behaviour should be as follows:
1) SetAVTransportURI: it shall clear any existing entries in the playlist; it shall add the respective URI as entry #1 in the new playlist; and if the player was already playing, it shall start to play this track.
2) SetNextAVTransportURI: if there is already an entry #1 in the playlist it shall add the respective URI as entry #2 in the playlist; if there was already an entry #2 (or higher) in the playlist then all such extra entries shall be deleted; if there is NOT an entry #1 in the playlist it shall behave the same as SetAVTransportURI above...
3) If the player is playing entry #1 and reaches the end of the track: if there is an entry #2 in the playlist, the player shall start playing this track; entry #1 shall be deleted from the front of the playlist; and consequently the now playing track becomes entry #1
If the behaviour is as mentioned above, then GetMediaInfo.NrTracks can only ever return the values 0, 1 or 2. And GetMediaInfo.CurrentTrackNo can only ever return the value 1.
=> Is this how you see it too?
Edit 2: but then again, it occurs to me that in the case of Squeeze players there may be other actors (UIs) who are in parallel pushing tracks to the playlist. So probably after all, it is better to consider the UPnP/DLNA "current" plus "next" playlist as a two track window that may slide over a larger playlist that had possibly been set by another actor. My head is starting to spin...