Completed Show Intro Skip Option

[rbjtech 4249]

Hi @chef - Unless you have activated the Introskip Core (manually) then why do you need to deactivate the Introskip plugin ?  It is used by many people, myself included.

We are just writing chapters (if toggled to do so in the advanced settings in the plugin) using the standard API - so I'm not sure why this is 'breaking' the Core implementation - we are not writing anything non-standard - we are just using the MarkerType of 'Chapter' - the same as any other normal chapter .. ?

I'll be disabling Beta updates until this gets resolved ..

[rbjtech 4249]

7 hours ago, TeamB said:

On another note, one of the ideas I had with audio chromaprint detection was using it to SYNC subtitles and chapters to the correct location.
What I have found is sometimes when I have a movie or episode and I download subtitles they are offset by a number of seconds, I need to open up the options in playback and set an offset to get them to line up. One idea I had was to have a way to take a short audio chromaprint say 5 min into a movie that you could search for and know this was at offset x and then set your subtitile offset up to that so the subtitles were in sync with the audio track. Discussion for a different project I guess.

There are already a few tools that do this already.  I had a play with some of them a while back - they worked very well but for the life of me I can't remember what they were called .. let me look it up when I get some time.

[neik 837]

1 hour ago, rbjtech said:

There are already a few tools that do this already.  I had a play with some of them a while back - they worked very well but for the life of me I can't remember what they were called .. let me look it up when I get some time.

Subsync as an example, I used to use it and it was working near to perfection for me.

[rbjtech 4249]

5 minutes ago, neik said:

Subsync as an example, I used to use it and it was working near to perfection for me.

That's the one ! - Thanks @neik

[chef 3745]

@TeamB did you want to head up a team to write a chapter editor of some kind?

I know a ton of people on the forum who would be super happy to lend a hand in anyway, me being one of them.

 A chapter editor would be a powerful addition to emby, wether intro skip is used or not.

 

[Cheesegeezer 3086]

5 minutes ago, chef said:

@TeamB did you want to head up a team to write a chapter editor of some kind?

I know a ton of people on the forum who would be super happy to lend a hand in anyway, me being one of them.

 A chapter editor would be a powerful addition to emby, wether intro skip is used or not.

 

Arrrrrgh I hate you sometimes lol      

This could be knocked up very quickly i think.  There isn't much to it.  The problem here lies in if a user updates metadata all the chapter points would be lost unless we save all the chapterpoints in a db and update as task.  This is where it starts to grow arms and legs.

finishing up some last minute tweaks on VantagePoint.  i wanna get on with the MediaInfo plugin,  need to shelve recommendations until i finish iridium as that way.... we can dictate how the UI is populated and users interact with it... Far too limited with Emby Core access.

and i need to nip on with Iridium.  

[TeamB 2352]

28 minutes ago, chef said:

A chapter editor would be a powerful addition to emby, wether intro skip is used or not.

yes agree, as I have said I am somewhat surprised that there is not one already.

19 minutes ago, Cheesegeezer said:

This could be knocked up very quickly i think.  There isn't much to it.  The problem here lies in if a user updates metadata all the chapter points would be lost unless we save all the chapterpoints in a db and update as task.  This is where it starts to grow arms and legs.

ok so I dont understand this point about chapter points being lost if metadata is updated. Are you saying if any metadata is changed all the chapters are reset to default?

[DragonSkills99 3]

14 minutes ago, Cheesegeezer said:

This could be knocked up very quickly i think.  There isn't much to it.  The problem here lies in if a user updates metadata all the chapter points would be lost unless we save all the chapterpoints in a db and update as task.  This is where it starts to grow arms and legs.

I don't know where the problem lies here, you could easily extract the chapter infos from the videos using ffmpeg or ffprobe. (It would recommend using ffmpeg as there you'll get an ini File you can edit and then import back in, that way no chapters will be lost)

 

for the extraction you just need the command:

ffmpeg -i "video file.mp4" -f ffmetadata "meta.ini"

meta.ini then contains all meta informations including chapters and can after editing be brought back into the video with the following command

ffmpeg -i "video file.mp4" -i "meta.ini" -map 0 -map_metadata 1 -c copy "output.mp4"

The only downside is, that you have to work with a temp file, as ffmpeg can't overwrite the videofile it's reading from.

[Cheesegeezer 3086]

3 minutes ago, DragonSkills99 said:

I don't know where the problem lies here, you could easily extract the chapter infos from the videos using ffmpeg or ffprobe. (It would recommend using ffmpeg as there you'll get an ini File you can edit and then import back in, that way no chapters will be lost)

 

 

why do that already when emby does it for you, wasting CPU, memory and disk space.  

So what we try to do is not mess with what the emby core does and people get very irrate about changing their media files.  if the plugin has a glitch for what ever reason, you can upset someones experience.

 

3 minutes ago, DragonSkills99 said:

 

for the extraction you just need the command:

ffmpeg -i "video file.mp4" -f ffmetadata "meta.ini"

meta.ini then contains all meta informations including chapters and can after editing be brought back into the video with the following command

ffmpeg -i "video file.mp4" -i "meta.ini" -map 0 -map_metadata 1 -c copy "output.mp4"

The only downside is, that you have to work with a temp file, as ffmpeg can't overwrite the videofile it's reading from.

I'm very familiar with ffmpeg and it's command lines and created a an OCR app for detecting end credits, we are using it for black detect in introskip plugin and i'm also using it to insert Movie Titles on BBFC Rating slides, that convert on the fly when using vantage point plugin.

You have to understand that if that movie is 4K, the time to insert those and reprocess the video will be length and likely be able to fry an egg on your cpu in the morning.

So why don't we just use emby's chapter points that are already there manipulate them and have a backup txt file or utilise a database and API.

[chef 3745]

Yes the chapter editor should absolutely use what emby has extracted already.

Especially if the core version of intro skip has been run on them They would contain the Marker Types you'd need to label items in the editor.

 

[rbjtech 4249]

The ability to save any manual edits has always been at the top of the want list for the Plugin - simply because if people manually edit items, they want to be able to re-create that after a system failure, or emby refresh etc.

Currently the data is just saved in the dB, but this is of course not easily re-producible.

The original file is never updated - that is a very bad idea.

My preference would be to store any intro/credit and subsequently manually edited chapter info in the NFO file.  ie you just combine the chapter info out the original source file + the NFO file to recreate your full chapters list as and when required.  I believe the Core will need to do this anyway - as there needs to be someway to keep manually edited chapter info if using the Core editor (the same way it happens today if you manually edit other data types).

[TeamB 2352]

4 minutes ago, rbjtech said:

The ability to save any manual edits has always been at the top of the want list for the Plugin - simply because if people manually edit items, they want to be able to re-create that after a system failure, or emby refresh etc.

Currently the data is just saved in the dB, but this is of course not easily re-producible.

The original file is never updated - that is a very bad idea.

My preference would be to store any intro/credit and subsequently manually edited chapter info in the NFO file.  ie you just combine the chapter info out the original source file + the NFO file to recreate your full chapters list as and when required.  I believe the Core will need to do this anyway - as there needs to be someway to keep manually edited chapter info if using the Core editor (the same way it happens today if you manually edit other data types).

Any chapter edits or additions would be saved to the emby db and backed up in the normal backup process, there should be no need for further redundant backups.

[rbjtech 4249]

13 minutes ago, TeamB said:

Any chapter edits or additions would be saved to the emby db and backed up in the normal backup process, there should be no need for further redundant backups.

Disagree as would many others - being able to reproduce them outside of emby, or another instance of emby is what's key here as they are tied to a unique emby id.

Lets take an example - I share my central media with 3 or 4 instances of emby - but one media data source - thus if I edit the title of the movie - it first gets written to the local emby dB and then it gets written to the shared NFO file.  That NFO file is then picked up by the other 3 instances and subsequently written to the emby dB.

Portability is key. 

This does not currently happen with chapters - because emby doesn't even have a chapter editor.  But since the introduction of Introskip Plugin and now the Core, the introduction of MarkerTypes in addition to what's in the source file starts to become important if people have spent time curating them.

Edited May 11, 2022 by rbjtech

[chef 3745]

9 minutes ago, TeamB said:

Any chapter edits or additions would be saved to the emby db and backed up in the normal backup process, there should be no need for further redundant backups.

Do you have any layout ideas? 

I was trying to think about the best way you could show a bunch of chapters.

Tables have always been difficult to show on mobile interfaces. So it would seem to be logical to expect a chapter editor table to be only used on larger screens.

Perhaps images are not as important as the data itself. Timestamps, and markers.

 

[rbjtech 4249]

2 minutes ago, chef said:

Perhaps images are not as important as the data itself. Timestamps, and markers.

Images as CRITICAL - how else would you know if the Marker was accurate or not ?

This is why the the Plugin uses images .. and we can very quickly see, without even looking at the timings, if the Intro's and Credits are accurate.. ?

[rbjtech 4249]

Without even looking at the timings - I can see that these Intro's and credits are accurate - they are almost the same frame in some cases ..  but just having a list of timings - I have no idea if they are accurate or not .. ?

[ebr 14910]

12 hours ago, TeamB said:

But does that just create named chapters?

Sorry, did not read all the ensuing discussion but this isn't what it does.  Chapters in the core are now a more generic "marker" and each one has a MarkerType (e.g. Chapter, IntroStart...).

The introduction of this is actually why the current plug-in is conflicting with the core.

[rbjtech 4249]

6 minutes ago, ebr said:

Sorry, did not read all the ensuing discussion but this isn't what it does.  Chapters in the core are now a more generic "marker" and each one has a MarkerType (e.g. Chapter, IntroStart...).

The introduction of this is actually why the current plug-in is conflicting with the core.

tbh Eric, I'm actually confused as to why - as the chapters added by the Plugin are of ChapterType=0 (Chapters),  they are not ChapterType=IntroStart or IntroEnd - so they should not conflict at all .. ?  If we need to update the Plugin to also write/specify the ChapterType=Chapter(0) when writing - then that makes sense but maybe it's better to assume a default chapter type of 'Chapter' if not specified ?

 

Edited May 11, 2022 by rbjtech

[Cheesegeezer 3086]

5 minutes ago, ebr said:

Sorry, did not read all the ensuing discussion but this isn't what it does.  Chapters in the core are now a more generic "marker" and each one has a MarkerType (e.g. Chapter, IntroStart...).

The introduction of this is actually why the current plug-in is conflicting with the core.

agreed and that's what we thought.  i checked it out and enumeration types are included now for the ChapterInfo

if (sequence.HasCreditSequence && !chapters.Exists(chapterPoint => chapterPoint.Name == endCreditChapterName))
                            {
                                Log.Debug("CHAPTER: Adding End Credit Chapter Point for {0}: {1}, Episode{2}: {3} at {4}",
                                    tvShowName, seasonName, episodeNo.ToString(), item.Name, creditSequenceStart);
                                

                                chapters.Add(new ChapterInfo
                                {
                                    Name = endCreditChapterName,
                                    StartPositionTicks = creditSequenceStart.Ticks,
                                    MarkerType = MarkerType.CreditsStart,
                                });

                                chapters.Sort(CompareStartTimes);
                                
                            }

So i guess adding this to our ChapterInsert class should start to fix the two.  

[TeamB 2352]

26 minutes ago, rbjtech said:

This does not currently happen with chapters

Writing and reading in chapter info to the nfo file is not the responsibility of the chapter editor, its the nfo metadata code that needs to do that.

[rbjtech 4249]

1 minute ago, TeamB said:

Writing and reading in chapter info to the nfo file is not the responsibility of the chapter editor, its the nfo metadata code that needs to do that.

Agreed - but first you need to include it in editable metadata  

[Cheesegeezer 3086]

9 minutes ago, rbjtech said:

tbh Eric, I'm actually confused as to why - as the chapters added by the Plugin are of ChapterType=0 (Chapters),  they are not ChapterType=IntroStart or IntroEnd - so they should not conflict at all .. ?  If we need to update the Plugin to also write/specify the ChapterType=Chapter(0) when writing - then that makes sense but maybe it's better to assume a default chapter type of 'Chapter' if not specified ?

 

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

[TeamB 2352]

1 minute ago, rbjtech said:

Agreed - but first you need to include it in editable metadata  

the chapter editor would do just that, edit the chapters that are there in the emby db, just like when you edit any other item details, it is saved in the emby db. How it is exported or backed up is not the plugins responsibility.

[TeamB 2352]

52 minutes ago, chef said:

Do you have any layout ideas? 

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.

Edited May 11, 2022 by TeamB

[rbjtech 4249]

11 minutes 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!!!! 

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