Completed Show Intro Skip Option

[Cheesegeezer 3087]

18 minutes ago, rbjtech said:

The 'MarkerType' didn't even exist when the Plugin was written - that's why it's now 'missing'.  But to my point earlier - if emby core defaulted to MarkerType=Chapters(0), then the Plugin code is perfectly valid - because we are updating Chapters - not other MarkerTypes ..

if chef could update github, i could have this implemented and we could test it very quickly.  

But i agree, there could be a default fallback, however the core probably want it "required". 

[ebr 14917]

30 minutes ago, rbjtech said:

But to my point earlier - if emby core defaulted to MarkerType=Chapters(0)

It does.

30 minutes ago, rbjtech said:

then the Plugin code is perfectly valid - because we are updating Chapters

No its not because the current plug-in doesn't understand there IS a marker type so it is blowing it away on the new core intro markers.  Cheese understands the problem...

[rbjtech 4276]

4 minutes ago, ebr said:

No its not because the current plug-in doesn't understand there IS a marker type so it is blowing it away on the new core intro markers.  Cheese understands the problem...

Right - with you. Thanks.

[Cheesegeezer 3087]

2 minutes ago, ebr said:

It does.

No its not because the current plug-in doesn't understand there IS a marker type so it is blowing it away on the new core intro markers.  Cheese understands the problem...

Eric, just a quickie if i may....

Core implementation is to use these markers as triggers for button displays in the VideoOSD.  However you are not planning to write in the physical Intro Start or Credit End to the Item display. Like below?

 

[ebr 14917]

We don't plan to show them but they will still exist.

If your plugin tries to duplicate them as normal chapter markers, that could potentially cause an issue on the client side... not sure.

[rbjtech 4276]

4 minutes ago, ebr said:

We don't plan to show them but they will still exist.

If your plugin tries to duplicate them as normal chapter markers, that could potentially cause an issue on the client side... not sure.

It's just a named chapter - I don't believe there is any reason why they would cause issues.  They haven't done for the last 8 months in using the Introskip Plugin ..

[ebr 14917]

Just now, rbjtech said:

It's just a named chapter - I don't believe there is any reason why they would cause issues.  They haven't done for the last 8 months in using the Introskip Plugin ..

Things are different now and the front ends are looking for the intro start and end in sequence.  It might be okay, but it also might mess up the logic on the front end for finding where the intro ends.

[Cheesegeezer 3087]

5 minutes ago, ebr said:

We don't plan to show them but they will still exist.

If your plugin tries to duplicate them as normal chapter markers, that could potentially cause an issue on the client side... not sure.

Thats what i'm thinking, however we could just add 1000 ticks to the start and minus 1000ticks to the end of the existing markers which should place a new index for them and not conflict with code and just add them as ChapterType 0.  

[ebr 14917]

1 minute ago, Cheesegeezer said:

however we could just add 1000 ticks to the start and minus 1000ticks to the end of the existing markers

Please don't modify the core markers.  Instead, place yours with the reverse of that logic (start just before and end just after).

[rbjtech 4276]

The Core is looking for different MarkerTypes - it is not looking for chapters.   You could call it Micky Mouse if you wanted to - it doesn't matter what it's called, it's just a name.  Core is not looking for that 'name' - it is looking for the MarkerType.

All that would happen if you clicked on it (and Auto-Skip was not active) - is the 'Core' would then kick in and recognise it was inbetween Intro Start and Intro End markerTypes - and display the 'Skip Intro' button ... ?

[Cheesegeezer 3087]

4 minutes ago, ebr said:

Please don't modify the core markers.  Instead, place yours with the reverse of that logic (start just before and end just after).

yeah the plan is NOT to touch any enumTypes above 0.  We will only use the Type of chapter.  IntroStart/End/Credits Marker types are yours and I see now.  yes because your introskip button will logically move to the next chapter point.

Got it!! 

[ebr 14917]

6 minutes ago, rbjtech said:

The Core is looking for different MarkerTypes - it is not looking for chapters.   You could call it Micky Mouse if you wanted to - it doesn't matter what it's called, it's just a name.  Core is not looking for that 'name' - it is looking for the MarkerType.

Please understand that I have an intimate understanding of what the core and apps are currently doing .

My analysis and sugestions to Cheese stand.

[ebr 14917]

Also, depending on which runs first (core logic or plug-in) if you try to duplicate these in some fashion, they could get wiped out.

Honestly, I wouldn't try to do this.  Instead, I'd just wait for feedback on the new feature and see if enough people want visibility of these things for the option to be put into the core.

[Cheesegeezer 3087]

10 minutes ago, ebr said:

Please don't modify the core markers.  Instead, place yours with the reverse of that logic (start just before and end just after).

chapters.Add(new ChapterInfo
             {
               Name = introStartChapterName,
               StartPositionTicks = titleSequenceStart.Ticks - 1000,
               MarkerType= MarkerType.Chapter
               });

 

That should keep us both happy Eric.... What say yeee?

[Cheesegeezer 3087]

1 minute ago, ebr said:

Also, depending on which runs first (core logic or plug-in) if you try to duplicate these in some fashion, they could get wiped out.

Honestly, I wouldn't try to do this.  Instead, I'd just wait for feedback on the new feature and see if enough people want visibility of these things for the option to be put into the core.

ours is solely Scheduled Tasked based, your will be event driven when launching a TV Show( i would imagine).

 

[Cheesegeezer 3087]

56 minutes ago, ebr said:

Also, depending on which runs first (core logic or plug-in) if you try to duplicate these in some fashion, they could get wiped out.

Honestly, I wouldn't try to do this.  Instead, I'd just wait for feedback on the new feature and see if enough people want visibility of these things for the option to be put into the core.

Would conduct checks to see if any markers that are not chapters have been added. If they have then we can assume the intro detect has been successful and then do our integration.  
 

but this can be added at any point. We can still work on other stuff and credits isnt going to be added in initial release, so our plugin could still utilise our code to implement this. 

[chef 3746]

2 hours ago, TeamB said:

For a chapter editor you dont need to show lists or pages of items, just one item and its chapters with a way of selecting or searching for an item you want to edit. Think a little like the metedata manager with a tree selector on the left and when you click an item it shows you the items chapters  and allows you to edit them.

Actually it might be a good idea to have a look at the metedata manager plugin and see if it might be easier to add chapter editing to that, though last time i looked at the metedata manager plugin my brain hurt from all the crazy in there.

Edit: Oops i was thinking of the reports plugin not the metedata manager.

 

2 hours ago, Cheesegeezer said:

actually Rich, thinking about it @chef, this is our fault(well Mine), because I call the chapters from the core, however in the current code, i'm not saving the marker type when i get the list to our variable so when we insert the new chapter points and send that back to the server it's not adding in the markers.... this might actually be a lot easier for our interface with the core for the backend donkey work than we though

 

Homer Simpson - DOH!!!! 

We just didn't update. All good .

I like teamBs idea of a tree view with the data being accessible on the right side for chapters. 

That would most likely keep things very user friendly. 

Ive never tried that before, did you ever try a tree view layout (while growing your JavaScript skills)  cheese?

See what I did there? Trees, growing... You're welcome

[Cheesegeezer 3087]

2 minutes ago, chef said:

 

We just didn't update. All good .

exactly so this will probably fix it.

2 minutes ago, chef said:

I like teamBs idea of a tree view with the data being accessible on the right side for chapters. 

That would most likely keep things very user friendly. 

Ive never tried that before, did you ever try a tree view layout (while growing your JavaScript skills)  cheese?

Nope, but would work off the concept of options type. I only know about it, never had the desire to use it. but its more of a config thing rather than a beautiful frontend UI

however it shouldn’t be too difficult, it like nesting and option list inside an option list inside and option list… giving you plenty of…. Erm ….. options hahahahha

2 minutes ago, chef said:

See what I did there? Trees, growing... You're welcome

I literally just lost a rib i was laughing so hard

[rbjtech 4276]

So I'm not entirely sure I follow this 'Tree' idea but I'll follow the branches ... (sorry Dave, there goes the other rib ..) 

So using the amazing Metadata manager as an example () - are we suggesting that the Intro and Credit images/metadata get put under the episodes - the red Arrow ?

I don't *think* that will be as screen friendly as putting them in a table format as we do now?  Maybe once you get to Episode level - then it shows all the thumbs for all the episodes ?

 

[Cheesegeezer 3087]

Yeah thats what a tree is essentially, and I don’t think I’ve used that metadata manager for a very long time.

im shopping at the mo but can knock up a mock ui in a bit. 
 

need to think about fast accessibility to what you neep, swiping or mouse wheel. But completely agree we need a good portion to display what we have now displaying all data. 
 

so top bottom tree style would suit better than left and right like you show there.

[TeamB 2353]

4 hours ago, rbjtech said:

So I'm not entirely sure I follow this 'Tree' idea but I'll follow the branches ... (sorry Dave, there goes the other rib ..) 

So using the amazing Metadata manager as an example () - are we suggesting that the Intro and Credit images/metadata get put under the episodes - the red Arrow ?

I don't *think* that will be as screen friendly as putting them in a table format as we do now?  Maybe once you get to Episode level - then it shows all the thumbs for all the episodes ?

 

No, the tree is just to select the item you want to view chapters for, once selected the chapters are shown in the right hand panel just like the metedata manager.

[Cheesegeezer 3087]

23 minutes ago, TeamB said:

No, the tree is just to select the item you want to view chapters for, once selected the chapters are shown in the right hand panel just like the metedata manager.

Understand but you need a lot of space to pull it all in and allow for editing 

[TeamB 2353]

3 minutes ago, Cheesegeezer said:

Understand but you need a lot of space to pull it all in and allow for editing 

Especially since there could be a large undetermined number of chapters so the edit ui would have to be flexible enough to show all the chapters and allow editing.

My suggestion would be a tree view in the left panel and when you select an item in the tree a table of the chapters shown up in the right panel with colums (time, image name, type) with a del icon to remove the chapter. The time and name would be editable. At the top an add new and save button.

All image extraction would be done by the built in chapter image extraction schedule that already exists.

 

[rbjtech 4276]

1 hour ago, TeamB said:

Especially since there could be a large undetermined number of chapters so the edit ui would have to be flexible enough to show all the chapters and allow editing.

My suggestion would be a tree view in the left panel and when you select an item in the tree a table of the chapters shown up in the right panel with colums (time, image name, type) with a del icon to remove the chapter. The time and name would be editable. At the top an add new and save button.

All image extraction would be done by the built in chapter image extraction schedule that already exists.

 

Are you talking about a general chapter editor here ?

I'm talking about the editor for Introskip - it only has two extra chapters per episode - one for Intro (with two ACCURATE thumbnails - one for IntroStart and another for the IntroEnd) - you recalculate the subsequent chapter (I'll let Cheese explain) and then a 2nd Chapter for the Credits (Start).   

Have you seen/used the Plugin Introskip Editor ?  That works very well - it just needs a bit of tweaking with regards to navigation - and that's where the 'tree' idea may work instead of the drop down lists as they are now..  All the timings can be changed and as you hit save, it regenerated the new thumbnails.

 

Edited May 11, 2022 by rbjtech

[TeamB 2353]

5 minutes ago, rbjtech said:

Are you talking about a general chapter editor here ?

yes