Roku Developer Program

[rsromeo]

Hi - trying to learn something new. What exactly do I need to do to implement resume playing on my video? I know roVideoScreen has SetPositionNotificationPeriod and isPlaybackPosition() but not sure how to use them to resume playback. I'm guessing I need to have a button pressed event that gets the position and then somehow store the position in the registry? Can someone help clue me in on what I need to do? A code snippet would be very helpful. Thanks.

[TheEndless]

"rsromeo" wrote:
Hi - trying to learn something new. What exactly do I need to do to implement resume playing on my video? I know roVideoScreen has SetPositionNotificationPeriod and isPlaybackPosition() but not sure how to use them to resume playback. I'm guessing I need to have a button pressed event that gets the position and then somehow store the position in the registry? Can someone help clue me in on what I need to do? A code snippet would be very helpful. Thanks.

The SetPositionNotificationPeriod() method specifies how often the isPlaybackPosition() event is raised. The GetIndex() method of the isPlaybackPosition() event gives you the current position in the video (in seconds). You can then use that value in the PlayStart attribute of the content metadata to indicate where playback should start when resuming later.

[rsromeo]

thanks TheEndless. I understand everything you said except confused on where/how I store the value from isPlaybackPosition() so I can refer to it later to use in the PlayStart attribute? In other words, I want to start a movie, pause it, leave the channel, come back later and resume playing. I'm guessing its stored with roRegistry?

[TheEndless]

"rsromeo" wrote:
thanks TheEndless. I understand everything you said except confused on where/how I store the value from isPlaybackPosition() so I can refer to it later to use in the PlayStart attribute? In other words, I want to start a movie, pause it, leave the channel, come back later and resume playing. I'm guessing its stored with roRegistry?

It depends. Services like Netflix and Hulu store it on their servers, so it can be used across devices. If that's not an option, or you don't want that functionality, then you can store it in the registry. In the channel where I implemented it, each video had a short unique ID, so I just stored a separate key in the registry named after the video ID with the position stored as a string. That made it easy to retrieve when the video was re-launched without having to parse a string with multiple values in it. I don't know if there are any negative implications to that approach, though...

[kbenson]

"TheEndless" wrote:
In the channel where I implemented it, each video had a short unique ID, so I just stored a separate key in the registry named after the video ID with the position stored as a string. That made it easy to retrieve when the video was re-launched without having to parse a string with multiple values in it. I don't know if there are any negative implications to that approach, though...

Depending on how big your unique id's are, and how big your stored number is (in ASCII representation), it could conceivably fill up the 16KB allotted per channel. Probably not very likely unless viewing LOTS of videos. You'll probably be able to store more than 1000 entries before it fills up, but if you aren't removing entries for fully watched movies, or implementing some way to remove the oldest as needed, it might cause problems down the line. I don't know what the error case is the for registry, but conceivably it could crash the program by returning a value you weren't expecting.

Again, not very likely (at least for a while), but worth thinking about.

[rsromeo]

I got it working. I went with storing in the registry. When playback finishes, I delete the key. Seems to work well. Thanks for your help! 🙂

[TheEndless]

"rsromeo" wrote:
I got it working. I went with storing in the registry. When playback finishes, I delete the key. Seems to work well. Thanks for your help! 🙂

Great! No problem...

As a tip, you may want to wait to store it until they're a certain percentage into the file, and delete if when they're a certain percentage from the end. I'm not sure what your content is, but a lot of folks will stop watching a video during the credits. No reason to resume at that point. 😉

[kbenson]

"TheEndless" wrote:

As a tip, you may want to wait to store it until they're a certain percentage into the file, and delete if when they're a certain percentage from the end. I'm not sure what your content is, but a lot of folks will stop watching a video during the credits. No reason to resume at that point. 😉

I believe that's how Netflix does it, at least with regard to the end of playback (although it requires you be quite close to the end). Tivo did (does?) this as well.

[dynamitemedia]

i stop at the credits all the time in netflix and that is the last position shown.

so when i go in to watch family guy it always remembers that i stopped at the credits and it shows that.

so what would you do to change that? check the content length and if ends so many seconds from the end make a new start position of "0" ?

thats interesting, at least if you have movies with ending credits, which i don't, lol

[kbenson]

"dynamitemedia" wrote:
i stop at the credits all the time in netflix and that is the last position shown.

so when i go in to watch family guy it always remembers that i stopped at the credits and it shows that.

It depends on how close to the end you are, I think. For Netflix, it's extremely close, I think.

For Tivo, it seemed to be a percentage. The longer the clip, the closer to the end you could stop and it would consider it watched.

so what would you do to change that? check the content length and if ends so many seconds from the end make a new start position of "0" ?

thats interesting, at least if you have movies with ending credits, which i don't, lol

I imagine a percentage based approach with a hard upper limit on what's considered the end would be ideal. 95% watched and never more than 5 minutes from the end would probably work well, I would think.