Skip Forward/Back

[dwyatt 2]

Just got a Roku3 to temporarily replace my recently dead HTPC (was going on 8 years old and the motherboard is dead). Now that I have the Roku3 I may just stick with this - it seems to be great so far. I only have one question - is it possible to setup the fastforward/rewind buttons to act as skip forward/back? I have no need for ff/rw and prefer to skip by 10 or 15 seconds.

 

Thanks in advance!

[Luke 39631]

the video player manages the buttons so, no, however your experience doing this will vary depending on whether or not transcoding is taking place. if there is no transcoding, then you'll get the graphical roku ff/rw presentation and it allows you to jump forward and back by very small amounts like that.

[dwyatt 2]

Thanks Luke. Looks like you're right - once I'm on ff/rw mode (or paused) I can use the left/right directional buttons to skip by 10 seconds in each direction. I just wish there was a better time display (it only displays minutes, no seconds) so I could see better how far I am jumping around. And I also have to hit play after moving around to get it playing again. A bit of a PITA. Makes me long for my HTPC with MBT on it ...

[dnicks 34]

FYI, I don't think you need to be in ff/rwd do skip ahead/back.  just press left or right arrow while the video is playing.

[mbguy 40]

Thanks Luke. Looks like you're right - once I'm on ff/rw mode (or paused) I can use the left/right directional buttons to skip by 10 seconds in each direction. I just wish there was a better time display (it only displays minutes, no seconds) so I could see better how far I am jumping around. And I also have to hit play after moving around to get it playing again. A bit of a PITA. 

 

 

Same pain experienced here.

 

1) Time display in minute increments instead of seconds. Too imprecise.

2) Video has to be paused or before skipping ahead/back would work. 

[Luke 39631]

What Roku app did you install?

[mbguy 40]

What Roku app did you install?

 

I have the Beta v3.

 

I did more testing: the skip back button works properly now. It jumps 10 seconds backwards without pausing playback. But skipping ahead 10 seconds stops the playback. I'd have to press play again to continue playback. 

 

It doesn't seem like a big deal at first, but when you are skipping ahead a lot to find something, it gets tiresome fast. 

 

I much prefer Emby for Kodi's implementation, it skips ahead without pausing playback. I don't know if this is Roku's hardware limitation though. 

 

PS. I also have the old Roku 3, I'm not sure if Roku 4 has resolved this issue or not. 

Edited March 16, 2017 by mbguy

[ebr 15576]

I have the Beta v3.

 

I did more testing: the skip back button works properly now. It jumps 10 seconds backwards without pausing playback. But skipping ahead 10 seconds stops the playback. I'd have to press play again to continue playback. 

 

It doesn't seem like a big deal at first, but when you are skipping ahead a lot to find something, it gets tiresome fast. 

 

I much prefer Emby for Kodi's implementation, it skips ahead without pausing playback. I don't know if this is Roku's hardware limitation though. 

 

PS. I also have the old Roku 3, I'm not sure if Roku 4 has resolved this issue or not. 

 

This is the standard Roku behavior.  In fact, our app isn't controlling this at all. It is just the Roku video player and that's how it works - although, they have changed it slightly in recent firmware updates so they may change it again.

 

IMO it would not be wise for us to modify this behavior in only our app as people who are used to using the standard Roku interface would probably be confused.

[mbguy 40]

IMO it would not be wise for us to modify this behavior in only our app as people who are used to using the standard Roku interface would probably be confused.

 

 

I agree. Could someone with Roku 4 confirm that this behaviour design also persists? If yes, I should stick with an Android Box for future upgrades. 

 

Though I really like Roku's simplicity sometimes, but this is the only fatal flaw, for me. 

[ebr 15576]

If you install the Roku thumbnail plugin and start utilizing those, you can get a pretty nifty interface for seeking through a video...

 

[dcook 287]

@@ebr I would like to use the Roku thumbnail app, since this app is developed by Emby and not a 3rd party will it respect the metadata location settings defined on the server and use that location for the Roky images?   And if not, can you update the thje plugin to add a setting field so we can input the location to store the Roku images?

 

My Media library is Read-Only access for Emby and I would want these Roku images on my fast SSD that I have setup for Cache and Metadata anyhow.

 

 

 

 

 

If you install the Roku thumbnail plugin and start utilizing those, you can get a pretty nifty interface for seeking through a video...

 

[ebr 15576]

Currently the plug-in stores them with the content.  That is really the best place for them especially since they are so expensive to generate.  They aren't very large (in the scheme of video things).

 

I cannot promise when/if the plug-in will be updated to allow a different storage location.

[dcook 287]

With the content is fine if that is what you have selected in your Emby server settings, but if someone chooses to specify a specific location for metadata in their Emby server settings, shouldn't the plugin not recognize that and store there?

 

I don't understand why you are treating this different then chapter images, it is exactly the same thing, just Roku specific

 

How much work can it be to make the plugin use the already pre-defined metadata location?

 

 

 

Currently the plug-in stores them with the content.  That is really the best place for them especially since they are so expensive to generate.  They aren't very large (in the scheme of video things).

 

I cannot promise when/if the plug-in will be updated to allow a different storage location.

[speechles 2001]

With the content is fine if that is what you have selected in your Emby server settings, but if someone chooses to specify a specific location for metadata in their Emby server settings, shouldn't the plugin not recognize that and store there?

 

I don't understand why you are treating this different then chapter images, it is exactly the same thing, just Roku specific

 

How much work can it be to make the plugin use the already pre-defined metadata location?

Because the plugin uses the item as the parent. This means the BIF really doesnt have its own ID. Think of them like theme videos/music and local trailers. Local *-trailer dont have their own ID either. They have to reside in the same place as the item for emby to detect them.

 

Sent from my Nexus 7 using Tapatalk

Edited March 20, 2017 by speechles

[dcook 287]

Again:

I don't understand why they are treating these images different then chapter images, it is exactly the same thing, just Roku specific

 

Have a system / design / methodology / process and stick with it, doing things in different ways all the time just causes problems.

 

Does not make sense to have a Roku app to make the images but then not store the data the same way as all the other data is stored.

 

 

 

 

 

 

Because the plugin uses the item as the parent. This means the BIF really doesnt have its own ID. Think of them like theme videos/music and local trailers. Local *-trailer dont have their own ID either. They have to reside in the same place as the item for emby to detect them.

Sent from my Nexus 7 using Tapatalk

[speechles 2001]

Each BIF is approx 6-15MB in FHD. It isnt technically metadata, it is an binary index file for the media. So made sense at that time to adjust accordingly. Put it with media. If you want this behavior changed (or following that server option) would it just affect roku BIF?... or the other parts that still want things saved with media, such as theme videos/music by radeon, and the servers built-in thememusic/trailer/specials endpoints too? Its a deep rabbit hole of change. Take the red or blue pill?

Edited March 20, 2017 by speechles

[dcook 287]

There are user defined options for cache, metadata, trans-coding temp folder, I don't see any difference.

Put it with the other metadata or at the very list have a configurable setting in the plugin so for example I could make a new folder called d:\rokubifs and store them all there.

 

It does not make sense to store this data with media.  

 

What if I decided after 1 year to switch to AppleTV then I have all the BIF data polluting my media library

 

 

 

 

 

Each BIF is approx 6-15MB in FHD. It isnt technically metadata, it is an binary index file for the media. So made sense at that time to adjust accordingly. Put it with media. If you want this behavior changed (or following that server option) would it just affect roku BIF?... or the other parts that still want things saved with media, such as theme videos/music by radeon, and the servers built-in thememusic/trailer/specials endpoints too? Its a deep rabbit hole of change. Take the red or blue pill?

[speechles 2001]

There are user defined options for cache, metadata, trans-coding temp folder, I don't see any difference.

Put it with the other metadata or at the very list have a configurable setting in the plugin so for example I could make a new folder called d:/rokubifs and store them all there.

 

It does not make sense to store this data with media.

 

What if I decided after 1 year to switch to AppleTV then I have all the BIF data polluting my media library

Hey, I am with you. More options to get closer to making 100% of users happy is a good thing. I tried to please 100% with blue neon hence all the options. The new app will hopefully try to get there too (or at least open source the code so others can take it there.. wink wink)

 

Now as for the plugin thing, this is the constructive side of it, explain why. Your mention that very shortly the roku may be abandoned as a platform on your server is compelling. This does indeed satisfy my argument that these are the same as trailers, etc. Clearly in this case, they are not. It should allow saving in with media or a custom path as an option.

 

The plugin is open sourced, shows on github, can be forked and pull requests made. Not sure how the java api is built or id try my hand at this. Anyone else have the time and inclination?

Edited March 20, 2017 by speechles

[Jdiesel 1281]

There are user defined options for cache, metadata, trans-coding temp folder, I don't see any difference.

Put it with the other metadata or at the very list have a configurable setting in the plugin so for example I could make a new folder called d:\rokubifs and store them all there.

 

It does not make sense to store this data with media.  

 

What if I decided after 1 year to switch to AppleTV then I have all the BIF data polluting my media library

 

On Windows:

 

Open explorer window, browser to root folder of your media, type "*.bif" in search bar, ctrl-a, delete. Done

 

On Linux:

 

Open terminal window, type "cd /your/media/directory", type "find . -name "*.bif" -type f -delete". Done

[ebr 15576]

Again:

I don't understand why they are treating these images different then chapter images, it is exactly the same thing, just Roku specific

 

Chapter images are never stored with the media but has been requested that they be able to for the same reason we store the bif file there - it is basically a visual index of the media itself and it is very expensive to re-generate.  Storing it with the media minimizes the situations where they need to be re-generated.  If you don't store it with the media and subsequently move your media somewhere else, or just setup a new server accessing it, then these very expensive operations have to run again to create data that already exists.

 

 

It does not make sense to store this data with media.  

 

What if I decided after 1 year to switch to AppleTV then I have all the BIF data polluting my media library

 

See above for why it really does make sense.  We may end up letting you store these in another location but our default I would suspect would stay as it is for all the reasons I outlined.

 

If you move to another device, the bif files will have absolutely no impact on the function of that device or app.

 

Please create a feature request for this and then it will be on the radar.  Thanks.

[dcook 287]

@@ebr if the data is stored in a custom location (for example F:\RokuBIFS) , and that location still exists then you would not need to recreate the data if you setup a new server or move media.

 

Of course if you store the data it in the C:\Users\Username\AppData and your reinstall the OS you would lose the data and have to regenerate it all.

Which is why its a very bad idea to store important information in AppData to begin with.

 

 

 

 

 

 

 

Chapter images are never stored with the media but has been requested that they be able to for the same reason we store the bif file there - it is basically a visual index of the media itself and it is very expensive to re-generate.  Storing it with the media minimizes the situations where they need to be re-generated.  If you don't store it with the media and subsequently move your media somewhere else, or just setup a new server accessing it, then these very expensive operations have to run again to create data that already exists.

 

 

 

See above for why it really does make sense.  We may end up letting you store these in another location but our default I would suspect would stay as it is for all the reasons I outlined.

 

If you move to another device, the bif files will have absolutely no impact on the function of that device or app.

 

Please create a feature request for this and then it will be on the radar.  Thanks.

[ebr 15576]

@@ebr if the data is stored in a custom location (for example F:\RokuBIFS) , and that location still exists then you would not need to recreate the data if you setup a new server or move media.

 

Unfortunately, you would because the only way to store a file that is supposed to be related to a specific file in some other location is to create an ID for it that traces back to that specific location.  If the location changes, there is no way to relate the two files.

[dcook 287]

Well that sounds like a fundamental design flaw to me then.

Why have ID's for some objects and not others?

 

 

Unfortunately, you would because the only way to store a file that is supposed to be related to a specific file in some other location is to create an ID for it that traces back to that specific location.  If the location changes, there is no way to relate the two files.

[Luke 39631]

All objects have ID's.

[dcook 287]

OK, so then there is no reason why the seek images for the Roku plugin can't be stored with the other metadata?

 

 

 

All objects have ID's.