Forum Discussion

tifroz's avatar
tifroz
Streaming Star
9 years ago

roVideoPlayer.SetContentList() bug in firmware 7.5.0?

My app lets users update their playlist during playback, changing the order etc...with every change in the playlist, the app executes something like [size=85]roVideoPlayer.SetContentList([thePlayListAsDefinedByTheUser])[/size]

Since firmware 7.5.0 this no longer works correctly: if playback is already in progress, playback will be interrupted and the user is now just staring at a blank screen.

To illustrate, in pseudo code:

roVideoPlayer.SetContentList([videoMedatadata1]) ' ok this works, video1 now playing
'....a little later, after the user takes action
roVideoPlayer.SetContentList([videoMedatadata1, videoMedatadata2 ]) ' Expected: video1 should keep playing (and video2 should start playing when video1 ends). Observed: video1 stops, the screen turns black




I only have a 7.5.0 device to experiment with at the moment, but I am pretty sure that the very same logic was working as expected with 7.2.0 - is anyone else experiencing the same? Any workaround?

(I sent an email with the same info to developer at roku dat com - but I was told on a different thread that they aren't terribly responsive so trying my luck here)

3 Replies

  • I wouldn't call this a bug - rather a "deficient design".

    Out of curiosity, what happens if you mutate the list you set at first, w/o 2nd SetContentList()? Sounds the behavior will be undefined - i.e. either Roku will crash, or modifying the list will work, or changes will be ignored - or also possible, a random mix of all 🙂

    I would advised you keep the lists to yourself and only set 1 clip to play at any one time and when done replace with another - except there is the pre-buffering advantage for the next clip. .AddContent() no good with you?
  • tifroz's avatar
    tifroz
    Streaming Star
    Thanks for the response!

    I guess one person's deficient API design is another's deeply flawed design 🙂 AddContent() only does half the job, because users can also remove a single item from the list. To support this use case and keep the benefit of pre-buffered video I have to maintain a mirror copy of the player's content playlist because the roVideoPlayer does not expose its contentItem list, maintain a mirror copy of the user's playlist & keep the two mirrors coordinated somehow (the as the user performs actions like remove an item, change order, the 2 playlists will get out of sync). Ugh.
  • "tifroz" wrote:
    ... keep the two mirrors coordinated somehow (the as the user performs actions like remove an item, change order, the 2 playlists will get out of sync). Ugh.

    These seem to me like a good places to use .SetContentList(). I.e. maybe not on append but delete/re-order being "fair game" to interrupt current play. That shan't be too vexing on the user, i think.

    What can i say, seems your use-case - simultaneously play and manipulate list - was never considered.