Save IntroSkip Metadata inside NFO

[rbjtech 4939]

Having just lost all of my previous Introskip data from the old Plugin due to a corrupt db, needing me to create a new TV library (subsequently needing hours/days worth of re-detection using the Core Introskip) - would it be possible to include the Introskip 'hidden' chapter markers in the standard metadata/nfo emby processes ?

ie

1. Save the Introskip MarkerType=IntroStart,EndEnd and CreditStart in the episode NFO file.

2. On a episode/show/library import - just read the NFO as you do now, and if the data is present, then use that in the Chapter Table instead of re-detecting it. 

3. Ideally allow us to see/edit that data in the standard metadata editor for that episode, but the main concern is the ability to recreate it without the need for the emby db/chapter table / ItemId dependency.

Thanks.

[Luke 39783]

HI, yes some sort of edit and backup process for this is planned for future updates. Thanks.

[aelzki 3]

Hi! Would like to request to have the "intro Skip" saved with the media. This will help as well when moving a large library to another location without having the scan take longer as well. 

[Cheesegeezer 3101]

6 minutes ago, aelzki said:

Hi! Would like to request to have the "intro Skip" saved with the media. This will help as well when moving a large library to another location without having the scan take longer as well. 

 

[Cheesegeezer 3101]

What about a seperate json file inside the folder. Which is purely for saving intro and credit markers. That way if the user doesn’t save nfo to folder its still there. A plugin could be easily written for this to backup and restore simply using chapters. 
 

[Cheesegeezer 3101]

On 21/10/2022 at 16:46, rbjtech said:

Having just lost all of my previous Introskip data from the old Plugin due to a corrupt db, needing me to create a new TV library (subsequently needing hours/days worth of re-detection using the Core Introskip) - would it be possible to include the Introskip 'hidden' chapter markers in the standard metadata/nfo emby processes ?

ie

1. Save the Introskip MarkerType=IntroStart,EndEnd and CreditStart in the episode NFO file.

2. On a episode/show/library import - just read the NFO as you do now, and if the data is present, then use that in the Chapter Table instead of re-detecting it. 

3. Ideally allow us to see/edit that data in the standard metadata editor for that episode, but the main concern is the ability to recreate it without the need for the emby db/chapter table / ItemId dependency.

Thanks.

 

Just now, Cheesegeezer said:

What about a seperate json file inside the folder. Which is purely for saving intro and credit markers. That way if the user doesn’t save nfo to folder its still there. A plugin could be easily written for this to backup and restore simply using chapters. 
 

i can knock this up pretty quickly i think.

[sydlexius 266]

9 minutes ago, Cheesegeezer said:

 

i can knock this up pretty quickly i think.

This would be handy, provided the data can go in both directions. 

[Cheesegeezer 3101]

 

11 minutes ago, sydlexius said:

This would be handy, provided the data can go in both directions. 

RTFP

[sydlexius 266]

47 minutes ago, Cheesegeezer said:

 

RTFP

I assume the F isn't for "Friendly" or "First" 

[elpoolet 21]

As previously said, it would be a great improvement, especially if it's possible to export this data to a place that won't be resetted when moving files.

I suggested sort a this in a post... ( 

) Glad to hear that this feature (or an approaching one) is on the way...

And if the ability to add this information inside an mkv (or mp4) rather than outside, it could be an amazing feature, but, even it's saved outside, I'm very interesting by trying this new feature and help to improve app.

[sydlexius 266]

6 minutes ago, elpoolet said:

As previously said, it would be a great improvement, especially if it's possible to export this data to a place that won't be resetted when moving files.

I suggested sort a this in a post... ( 

) Glad to hear that this feature (or an approaching one) is on the way...

And if the ability to add this information inside an mkv (or mp4) rather than outside, it could be an amazing feature, but, even it's saved outside, I'm very interesting by trying this new feature and help to improve app.

I'm not a big fan of letting my media streaming solutions modify my media, however it may make sense to output the fingerprint and timestamp data in Edit Decision List (EDL) format.  There seems to be support for notes fields as well as comments (potentially a place to stick fingerprint data).   Also, there are tools to automatically apply EDL timestamps to MKV and MP4 chapters.

[Cheesegeezer 3101]

Got cracking with this, shouldn't take long.  I have to help some clients in Holland with some oilfield data this evening, so will be limited on what I can actually get stuck into.

But hopefully will have something for testing tomorrow.

 

[elpoolet 21]

5 minutes ago, sydlexius said:

I'm not a big fan of letting my media streaming solutions modify my media, however it may make sense to output the fingerprint and timestamp data in Edit Decision List (EDL) format.  There seems to be support for notes fields as well as comments (potentially a place to stick fingerprint data).   Also, there are tools to automatically apply EDL timestamps to MKV and MP4 chapters.

I also prefer the streaming server does not modify my files.
But If it could save and/or read the Intro, Credits (and Recap) informations to/from an external file (for example : 1 file by folder for TV Shows) it would be great.
The processing rule could be : 
 - Is there Intro/Recap/Credits information in the external file ?
 - If yes, update DB with this information
then
 - is there information inside DB ?
 - if no, process by the SCheduled task to create audio fingerprints of the first 10 minutes of the show, then try to found the Intro....
then
 - is there information inside DB ?
 - if yes, and saving enabled : save this info inside external file....

What do you think of these rules ?

[elpoolet 21]

7 minutes ago, Cheesegeezer said:

Got cracking with this, shouldn't take long.  I have to help some clients in Holland with some oilfield data this evening, so will be limited on what I can actually get stuck into.

But hopefully will have something for testing tomorrow.

 

May I ask, what is the primary key of the backup/restore ?

Is this the Item.Id ?, the full metadata path ?, the File (TV show) path ?
Thanks

[Cheesegeezer 3101]

6 minutes ago, elpoolet said:

May I ask, what is the primary key of the backup/restore ?

Is this the Item.Id ?, the full metadata path ?, the File (TV show) path ?
Thanks

it can't be any of those, it would need to be based on TVDBId, Series Name, Season and Episode Number.  

Because if you need to restore to a completely new install, then all of the variables you mention will change.  This is why you will need to assign a Backup path which is outside of the emby ecosystem, so it's completely independant and accessable all the time.

Hope that makes sense chief  

[elpoolet 21]

5 minutes ago, Cheesegeezer said:

it can't be any of those, it would need to be based on TVDBId, Series Name, Season and Episode Number.  

Because if you need to restore to a completely new install, then all of the variables you mention will change.  This is why you will need to assign a Backup path which is outside of the emby ecosystem, so it's completely independant and accessable all the time.

Hope that makes sense chief  

Sounds Great  !!!

And what if the TVDB-ID is missing but ther'es a TMDBID ?
How about medias without external ID at all ? (I'm just guessing, I don't have TV shows with such caracteristics.. but I thinks it's possible)

[Cheesegeezer 3101]

1 minute ago, elpoolet said:

Sounds Great  !!!

And what if the TVDB-ID is missing but ther'es a TMDBID ?
How about medias without external ID at all ? (I'm just guessing, I don't have TV shows with such caracteristics.. but I thinks it's possible)

of course it is, and there needs to be a fall back.  Especially for users that meticulously create Episodes under custom series for non TVDB, TMDB or IMDB.  This is where testing comes in so we capture everything.

It's not my first rodeo at this pal  

[elpoolet 21]

24 minutes ago, Cheesegeezer said:

of course it is, and there needs to be a fall back.  Especially for users that meticulously create Episodes under custom series for non TVDB, TMDB or IMDB.  This is where testing comes in so we capture everything.

It's not my first rodeo at this pal  

It's just perfect.

I'm eager to be able to test it.
I stay in touch of evolution...

Many thanks.

[Cheesegeezer 3101]

53 minutes ago, elpoolet said:

I also prefer the streaming server does not modify my files.
But If it could save and/or read the Intro, Credits (and Recap) informations to/from an external file (for example : 1 file by folder for TV Shows) it would be great.
The processing rule could be : 
 - Is there Intro/Recap/Credits information in the external file ?
 - If yes, update DB with this information
then
 - is there information inside DB ?
 - if no, process by the SCheduled task to create audio fingerprints of the first 10 minutes of the show, then try to found the Intro....
then
 - is there information inside DB ?
 - if yes, and saving enabled : save this info inside external file....

What do you think of these rules ?

This is not what i had in mind for the restore/backup utility.

The user can set up a backup every 24hrs and it will just overwrite the existing backup.

On a restore, it will completely overwrite all of the Intro/Credit Markers with the information stored in the backup.

Recap isn't even a feature yet.  We planned to add that to the introskip plugin, where the user could say that a season or episode's recap was directly before the Intro and then everything before the IntroEndMarker would be skipped. But we never implemented it, the core took over and TeamB decided to go his own route. so we binned the IntroSkip Plugin that was far superior to all of the current solutions available.

Anyways.  That's what i'm planning with the scope of this plugin. 

 

[Cheesegeezer 3101]

[Cheesegeezer 3101]

Right thats me for the night but i have nearly all the info to create the backup jsons now.

Then just need to smash the restore and get some testers

[elpoolet 21]

1 minute ago, Cheesegeezer said:

Right thats me for the night but i have nearly all the info to create the backup jsons now.

Then just need to smash the restore and get some testers

You get at least one tester !!!
I volunteer

[rbjtech 4939]

Hi Dave - only just seen this.

@Cheesegeezer

Great that you are working on a solution, but I'm a little confused why you are exporting to an external JSON file - taking the process outside of emby ?

Emby already has the handlers to 'write' this NFO (and save any other 'custom' metadata you may have modified) and subsequently it also reads the NFO during a metadata refresh, restore or library relocation.   The NFO's use the standard provider Id's as you know, they are not 'tied' to emby ItemId's.

Saving the Intro/Credit data in this file seems a logical place to save it.

If you don't use NFO's in your emby config - then you are also relying on the Emby dB to save all your custom metadata anyway - so you probably have an alternate way of backing up this custom metadata  (or you are not backing it up at all...)

An EDL file is also a reasonable option as previously mentioned - but Emby does not support EDL files  - so while this would be great for external players that do - it doesn't benefit Emby at this time.

Keeping it all within Emby means that when you refresh metadata on an item - it automatically pulls the Introdata (if available) at that time,  using an external source, means I then need to go and find that item and recover it's Introdata (if I remember to do so..) - which then somewhat defeats the purpose of having it available vs being re-detected.

[Cheesegeezer 3101]

5 minutes ago, rbjtech said:

Hi Dave - only just seen this.

@Cheesegeezer

Great that you are working on a solution, but I'm a little confused why you are exporting to an external JSON file - taking the process outside of emby ?

Emby already has the handlers to 'write' this NFO (and save any other 'custom' metadata you may have modified) and subsequently it also reads the NFO during a metadata refresh, restore or library relocation.   The NFO's use the standard provider Id's as you know, they are not 'tied' to emby ItemId's.

Agreed and you answer the reason why an external file is necessary below.  

5 minutes ago, rbjtech said:

Saving the Intro/Credit data in this file seems a logical place to save it.

If you don't use NFO's in your emby config - then you are also relying on the Emby dB to save all your custom metadata anyway - so you probably have an alternate way of backing up this custom metadata  (or you are not backing it up at all...)

5 minutes ago, rbjtech said:

Keeping it all within Emby means that when you refresh metadata on an item - it automatically pulls the Introdata (if available) at that time,  using an external source, means I then need to go and find that item and recover it's Introdata (if I remember to do so..) - which then somewhat defeats the purpose of having it available vs being re-detected.

But i will not be able to initiate the info being pulled in by the refresh metadata, because the core isn't looking for that info in the nfo file... currently.

Basically you will need the core to implement what you are looking for.  

Yet again..... at least this is a stop gap until something is implemented by the core.

 

12 hours ago, Cheesegeezer said:

This is not what i had in mind for the restore/backup utility.

The user can set up a backup every 24hrs and it will just overwrite the existing backup.

On a restore, it will completely overwrite all of the Intro/Credit Markers with the information stored in the backup.

 

[rbjtech 4939]

50 minutes ago, Cheesegeezer said:

Yet again..... at least this is a stop gap until something is implemented by the core.

Understood - I guess I'm trying to save you some work  - but as we have no idea on when the core solution will be provisioned, this could turn into 'the' solution..

Thanks Dave - I look forward to testing it as I have one or two episodes ..