Completed Show Intro Skip Option

[rbjtech 4223]

38 minutes ago, ebr said:

Nothing alleged about it.  There is a problem and Cheese acknowledged (and I believe) fixed it.

Luke told the plug-in devs a couple weeks ago exactly which features would be in the initial core implementation.  They were - intro identification, integration of that into the apps (via a button and auto skip functionality) and a chapter editor.  Other features will be considered after that initial implementation based on feedback.

ok - The Intro Skip Core (turned off) and the Plugin version work perfectly together and have done since you first released Introskip Core - thus my view that this has been mis-identified as 'broken' when infact it is only broken when you try and use both together. 

40 minutes ago, ebr said:

Luke told the plug-in devs a couple weeks ago exactly which features would be in the initial core implementation.  They were - intro identification, integration of that into the apps (via a button and auto skip functionality) and a chapter editor.  Other features will be considered after that initial implementation based on feedback.

ok - that's fair enough - I was not aware of this commitment.  Thanks for the update.

[chef 3745]

Hey Guys. the GitHub is updated with the most recent plugin code. I didn't change anything. It's all the same since we left it a couple months ago.

Cheese! Rich! You have to add the proper markers for chapters. That's all that has to be fixed.

I'm screwed for time. I'm working the COVID units every night, and I'm just exhausted. It is mentally exhausting, and physically draining me. I wish I had more time, but it is just a really bad time right now to do anything I actually want to do... which is program computers. I'm very sorry. 

 

 

 

[Cheesegeezer 3086]

1 minute ago, chef said:

Hey Guys. the GitHub is updated with the most recent plugin code. I didn't change anything. It's all the same since we left it a couple months ago.

Cheese! Rich! You have to add the proper markers for chapters. That's all that has to be fixed.

I'm screwed for time. I'm working the COVID units every night, and I'm just exhausted. It is mentally exhausting, and physically draining me. I wish I had more time, but it is just a really bad time right now to do anything I actually want to do... which is program computers. I'm very sorry. 

 

 

 

You’re a star fella. That’s perfect I’ll get the changes implemented and me and Rich can test as were both on 38.

hey hang in there fella, keep your chin up and get some sleep. Hope you can get back to some normality soon bro!

[Cheesegeezer 3086]

36 minutes ago, chef said:

Hey Guys. the GitHub is updated with the most recent plugin code. I didn't change anything. It's all the same since we left it a couple months ago.

Cheese! Rich! You have to add the proper markers for chapters. That's all that has to be fixed.

I'm screwed for time. I'm working the COVID units every night, and I'm just exhausted. It is mentally exhausting, and physically draining me. I wish I had more time, but it is just a really bad time right now to do anything I actually want to do... which is program computers. I'm very sorry. 

 

 

 

Still showing 1.79 but if it’s completely updated I’ll change version to 2.0 so it’s known to be compatible with emby core

[chef 3745]

51 minutes ago, Cheesegeezer said:

Still showing 1.79 but if it’s completely updated I’ll change version to 2.0 so it’s known to be compatible with emby core

For testing change the plugin ID. Test it. But, maybe be cautious of creating a public release until you know for sure the markerTypes are working, and compatible.

 

Otherwise the core devs would have to disable the new id.

Cool news is that if you are successful with the plugin data and the chapter markerTypes, you indirectly cause the button to show. Success! 

Sorry I can't be of more help. But, markerTypes == client button  

Which if anyone reads that... is gonna be the same for the core data. The data is pretty much the same... So exciting... Yeah... but... not really.

 

[crusher11 851]

So the core implementation is actually irrelevant?

I'm so confused...

[samuelqwe 313]

1 hour ago, crusher11 said:

So the core implementation is actually irrelevant?

I'm so confused...

Right now, the plugin and core implementation store detected intros in two completely different places.

However, once updated, the plugin should store the detected intros in the same place and in the same way as the core implementation.

This will allow the plugin to work together with the core implementation to augment the experience with additional features that the Emby devs don’t implement in the core.

So to answer your question, the core implementation is not completely irrelevant as it gives us an official way to store the data, which is also what provides the timings for the skip intro button.

[crusher11 851]

2 minutes ago, samuelqwe said:

Right now, the plugin and core implementation store detected intros in two completely different places.

However, once updated, the plugin should store the detected intros in the same place and in the same way as the core implementation.

This will allow the plugin to work together with the core implementation to augment the experience with additional features that the Emby devs don’t implement in the core.

So to answer your question, the core implementation is not completely irrelevant as it gives us an official way to store the data, which is also what provides the timings for the skip intro button.

But Luke said elsewhere the core wouldn't be able to use timings from the plugin.

[samuelqwe 313]

50 minutes ago, crusher11 said:

But Luke said elsewhere the core wouldn't be able to use timings from the plugin.

With the current version of the plugin that is true, however we can update the plugin such that the core can use the timings from the plugin. It’s just a matter of changing how the data is stored so that it matches the core.

[rbjtech 4223]

12 hours ago, chef said:

For testing change the plugin ID. Test it. But, maybe be cautious of creating a public release until you know for sure the markerTypes are working, and compatible.

 

Otherwise the core devs would have to disable the new id.

Cool news is that if you are successful with the plugin data and the chapter markerTypes, you indirectly cause the button to show. Success! 

Sorry I can't be of more help. But, markerTypes == client button  

Which if anyone reads that... is gonna be the same for the core data. The data is pretty much the same... So exciting... Yeah... but... not really.

 

Thanks @chef 

@Cheesegeezer - Once you have modified the chapters - let me know as I'm aware of the MarkerType's the Core are using and I can check via the database directly or via the API as it returns the MarkerType in the JSON response if you include 'Chapters'.

Edited May 17, 2022 by rbjtech

[Cheesegeezer 3086]

12 hours ago, chef said:

For testing change the plugin ID. Test it. But, maybe be cautious of creating a public release until you know for sure the markerTypes are working, and compatible.

 

Otherwise the core devs would have to disable the new id.

Cool news is that if you are successful with the plugin data and the chapter markerTypes, you indirectly cause the button to show. Success! 

Sorry I can't be of more help. But, markerTypes == client button  

Which if anyone reads that... is gonna be the same for the core data. The data is pretty much the same... So exciting... Yeah... but... not really.

 

@chef, have you started a new repo? There's no updated on Github at all fella.

Nothing has been updated on Github

[chef 3745]

2 hours ago, Cheesegeezer said:

@chef, have you started a new repo? There's no updated on Github at all fella.

Nothing has been updated on Github

I'll push what I have. But I'm pretty sure it is the same code that is there.

I scraped other stuff I was trying. My code was deplorable you would have laughed and thought "what is he doing??"

 

[rbjtech 4223]

10 minutes ago, chef said:

I'll push what I have. But I'm pretty sure it is the same code that is there.

I scraped other stuff I was trying. My code was deplorable you would have laughed and thought "what is he doing??"

 

Whatever you were doing @chef , it has been working PERFECTLY for the last 3 months - zero issues, zero crashes, every single relevant Intro/credit found with microsecond accuracy ..   I still smile every time I see the 'Intro and/or Credit Skipped' message .. 

You were doing something right .. be proud. 

Edited May 17, 2022 by rbjtech

[chef 3745]

I pushed what I had, but I totally forgot how to create a pull request. It took a minute and then a couple more...

Did it work? 

[chef 3745]

26 minutes ago, rbjtech said:

Whatever you were doing @chef , it has been working PERFECTLY for the last 3 months - zero issues, zero crashes, every single relevant Intro/credit found with microsecond accuracy ..   I still smile every time I see the 'Intro and/or Credit Skipped' message .. 

You were doing something right .. be proud. 

Thank you sir.

[Cheesegeezer 3086]

36 minutes ago, chef said:

I pushed what I had, but I totally forgot how to create a pull request. It took a minute and then a couple more...

Did it work? 

Looks like it has. Thanks dooood

[fallenwitch3r 41]

Is there a new version for testing out there?

[Cheesegeezer 3086]

2 minutes ago, fallenwitch3r said:

Is there a new version for testing out there?

nope not yet.

i think @Admin should start their own thread for Core Implementation testing.

This thread should be left for the plugin.

[rbjtech 4223]

5 minutes ago, Cheesegeezer said:

nope not yet.

i think @Admin should start their own thread for Core Implementation testing.

This thread should be left for the plugin.

It's a valid point - Could the title maybe be changed by a Mod to include the word Plugin - as 99.99% of this thread is related to the Plugin.. @CBers

The Core already has it's own Introskip testing thread - here

[CBers 6766]

25 minutes ago, rbjtech said:

It's a valid point - Could the title maybe be changed by a Mod to include the word Plugin - as 99.99% of this thread is related to the Plugin.. @CBers

The Core already has it's own Introskip testing thread - here

I've renamed it, hope that's OK? 

 

[Cheesegeezer 3086]

5 minutes ago, CBers said:

I've renamed it, hope that's OK? 

 

Cheers corn beef

[datanet 120]

Hopefully the plugin will be able to run along side the core implementation for the foreseeable future since it seems it may be a while until there is feature parity between the plugin and core implementation.

I'm a self-proclaimed Emby fanboy, but I do have to say I am a little confused and surprised how this has evolved.  It seemed Luke stated somewhat recently that he was moving towards making Emby more "modular" and had even broken out some of the core code as plugins.  I could understand Luke taking on the task of extending the core API and providing hooks to better support the existing plugin and providing the ability to do things it's currently not able to do (such as a manual skip button)...especially since this one already works very well and has plenty of flexibility and features.  This seems like a reversal of Luke's vision/preference to keep/move features like this out as plugins. 

There's been at least 3 "outside" contributors (predominately @chef) to the design and code that makes up the auto skip feature.  As a whole, fixes, improvements and updates have happened relatively quickly.  More importantly, they have listened and are responsive to requests and are continually striving to improve the plugin within the limitations of the Emby plugin API.  My fear is that moving this auto skip functionality to the closed core code as opposed to extending the API and keeping it as a plugin (where it would likely continue getting the love and attention it currently does), it will get buried in the myriad of other things Luke (and team) are working on in the pool of "popular" features for Emby.  I suspect this will result in slow and/or limited further tweaking/development of the auto skip feature (such as the recently mentioned OCR recognition as an additional detection method) and further improvements will never or almost never happen.  Don't get me wrong, I think @Luke and team are doing an incredible job...but they already have a lot on their plate and I'm just not understanding why they'd absorb that additional burden when the current development of this plugin was being handled perfectly fine...they just needed the API extended a little to incorporate the remaining wish list items.

Someone help me understand the logic taking place here.

Edited May 18, 2022 by datanet

[chef 3745]

1 minute ago, datanet said:

Hopefully the plugin will be able to run along side the core implementation for the foreseeable future since it seems it may be a while until there is feature parity between the plugin and core implementation.

I'm a self-proclaimed Emby fanboy, but I do have to say I am a little confused and surprised how this has evolved.  It seemed Luke stated somewhat recently that he was moving towards making Emby more "modular" and had even broken out some of the core code as plugins.  I could understand taking on the task of extending the core API and providing hooks that would allow the current plugin to handle certain things it's currently not able to do (such as a manual skip button) but still stick with the existing plugin, especially since this one already works very well and has plenty of flexibility and features.  This seems like a reversal of Luke's vision/preference to keep/move features like this out as plugins. 

There's been at least 3 "outside" contributors (predominately @chef) to the design and code that makes up the auto skip feature.  As a whole, fixes, improvements and updates have happened relatively quickly.  More importantly, they have listened and are responsive to requests and are continually striving to improve the plugin within the limitations of the Emby plugin API.  My fear is that moving this auto skip functionality to the closed core code as opposed to extending the API and keeping it as a plugin (where it would likely continue getting the love and attention it currently does), it will get buried in the myriad of other things Luke (and team) are working on in the pool of "popular" features for Emby.  I suspect this will result in slow and/or limited further tweaking/development of the auto skip feature (such as the recently mentioned OCR recognition as an additional detection method) and further improvements will never or almost never happen.  Don't get me wrong, I think @Luke and team are doing an incredible job...but they already have a lot on their plate and I'm just not understanding why they'd absorb that additional burden when the current development was being handled perfectly fine...they just needed the API extended a little to incorporate the remaining wish list items.

Someone help me understand the logic taking place here.

I think that in time we will be pleasantly surprised by what the core version will have to offer for intro skip. Having the methods implemented in the core will inevitably create faster scans, which will be enough of a bonus for me to use it specifically. 

Yes the core team are a busy bunch, but they have taken this on and are actively implementing the feature to make it a pretty powerful piece of tech in Emby.

The plugin is great too, don't get me wrong (it is our baby). But, we had been in communications with the core team for the better part of  two years, while  attempting to get it functional enough (POC) to have something similar implemented in production. 

Although the hand off may seem a little "janky", the end result is going to be what you'd expect from emby, a great feature that works as advertised. We'll see  updates/upgrades that will eventually have all the expected functionalities the plugin had, I'm sure.   

It's a big deal to implement something new into an already working product. Anything added has consequences (good/bad).

So although it will take time to iron out all the bits, and hit the expectations people have (especially when it comes to emby's product reputation), it will.  

 

You've been here since the start, and took an active role in helping to get intro skip to be a viable proof of concept. So I would like to personally thank you @datanet.  

[crusher11 851]

If the core could use timings generated by the plugin, enabling me to just carry over what I've already done and continue to make edits where necessary, then it wouldn't really be a problem.

It's this weird in-between point that bothers me, where it's not even enabled in Emby but they've killed the plugin anyway. I'm still waiting to update my server until that's resolved, and even once it is I'm not sure how to go about actually using it.

[rbjtech 4223]

We should be updating the chapter code reasonably soon, which will re-enable the Plugin code to work alongside the underpinnings of the Core version.

Nothing else has changed, and the Introskip Plugin continues to work and be fully operational - excl the manual button that seems so desirable for many people.

There are two possible paths for the future of the Introskip Plugin -

a) Embu Core add the ability for us to use the 'Button' via the standard API without even enabling the Core Introskip feature.  This may be fully functional today - technically it's easy, we just haven't fully investigated yet.    This would mean the Plugin writing it's Intro 'data' partially to the Core - we can't write all of it because the Core is, as I understand it, not doing Credit Detection but this may change.

b) The Introskip plugin is abandoned as a Beta and we wait for the Core to introduce all the essential features the Plugin had.  This Plugin was not developed in isolation - we had a LOT of testers and a LOT of feedback on what features to add/tweek.

 

My preference is obviously a) but from a developers perspective, nobody wants to invest time and effort into a product that will ultimately be replaced 'sometime' in the future.   The odd 'maintenance' release should be achievable though and if the Introskip Plugin can run in parallel until the Core catches up functionally/surpasses it - then that is better for everyone.

 

There is actually a 3rd option, which is to continue to investigate and prove the technology of sourcing the FP metadata from the cloud - an idea from @TeamB  This actually opens up a world of new possibilities that cannot be implemented by the Plugin or the Core.   The downside is this needs crowd assistance to get the core metadata - but this is how thetvdb and tmdb started so it just needs interest ...