Jump to content


Photo

Skip Forward/Back

Roku3 Skip

  • Please log in to reply
37 replies to this topic

#21 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 10:38 AM

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



#22 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50059 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 10:42 AM

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



#23 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 10:44 AM

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.



#24 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 149391 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 12:25 PM

All objects have ID's.



#25 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 12:29 PM

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.



#26 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 149391 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 12:31 PM

Doesn't the plugin have a setting? have you explored that?



#27 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50059 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 12:41 PM

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

 

The other metadata has the same limitation.  If you don't store it alongside your media, then moving the media will cause us to have to rebuild it.  That is one of the reasons I strongly recommend storing the metadata along with the media.



#28 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50059 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 12:42 PM

Doesn't the plugin have a setting? have you explored that?

 

He he... it does.

 

58d15873db2ce_rokubifoptions.png



#29 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 12:42 PM

No option that I can find

 

 

Doesn't the plugin have a setting? have you explored that?



#30 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 12:45 PM

Here is the only settings I see:

 

 

58d1588227237_Capture3333.jpg

 

 

No where can you define where to store the images



#31 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50059 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 12:46 PM

See my post above :).

 

Sorry for all the confusion.  I wasn't aware that the setting already existed and, when you asked for it, I assumed it didn't.

 

Of course, it is still potentially a valid request for the individual plug-in setting to be replaced with the standard setting on the server...

 

But a good argument for not doing that would be just how expensive it is to generate these.  So maybe you want all the other metadata not stored there but do want these.



#32 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 12:55 PM

@ebr that is not the setting, all that does is tell the plugin to save with the media, what I am looking for is a setting that looks like this:

 

58d15ae8980e1_Capture4444.jpg

 

But specific for the Roku Plugin since the Plugin is not honoring the settings that are already defined for Metadata in the server.

 

 

 

 

 

 

See my post above :).

 

Sorry for all the confusion.  I wasn't aware that the setting already existed and, when you asked for it, I assumed it didn't.

 

Of course, it is still potentially a valid request for the individual plug-in setting to be replaced with the standard setting on the server...

 

But a good argument for not doing that would be just how expensive it is to generate these.  So maybe you want all the other metadata not stored there but do want these.



#33 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 50059 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 01:10 PM

With that option unchecked, where is the .bif file saved?



#34 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 01:27 PM

I don't know, it does not say anywhere where the files are saved.

Can you not tell me?  Didn't you guys create this plugin?

 

 

 

With that option unchecked, where is the .bif file saved?



#35 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 149391 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 01:28 PM

In the server's internal metadata folder.



#36 dcook OFFLINE  

dcook

    Advanced Member

  • Members
  • 866 posts
  • Local time: 03:02 AM

Posted 21 March 2017 - 02:00 PM

@Luke  so you are confirming that if I have Metadata folder set on my server:

 

58d16a2070b3e_Capture5555.jpg

 

This Plugin is supposed to store the images there?

 

Because that is not the behavior I am seeing.

 

 

 

 

In the server's internal metadata folder.



#37 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 149391 posts
  • Local time: 02:02 AM

Posted 21 March 2017 - 02:06 PM

Correct, yes.



#38 mbguy OFFLINE  

mbguy

    Advanced Member

  • Members
  • 185 posts
  • Local time: 11:02 PM

Posted 21 April 2017 - 03:31 PM

This is the standard Roku behavior (skipping forward and pausing video, requires pressing play again to continue video).  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.

This Roku behavior continues to bug me. Sadly Emby is crippled because of it. What is the rationale for Roku to design this type of seeking behavior, ie. pausing video after pressing skip forward.

 

No media players I've owned/used before has this kind of skip forward design, eg. blu ray player, AppleTV, windows media player, Kodi etc so I wonder if there's a way to circumvent this stubborn and irregular skip forward design of Roku. I'm surprised they are able to get away with this for this long.


Edited by mbguy, 21 April 2017 - 03:31 PM.






Also tagged with one or more of these keywords: Roku3, Skip

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users