Print

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

[desa]

I encountered an odd behavior of the renderer when dealing with the SetNextAVTransportURI method.

When the renderer SetNextAVTransportURI method is invoked, it appends the specified URI to a list of URIs to play. This works fine as long as the list contains only one element, but further invocations of the method add more and more URIs, creating a renderer local playlist that doesn't match the 2 slot (current and next URI) structure that the SetCurrent/SetNext methods suggest.

The correct behavior of the SetNextAVTransportURI method should be setting the "next" slot regardless of whether it has been already set or not.

Issuing repeated "Add (as next to play)" from a MC controller to a MC renderer easily demonstrates how the current behavior can cause inconsistent results.

Ciao
Marcello

[AndrewFG]

When the renderer SetNextAVTransportURI method is invoked, it appends the specified URI to a list of URIs to play. This works fine as long as the list contains only one element, but further invocations of the method add more and more URIs, creating a renderer local playlist that doesn't match the 2 slot (current and next URI) structure that the SetCurrent/SetNext methods suggest.

What renderer are you referring to?

[desa]

What renderer are you referring to?

To MC DLNA renderer component.

[AndrewFG]

To MC DLNA renderer component.

Then there is probably indeed a bug in MC. (What version are you on?)

The UPnP specification implies that renderers have a maximum local playlist size of two tracks - the one playing now, and the next one. Now obviously MC is able to handle larger playlists than two, but it must map its own playlist properly around the two entries. As follows:

Starting point (for example)

Track_A  (already played)
Track_B  (already played)
Track_C  (already played)
Track_D  (now playing)

After calling SetNextAVTransportURI( Track_E ) ...

Track_A
Track_B
Track_C
Track_D  (now playing)
Track_E  (added next track to play)

After calling Seek( Previous ) TWO TIMES ...

Track_A
Track_B  (now playing)
Track_C
Track_D
Track_E 

After calling Seek( Next ) ...

Track_A
Track_B 
Track_C  (now playing)
Track_D
Track_E 

After calling SetNextAVTransportURI( Track_F ) ...

Track_A
Track_B 
Track_C  (now playing)
Track_F  (added next track to play) -- NOTE: Track_D and Track_E deleted from tail !!

[desa]

Then there is probably indeed a bug in MC. (What version are you on?)

The UPnP specification implies that renderers have a maximum local playlist size of two tracks - the one playing now, and the next one. Now obviously MC is able to handle larger playlists than two, but it must map its own playlist properly around the two entries. As follows:
...
After calling Seek( Next ) ...

Track_A
Track_B 
Track_C  (now playing)
Track_D
Track_E 

After calling SetNextAVTransportURI( Track_F ) ...

Track_A
Track_B 
Track_C  (now playing)
Track_F  (added next track to play) -- NOTE: Track_D and Track_E deleted from tail !!

Yes, this is the expected behavior, but unfortunately after calling SetNextAVTransportURI( Track_F ) the renderer playlist content is:
Track_A
Track_B 
Track_C  (now playing)
Track_D
Track_E 
Track_F

If we consider both the MC controller and renderer playlists, the result is even more curious.

We start with both playlists empty and we assume that all commands are issued on the controller.

We add TRACK_A with "Add (as next to play)". Playlists content:
Controller: TRACK_A (playing)
Renderer: TRACK_A (playing)
Fine. This is what we expected.

Now we add TRACK_B using "Add (as next to play)" again.
Controller: TRACK_A (playing), TRACK_B
Renderer: TRACK_A (playing), TRACK_B
Still fine.

We add TRACK_C using "Add (as next to play)" one more time:
Controller: TRACK_A (playing), TRACK_C, TRACK_B
Renderer: TRACK_A (playing), TRACK_B, TRACK_C
The 2 lists now contain the same elements, but in a different order. And the renderer one is wrong.

When TRACK_A is over and renderer tries to play the next track, things become funny.

The controller shows TRACK_C playing, but the track length is from TRACK_B. At the same time, the renderer shows it is playing TRACK_B and this is what it is really doing, indeed. So you see TRACK_C playing, but you hear TRACK_B.

Just in case I tried the same operations towards a gmrender-resurrect on a Linux box, still using MC as both server and controller, and everything works as expected.

I tested using MC 19.0.54 windows (in both controller and renderer mode) and MC 10.0.67 for OS X (renderer only).

I think I can state this is definitely a MC renderer bug.

Marcello

[AndrewFG]

^

I agree. Definitely a bug.