Jump to content

Skip Forward/Back


dwyatt

Recommended Posts

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

  • 1 year later...
mbguy

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. 

Link to comment
Share on other sites

mbguy

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 by mbguy
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

mbguy

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. 

Link to comment
Share on other sites

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

 

58585395ad1a2_bif.jpg

  • Like 1
Link to comment
Share on other sites

dcook

@@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...

 

58585395ad1a2_bif.jpg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dcook

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.

Link to comment
Share on other sites

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 by speechles
Link to comment
Share on other sites

dcook

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

Link to comment
Share on other sites

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 by speechles
Link to comment
Share on other sites

dcook

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? :)

Link to comment
Share on other sites

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 by speechles
Link to comment
Share on other sites

Jdiesel

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

dcook

@@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.

Link to comment
Share on other sites

@@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.

Link to comment
Share on other sites

dcook

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.

Link to comment
Share on other sites

dcook

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...