Jump to content

Plugin - Chapter Editor (ChapterApi)


TeamB

Recommended Posts

TeamB
4 minutes ago, neik said:

Just thinking out load but those fingerprint would probably be stored best at TVDB or the likes.

a central portal like tvdb or some other system would be best yes.

the audio fingerprints are not big, about the size of an artwork image from memory so storage is not really an issue.

the thing is the core auto detection approach does mostly work, it has its issues but it does mean if you have multiple episodes from a season it has a reasonable chance of working so i can see why most systems like emby and plex went with that approach.

Link to comment
Share on other sites

  • 2 weeks later...
Killface69

I like the idea of chapters being treated like additional metadata.

I've stumbled upon chapter Editor  https://www.videohelp.com/software/chapterEditor by hubblec4 https://forum.doom9.org/showthread.php?t=169984

One of its features can access a database based upon a backup of chapterdb with also more recent entries. Downside is that it's all done by importing, searching, saving manually, and once I replace the file, the chapters are gone. The idea could be to ask the author to also use the db for your plugin as metadata source.

Key features could be:

  • If files has chapters but no names, select a release with the same runtime and chapter amount and use the names only
  • Import chapters in general / only when missing / preferred with names
Link to comment
Share on other sites

TeamB
On 1/6/2024 at 12:15 AM, Killface69 said:

I like the idea of chapters being treated like additional metadata.

I've stumbled upon chapter Editor  https://www.videohelp.com/software/chapterEditor by hubblec4 https://forum.doom9.org/showthread.php?t=169984

One of its features can access a database based upon a backup of chapterdb with also more recent entries. Downside is that it's all done by importing, searching, saving manually, and once I replace the file, the chapters are gone. The idea could be to ask the author to also use the db for your plugin as metadata source.

Key features could be:

  • If files has chapters but no names, select a release with the same runtime and chapter amount and use the names only
  • Import chapters in general / only when missing / preferred with names

what database is it using? how do you get access to the database?

If you are looking to just back up your chapters in Emby then I think that is comming at some point. Team emby said they want to have chapters backed up and restored but I am not sure when that is comming.

Link to comment
Share on other sites

Killface69
On 1/9/2024 at 11:06 PM, TeamB said:

what database is it using? how do you get access to the database?

If you are looking to just back up your chapters in Emby then I think that is comming at some point. Team emby said they want to have chapters backed up and restored but I am not sure when that is comming.

I have no idea about the database specifics, only that it's hosted online, once you register within the app, you'll have access via an API for searching/uploading/downloading. Haven't talked to the author as I had no need for support yet.

What bothers me are auto chapters in fixed intervals and unnamed chapters. cE offers a good solution for single files to import either chapter titles or all info, but isn't suited for mass import.

Link to comment
Share on other sites

  • 4 weeks later...
joshinils

I wanted to go through a tv series and add a pair of IntroStart and IntroEnd for the "previously on" segment at the start of each episode. They are of varying length, but the second chapter in the file coincides with the end of the "previously on".

 

So I went ahead and added an IntroStart type chapter at 0 and an IntroEnd type at the same time of the second chapter.

Works perfectly, so far so good.

But there is also a short (about 4 seconds) intro in this show, after I added a second pair of IntroStart and IntroEnd for the actual intro only those were displaying the skip button, not the much longer previously-on at the start of the episode.

 

Does this not work with adding multiple intros?

Can I somehow add chapters to skip all previously-on segments on all episodes? All with the end at the second chapter?

I know I could write a bash script using FFmpeg to extract all chapters into metadata files, then edit those semi-manually (or with a bit of fiddling and Python automatically) to add the 0th chapter and copy the second and give them the names "IntroStart" and "IntroEnd". Would that even work? Or would the type be chapter instead of IntroEnd/Start meaning they are not recognized as such?

 

Assuming two pairs of intros are possible, I could also use the third chapter, since that seems to mark the end of the short actual intro. Assuming a fixed length for that, subtract and insert it as start chapter, copy the third as end.

Link to comment
Share on other sites

TeamB
2 hours ago, joshinils said:

Does this not work with adding multiple intros?

no, the assumption is that a show has one intro.

I think playback clients also assume this.

  • Agree 1
Link to comment
Share on other sites

rbjtech

So we had this idea on the very first Introskip Plugin but abandoned it soon after as it's manual effort vs the reward is simply not worth it.

If you did what to do it - there are a couple of options :-

a) Use that time to simply remove the 'previously on' segment from the source video in the first place.    It only really has it's place on broadcast TV - nobody wants to watch a 'previously on' from a episode they watched 30 seconds ago...

b) Trick emby into thinking its a commercial, and use commskipper to skip it that way. 

Emby does actually have the ability to add hidden marker types which 'could' be used for this sort of thing - we even floated the idea to add them - but without client support, the idea is dead in the water.   

Being brutally honest, the Introskip feature in the core has pretty much been abandoned since its bare bones implementation - thus not even having an editor - this great plugin from TeamB covers that gap - but there are many more features missing vs the original Introskip Plugin... :(

Link to comment
Share on other sites

crusher11

Why can't development resume on the plug-in? It was abandoned as redundant but it clearly isn't.

Link to comment
Share on other sites

rbjtech
2 minutes ago, crusher11 said:

Why can't development resume on the plug-in? It was abandoned as redundant but it clearly isn't.

As far as I am aware, the Plugin Dev's involved are no longer active in this space, or they certainly are not interested in opening that wound again...

  • Sad 1
Link to comment
Share on other sites

rbjtech
1 hour ago, l4kr411 said:

So... how do I lock intro data?

You can't lock chapter info unfortunately.

Link to comment
Share on other sites

TeamB
On 2/9/2024 at 9:33 PM, rbjtech said:

As far as I am aware, the Plugin Dev's involved are no longer active in this space, or they certainly are not interested in opening that wound again...

its disappointing it was not an open source project, a lot of community sourced info and research went into that plugin, its a pity it ended the way it did.

Edited by TeamB
  • Sad 1
  • Agree 1
Link to comment
Share on other sites

samuelqwe
15 minutes ago, TeamB said:

its disappointing it was not an open source project, a lot of community sources info and research went into that plugin, its a pity it ended the way it did.

I will say it actually started out that way before we decided to make the repo to private for a variety of reasons. Nowadays, we probably could open-source the code, but sadly I don't think that's ever gonna happen.

Link to comment
Share on other sites

samuelqwe

I also want to add that we also originally planned to keep the plugin alive after Intro Skip was natively implemented in Emby, but we were repeatedly told by the Emby Devs that they were gonna add some of the features the plugin would've had and that working on it would be a waste of time.

Link to comment
Share on other sites

TeamB
32 minutes ago, samuelqwe said:

I will say it actually started out that way before we decided to make the repo to private for a variety of reasons.

can I ask what reasons?

32 minutes ago, samuelqwe said:

Nowadays, we probably could open-source the code, but sadly I don't think that's ever gonna happen.

again, why?

26 minutes ago, samuelqwe said:

I also want to add that we also originally planned to keep the plugin alive after Intro Skip was natively implemented in Emby, but we were repeatedly told by the Emby Devs that they were gonna add some of the features the plugin would've had and that working on it would be a waste of time.

I was also told this plugin (ChapterAPI) was a waste of time, that chapter editing was coming "soon" to core, now years later it is still the only option, even if chapter editing was added to the core I still think users deserve and prefer to have multiple options and alternatives.

Edited by TeamB
Link to comment
Share on other sites

samuelqwe
29 minutes ago, TeamB said:

can I ask what reasons?

If I remember correctly, the main reason was that we didn’t want Jellyfin to take the code before this had any chance to be implemented in Emby. There were other reasons, but at the time that was the main concern.

 

1 hour ago, samuelqwe said:

Nowadays, we probably could open-source the code, but sadly I don't think that's ever gonna happen.

29 minutes ago, TeamB said:

again, why?

Well, for one, I don’t have the permissions to change the visibility of the repo, but even if I did, I wouldn’t feel comfortable releasing the source code unless the main devs involved also agreed.

 

32 minutes ago, TeamB said:

I was also told this plugin (ChapterAPI) was a waste of time, that chapter editing was coming "soon" to core, now years later it is still the only option, even if chapter editing was added to the core I still think users deserve and prefer to have multiple options and alternatives.

Marker editing would’ve have been one of the features we also would’ve had, as the original plugin essentially already did this.

I do agree that alternatives are good to have and that users should have multiple options, though we never picked development back up since we all eventually got busy and the whole situation really didn’t motivate us to keep working on the project.

Link to comment
Share on other sites

TeamB
Just now, samuelqwe said:

If I remember correctly, the main reason was that we didn’t want Jellyfin to take the code before this had any chance to be implemented in Emby. There were other reasons, but at the time that was the main concern.

There is so much concern and energy put into what other teams and projects are doing in this community.

Some of the devs working on that project are good, they could reverse engineer that plugin in a few hours, not having the source would slow them down about 10 min.

4 minutes ago, samuelqwe said:

Well, for one, I don’t have the permissions to change the visibility of the repo, but even if I did, I wouldn’t feel comfortable releasing the source code unless the main devs involved also agreed.

Absolutely agree, the original devs hold the power on this, it is their code and their work, a lot of community sourced testing, suggestions and feedback went into the plugin but the code is still controlled by the authors.

It's just disappointing when projects like that just disappear cos they were not open to begin with and the original devs step out, the work that went into it also just disappears.

8 minutes ago, samuelqwe said:

and the whole situation really didn’t motivate us to keep working on the project.

can you elaborate on this?

 

Link to comment
Share on other sites

samuelqwe
1 hour ago, TeamB said:

Some of the devs working on that project are good, they could reverse engineer that plugin in a few hours, not having the source would slow them down about 10 min.

I don’t doubt that. It’s not like we were doing anything particularly new and innovative, but we had worked hard on getting to where we were and we felt we had to protect it for a bit longer. That’s pretty much it.

2 hours ago, samuelqwe said:

the whole situation really didn’t motivate us to keep working on the project.

2 hours ago, TeamB said:

can you elaborate on this?

I was referring to the way things went down when Intro Skip was integrated into Emby.

Essentially, we were all happy to see the feature natively implemented. It was the first version and it was a very basic implementation, but we expected that. We then made suggestions, were told improvements were coming, and those improvements never came. Alright, we’ll just keep working on our plugin in the meantime and use it to fill in the gaps, we thought. But then anytime we suggested doing that, we kept getting told it was a waste of time and that the improvements would be coming soon, and they were telling people to uninstall and stop using our plugin.

Seems like they don’t want us working on this. Fine. I guess we won’t…

I don’t think the Emby developers had any bad intentions, but we didn’t really like how this was being handled, and had little motivation to pick the project back up.

  • Like 1
  • Sad 1
Link to comment
Share on other sites

TeamB
5 minutes ago, samuelqwe said:

and we felt we had to protect it for a bit longer. That’s pretty much it.

But that is fundamentally the difference in an open project, you want to share your work with everyone, regardless of the project, it is how open projects work. If you have that open project vibe you are happy to share your thoughts, ideas and research with everyone, that is how I treat all my plugins and projects, a number of them have been used in other projects like Jellyfin, its cool, that is what I did the work for, its open so everyone (the whole media sharing community) regardless of project gets to benefit.

Do I agree with everything all the other projects do, no not all the time, but people should have alternatives, a single solution ecosystem is just bad for everyone.

11 minutes ago, samuelqwe said:

We then made suggestions, were told improvements were coming, and those improvements never came.

For most uses this is just a checkbox on the feature list of the product and that is ok. For some they want power options to fine tune this and that is also ok. Emby is going to in most cases supply the MVP (minimum viable product), they just don't have the man power to do anything else.

Emby is trying to give the broadest users in their customer base that check box, and they do that reasonably well.

16 minutes ago, samuelqwe said:

Alright, we’ll just keep working on our plugin in the meantime and use it to fill in the gaps, we thought. But then anytime we suggested doing that, we kept getting told it was a waste of time

If you are enjoying the work and users find it useful, then it is never a waste of time. This all come back to what motivates you to do the work in the first place.

1. If it is because you enjoy the work and want to help the wider community, then keep doing the work, it is never a waste of time.

2. If it is because you want to help the Emby team build a better product and beat all the competitors and the Emby team is telling you not to do the work, then yeah, stop doing the work.

I am all about 1.

While I want Emby to succeed and will help with that, that is why I am here and not elsewhere, I also like building shit and the shit I build generally helps the media sharing community.

 

 

  • Like 1
Link to comment
Share on other sites

samuelqwe
1 hour ago, TeamB said:

But that is fundamentally the difference in an open project, you want to share your work with everyone, regardless of the project, it is how open projects work.

I’ll admit, I didn’t really think about that at the time.

Although I was involved in the project since the very beginning, I did not write the plugin. I wasn’t the only one involved in the decision to go closed-source. I cannot change the fact that we decided that, at the time, going closed-source was the way to go for the project.

2 hours ago, TeamB said:

Emby is going to in most cases supply the MVP (minimum viable product), they just don't have the man power to do anything else.

Right, I don’t think we ever expected Emby to add everything the plugin does, that would be unrealistic. I am happy we even got the feature at all, though there is always room for improvement.

2 hours ago, TeamB said:

If you are enjoying the work and users find it useful, then it is never a waste of time. This all come back to what motivates you to do the work in the first place

As I said earlier, and I can only speak for myself, my mentality at the time was more in line with the second scenario you described above. I wanted to see the feature in Emby and it eventually got there. I didn’t really think about it beyond that.

2 hours ago, TeamB said:

While I want Emby to succeed and will help with that, that is why I am here and not elsewhere, I also like building shit and the shit I build generally helps the media sharing community

Thanks for all the work you do! Chapter Editor is very useful :)

  • Like 1
Link to comment
Share on other sites

rbjtech

In agreement with everything @samuelqwesaid above.   

Maybe ask @chefif he wants to change the private repo to public - but in it's current state, some elements of the plugin are broken - and many sticking plasters have been added to make it work as integration to use the clients 'skip' was added after that got implemented (actually @Cheesegeezerwrote that bit) - and tbh was one of the main reasons why development stopped as we were told this was breaking things (which it wasn't..).   

I still use the Plugin today rather than the Core as frankly the Plugin still works better for me, but for how much longer I'm not sure.  

Emby need to finish what they started - no ability to change/lock the data, no editing, no credits, no exclude, no ignore episode 1 intro skip, no permission based skip, no proper intro naming/labelling, no stats etc     

The MVP attitude is a little sad - we were proud to be better than Plex at the time - with all the features we added (the main one being Credits) - now emby is sadly lacking the competitors in this area, as well as many others such as transcoding DV etc where once it was at the forefront.. :(    We should not be 'catching up - we should be innovating...

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

chef

Which repo needs to be public? 

 

Every single plugin I ever wrote is broken. 😆

  • Haha 1
Link to comment
Share on other sites

rbjtech
19 minutes ago, chef said:

Which repo needs to be public? 

 

Every single plugin I ever wrote is broken. 😆

image.png.3ed1148966ccc765eaf1de37dfe8fd7b.png

chefbennyj1/Emby.IntroSkip: use chroma-print technology to find episode title sequence start and end times. (github.com)

edit - Adding @Cheesegeezer- Some of this is his code too ..

Edited by rbjtech
Link to comment
Share on other sites

samuelqwe
7 minutes ago, chef said:

Which repo needs to be public?

In this case, we were discussing about making the source code for the Intro Skip plugin public. I don’t see any reason why we shouldn’t.

  • Agree 1
Link to comment
Share on other sites

chef

Because the core devs used so e of our code for internal intro skip.

If they say they dont care. 

One of the community members already sourced and posted intro skip code publicly anyway.

It doesn't matter to me. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...