Jump to content

Show Intro Skip Option


Liquidfire88

Recommended Posts

datanet
1 minute ago, ebr said:

Why does the plug-in need any intro detection logic at all anymore? Can't it just let the core do the detection of those and it only deals with end credits?

I may be talking out of turn here, but I suspect this is because Luke has chosen to use a much smaller window for detection (to reduce resource consumption) and this smaller window is less inclusive than the current intro detection process that is in the plugin.  Naturally, i do think the Intro detection should be moved over to being handled only by the core, but with editable criteria (either hidden or unhidden) that would allow the detection process to run similarly to how the plugin currently runs.  This would allow for people who have the available resources to have better (or more complete) detection. 

  • Like 1
Link to comment
Share on other sites

8 minutes ago, datanet said:

but I suspect this is because Luke has chosen to use a much smaller window for detection

The current window is 10 minutes.  Realistically, what percentage of content - with consistent intros - has these outside of 10 minutes into the episode?  

Link to comment
Share on other sites

rbjtech
47 minutes ago, ebr said:

The current window is 10 minutes.  Realistically, what percentage of content - with consistent intros - has these outside of 10 minutes into the episode?  

On recent shows Eric - it's more than you may think.   I have the stats of all my TV shows if you want to see the actual data from the Plugin ?  I'm happy to share it.

In my initial test of the the Core Introskip with just a very small sample, it didn't pick up a show because of this reason - so yes, it is an issue that needs a solution.

 

Edited by rbjtech
  • Like 1
Link to comment
Share on other sites

datanet
2 minutes ago, ebr said:

The current window is 10 minutes. Realistically, what percentage of content - with consistent intros - has these outside of 10 minutes into the episode?  

@chef will need to chime in here, but I do know he went through quite a few iterations of adjusting the various timing parameters to get the most accurate results that covered pretty much all but the extreme cases.

Furthermore, if nothing else, this "experiment" uncovered that there is no one size fits all when it comes to Intro detection and credit detection.  The detection process should be more modular (possibly in the form of detection plugins) or detection profiles that even have the possibility of being assigned per TV Series.  If memory serves, It was determined that the existing default detection had difficulty handling some Anime series.  There could be detection profiles that are better suited for handling this type of content.  Future OCR detection could be added as a detection process and/or added to detection profiles.  Similar detection info could be provided with the possibility of a future crowdsourced database of the intro and credit metadata.  Going in to this design with a modular format for detection opens up numerous opportunities for improvement in the detection process.  Emby would become the model on how it should be done.

  • Like 1
Link to comment
Share on other sites

rbjtech
16 minutes ago, rbjtech said:

On recent shows Eric - it's more than you may think.   I have the stats of all my TV shows if you want to see the actual data from the Plugin ?  I'm happy to share it.

In my initial test of the the Core Introskip with just a very small sample, it didn't pick up a show because of this reason - so yes, it is a issue that needs a solution.

 

Just some I picked at random ... 

Halo - s1e1 - 17:55 > 18:56 

Halo s1e6 - 8:54 > 9:57

Halo s1e9 - 10:43 > 11:46

1883 - s1e6 - 8:34 > 9:39

Das Boot - s1e1 - 9:17 > 10:33

Alcatraz - s1e2 - 9:53 > 10:24

A quick pivot table from an export will give you the full stats - but 10 mins is imho too short.  The Plugin settled on using 15 mins for a 55 minute or greater episode  duration, dropping to to 10 for a 30-45 min episode - I forget the actual metrics, but it's not fixed.

 

Link to comment
Share on other sites

rbjtech
1 hour ago, ebr said:

Why does the plug-in need any intro detection logic at all anymore?  Can't it just let the core do the detection of those and it only deals with end credits?

Intro detection could potentially be turned off I agree - as we now have manual and auto-skip options in the Core - but the key thing currently 'missing' is the ability to validate/edit the said detected data.

In the Plugin, you can select the Show and Season and edit the data - any of the timings below can be edited and it then regenerates the exact frame thumbnail so you can validate the change before hitting save.

Lower level function such as the ability to turn on/off autoskip on a user basis, or even show the 'Skip Intro' button at user level are nice to haves imo.

btw - you can click the episode Thumb on the left and it will just play the Intro it has detected - it's pretty neat .. 🙂

image.thumb.png.d66a50d19a3ee94ec7a68f8fd241fae0.png

 

 

Edited by rbjtech
Link to comment
Share on other sites

Cheesegeezer
1 hour ago, ebr said:

Why does the plug-in need any intro detection logic at all anymore?  Can't it just let the core do the detection of those and it only deals with end credits?

It’s because we been around way longer than you. And detection has already been done in the plugin. And you need to test the core. So migration makes sense.

also the plugin is way more feature rich at the moment 

Edited by Cheesegeezer
  • Like 1
Link to comment
Share on other sites

datanet
52 minutes ago, Cheesegeezer said:

It’s because we been around way longer than you.

Probably not the best choice of words since Eric has been here as core developer since the beginning of Emby.  But the developers of the auto skip feature certainly have been working for a significant amount of time over the past couple years tweaking and refining the process of what makes up the auto skip plugin that it is today.  So from that perspective the "we", being the auto skip dev team, has been doing this longer than "you", the core devs, who have taken over implementing this feature in the core code.  I get the feeling the autoskip developers may possibly be a little frustrated that the most critical part of the equation - the parameters that make up the detection process - were kind of tossed aside for what the core team felt was "best" despite much effort, tweaking and testing that was done by the autoskip dev team to get the plugin to the level it is today.  I think that might be what Cheese was trying to say. 🙂

It's unfortunate that there wasn't more effort by the core team to provide a viable migration path for existing users of the plugin by either providing the ability to import the existing data and extending the schema of the database to accommodate the additional data that was acquired and saved with the current plugin.  If that had taken place, there would be less resistance by the users of this plugin to migrate over to the core implementation.  The way it is now, the two implementations store their data in different places and in different ways.  If the two teams could agree on a common storage method whereby no data is discarded from the plugin data, I'm sure the autoskip plugin developers would update their plugin to access the new database location (with all the existing data intact).

Can this not happen?  It seems this portion is essential to keep these two projects from remaining disjointed.

Edited by datanet
Link to comment
Share on other sites

rbjtech
50 minutes ago, datanet said:

Probably not the best choice of words since Eric has been here as core developer since the beginning of Emby.  But the developers of the auto skip feature certainly have been working for a significant amount of time over the past couple years tweaking and refining the process of what makes up the auto skip plugin that it is today.  So from that perspective the "we", being the auto skip dev team, has been doing this longer than "you", the core devs, who have taken over implementing this feature in the core code.  I get the feeling the autoskip developers may possibly be a little frustrated that the most critical part of the equation - the parameters that make up the detection process - were kind of tossed aside for what the core team felt was "best" despite much effort, tweaking and testing that was done by the autoskip dev team to get the plugin to the level it is today.  I think that might be what Cheese was trying to say. 🙂

It's unfortunate that there wasn't more effort by the core team to provide a viable migration path for existing users of the plugin by either providing the ability to import the existing data and extending the schema of the database to accommodate the additional data that was acquired and saved with the current plugin.  If that had taken place, there would be less resistance by the users of this plugin to migrate over to the core implementation.  The way it is now, the two implementations store their data in different places and in different ways.  If the two teams could agree on a common storage method whereby no data is discarded from the plugin data, I'm sure the autoskip plugin developers would update their plugin to access the new database location (with all the existing data intact).

Can this not happen?  It seems this portion is essential to keep these two projects from remaining disjointed.

We are already doing this - the Plugin now writes it's data to be compatible with the Core (as well as it's own db) and by simply refreshing the metadata, everything that was in the Plugin now works with the Core.  (latest wiki update)

The immediate issue of the Plugin not working with the Core release is resolved - what we are debating now is the 'next steps'. 

Medium/Long term - all detection should be in the Core, nobody is disputing that - but it's the 'short term' where the users of the Plugin (myself included) are reluctant to give up the functions they have grown accustomed to in the Plugin.   

My personal view is the Core need to provide editable markers ASAP but I believe they are already working on this.

Once this is out of Beta, then we can decouple the Intro detection - leaving just the credit detection and maybe the full/advanced edit facilities in the Plugin if we want to (it doesn't really make sense to have this split Intro/Credit imo).

Users that want just Intro, continue to use the Core as they do today, users that want credits can use the Plugin.   If the Core decide to implement the Credit detection as well (if there is demand for it), then great - the plugin may supply other 'advanced' options but ultimately at this stage - it will probably be no longer required - and that is not an issue as it has paved the way to getting this in the Core which is a win for everybody.

Edited by rbjtech
Link to comment
Share on other sites

datanet
9 minutes ago, rbjtech said:

We are already doing this - the Plugin now writes it's data to be compatible with the Core (as well as it's own db) and by simply refreshing the metadata, everything that was in the Plugin now works with the Core.  (latest wiki update)

I guess I wasn't entirely clear, and correct me if I'm wrong, but say I wanted to go "all in" and remove the plug-in and rely entirely on the core implementation.  That would require a complete intro re-detection of my whole TV library...correct?  If so, the manual edits I've done over time to fix the episodes that weren't detected properly or incorrectly would be discarded which was my point of resistance to embracing the core version.  But if you're saying all i need to do is to perform a metadata refresh on my TV library and now the core will see and use all my existing detection data...that's great.  So does that further mean if I decided to enable the schedule detection scan of the core version it wouldn't touch the existing "imported" data and operate as though it has already fully scanned my library?  Obviously I would have to disable the plugin scheduled tasks if I did that.  But as you mentioned, the plugin editor would not see any new detection data provided by the core detection process from that point forward though?

Really trying to wrap my head around what is and isn't at this point.

By the way, I'm no where ready to go all in on the core implementation at this point and these are only hypothetical questions to determine what is lost (beside the features) if you choose to migrate from the plugin to the core. 

Link to comment
Share on other sites

Cheesegeezer
1 hour ago, datanet said:

Probably not the best choice of words since Eric has been here as core developer since the beginning of Emby.

actually he’s been here since videobrowser and mediabrowser. If you even used those platforms on WMC and when i started developing themes.
 

 When i say we i mean the plugin development of IntroSkip.

 

Link to comment
Share on other sites

Cheesegeezer
8 minutes ago, datanet said:

I guess I wasn't entirely clear, and correct me if I'm wrong, but say I wanted to go "all in" and remove the plug-in and rely entirely on the core implementation.  That would require a complete intro re-detection of my whole TV library...correct?

yes and at the moment there is no way to transfer your hard work to the core.

8 minutes ago, datanet said:

If so, the manual edits I've done over time to fix the episodes that weren't detected properly or incorrectly would be discarded which was my point of resistance to embracing the core version.  But if you're saying all i need to do is to perform a metadata refresh on my TV library and now the core will see and use all my existing detection data...that's great

no the core scan creates new intro start and end points

8 minutes ago, datanet said:

So does that further mean if I decided to enable the schedule detection scan of the core version it wouldn't touch the existing "imported" data and operate as though it has already fully scanned my library?

so your plugin edit points are stored in our database not the core

8 minutes ago, datanet said:

 

Obviously I would have to disable the plugin scheduled tasks if I did that.  But as you mentioned, the plugin editor would not see any new detection data provided by the core detection process from that point forward though?

Really trying to wrap my head around what is and isn't at this point.

By the way, I'm no where ready to go all in on the core implementation at this point and these are only hypothetical questions to determine what is lost (beside the features) if you choose to migrate from the plugin to the core. 

Here in lies the transition. And why we need to have a method of integrating IntroSkip plugin edits to core emby.

Link to comment
Share on other sites

datanet
1 minute ago, Cheesegeezer said:

actually he’s been here since videobrowser and mediabrowser. If you even used those platforms on WMC and when i started developing themes.
 

 When i say we i mean the plugin development of IntroSkip.

 

Yep, been here since the beginning of MediaBrowser and refused to let it die on my Windows set top boxes.  Didn't think anything would ever come close to being able to replace the functionality of my perfectly setup Windows Media Center (with MediaBrowser) after Microsoft shelved WMC.  Oh how wrong I was.  😀

And yes, I had pointed out the "we" and "you" and what I knew you meant.

 

Link to comment
Share on other sites

datanet
4 minutes ago, Cheesegeezer said:

yes and at the moment there is no way to transfer your hard work to the core.

no the core scan creates new intro start and end points

so your plugin edit points are stored in our database not the core

Here in lies the transition. And why we need to have a method of integrating IntroSkip plugin edits to core emby.

Exactly.

So this is what i was alluding to in my earlier post about the migration being met with resistance for existing plugin users and the disjointed nature of the migration.  So I stand by my initial post. :)

Link to comment
Share on other sites

Cheesegeezer
2 minutes ago, datanet said:

Exactly.

So this is what i was alluding to in my earlier post about the migration being met with resistance for existing plugin users and the disjointed nature of the migration.  So I stand by my initial post. :)

My view is.. there are a lot of folk using our plugin already and have worked a lot on their intros and end credits for perfection. 
why should they be expected to do this all over again. just because the core has adopted this feature. 

we need to speak with Luke and Eric to find a good way to do this and until then, there is no way to please everyone that uses the plugin. 
 

 

  • Like 1
Link to comment
Share on other sites

datanet
22 minutes ago, Cheesegeezer said:

My view is.. there are a lot of folk using our plugin already and have worked a lot on their intros and end credits for perfection. 
why should they be expected to do this all over again. just because the core has adopted this feature. 

we need to speak with Luke and Eric to find a good way to do this and until then, there is no way to please everyone that uses the plugin. 
 

 

Except the problem is actually worse than that, we don't even have a method to edit those points in the core implementation.  At least yet.

  • Agree 1
Link to comment
Share on other sites

Cheesegeezer

And our api has a tag that says an episode hasIntro or hasCredit which could be pulled by the core to transfer chapter data(which is their driving force) for these features

  • Like 1
Link to comment
Share on other sites

3 hours ago, rbjtech said:

Intro detection could potentially be turned off I agree - as we now have manual and auto-skip options in the Core - but the key thing currently 'missing' is the ability to validate/edit the said detected data.

In the Plugin, you can select the Show and Season and edit the data - any of the timings below can be edited and it then regenerates the exact frame thumbnail so you can validate the change before hitting save.

Lower level function such as the ability to turn on/off autoskip on a user basis, or even show the 'Skip Intro' button at user level are nice to haves imo.

btw - you can click the episode Thumb on the left and it will just play the Intro it has detected - it's pretty neat .. 🙂

image.thumb.png.d66a50d19a3ee94ec7a68f8fd241fae0.png

 

 

Marker/chapter editing is going to come sooner rather than later, likely in a 4.7.X update, so I would suggest focusing on having the plugin use the core data and supplement it with features rather than having it's own data store. You can even put the detected credits into the core chapter list.

Link to comment
Share on other sites

Cheesegeezer
3 minutes ago, Luke said:

Marker/chapter editing is going to come sooner rather than later, likely in a 4.7.X update, so I would suggest focusing on having the plugin use the core data and supplement it with features rather than having it's own data store. You can even put the detected credits into the core chapter list.

We are already doing with the chapter markers this but we need a transfer option to migrate plugin to core. We can’t just sever it.

  • Agree 1
Link to comment
Share on other sites

datanet
4 hours ago, datanet said:

@chef will need to chime in here, but I do know he went through quite a few iterations of adjusting the various timing parameters to get the most accurate results that covered pretty much all but the extreme cases.

Furthermore, if nothing else, this "experiment" uncovered that there is no one size fits all when it comes to Intro detection and credit detection.  The detection process should be more modular (possibly in the form of detection plugins) or detection profiles that even have the possibility of being assigned per TV Series.  If memory serves, It was determined that the existing default detection had difficulty handling some Anime series.  There could be detection profiles that are better suited for handling this type of content.  Future OCR detection could be added as a detection process and/or added to detection profiles.  Similar detection info could be provided with the possibility of a future crowdsourced database of the intro and credit metadata.  Going in to this design with a modular format for detection opens up numerous opportunities for improvement in the detection process.  Emby would become the model on how it should be done.

 

4 hours ago, rbjtech said:

Just some I picked at random ... 

Halo - s1e1 - 17:55 > 18:56 

Halo s1e6 - 8:54 > 9:57

Halo s1e9 - 10:43 > 11:46

1883 - s1e6 - 8:34 > 9:39

Das Boot - s1e1 - 9:17 > 10:33

Alcatraz - s1e2 - 9:53 > 10:24

A quick pivot table from an export will give you the full stats - but 10 mins is imho too short.  The Plugin settled on using 15 mins for a 55 minute or greater episode  duration, dropping to to 10 for a 30-45 min episode - I forget the actual metrics, but it's not fixed.

 

 

@Luke Any thoughts on addressing this if we're expected to embrace the core detection process after coming from what the plugin detection process evolved in to?  Even if it is initially at least something as simple as a default detection algorithm (using the 10 minute window) you're currently using with the option to select (per TV Series) an "aggressive" detection profile that expands the detection window outside the 10 minutes.  Or better yet, use whatever algorithm chef is using for calculating this window as the optional "aggressive" setting.

Edited by datanet
Link to comment
Share on other sites

crusher11

Hopefully this question is less dumb than my ones from yesterday: what happens if I import all my timings, then later on go back and use MKVToolnix to add chapters to an episode which previously did not have any (but does have an intro and/or credits marker)?

Link to comment
Share on other sites

rbjtech
8 hours ago, datanet said:

Exactly.

So this is what i was alluding to in my earlier post about the migration being met with resistance for existing plugin users and the disjointed nature of the migration.  So I stand by my initial post. :)

So I believe this is incorrect.

When you import the data into the chapters - that is it - there is nothing more to do.

The hidden chapter points we imported ARE the Core database - there is no separate record of these details. 

People are assuming the chapters file is something special - it's not - it's data held in the CORE database (library.db) - in the chapters table to be precise - just like any other metadata.

You can turn the Plugin off at this point if you wanted to - and the CORE would continue to use the imported data - it would NOT replace it during it's scans because it already has an entry for that episode.

  • Like 1
Link to comment
Share on other sites

rbjtech
7 hours ago, Luke said:

Marker/chapter editing is going to come sooner rather than later, likely in a 4.7.X update, so I would suggest focusing on having the plugin use the core data and supplement it with features rather than having it's own data store. You can even put the detected credits into the core chapter list.

Agree with Luke - rather than store in both our own dB and the core dB, there is no reason why we cannot store it in the chapters table in the Core dB only - it makes no difference to the plugin where it gets it's data from and we are not  storing any exclusive data. 

Edited by rbjtech
Link to comment
Share on other sites

seanbuff
14 minutes ago, rbjtech said:

When you import the data into the chapters - that is it - there is nothing more to do.

The hidden chapter points we imported ARE the Core database - there is no separate record of these details. 

People are assuming the chapters file is something special - it's not - it's data held in the CORE database (library.db) - in the chapters table to be precise - just like any other metadata.

Ahhh this is much clearer now, thank you for articulating it this way.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...