Completed Show Intro Skip Option

[Banquero 30]

29 minutes ago, tchirou said:

Personally, the lack of this feature made me switch to plex with a broken heart after 5 years of Emby and a lifetime license. But for tv shows, skipping intros is mandatory once you are used to it.

Yo creo que deben de avanzar en unificar todas las app de Emby para que sean iguales en todas las plataformas, porque las diferencias son muchas y que algunas caracteristicas como estas queden implementadas en la app del servidor para poder competir con otras aplicaciones de streaming como nextflix, y demás...Saludos...

[vittsof 2]

Hello there. I read some of your thoughts on how intro detection is accomplished on plex. As far as I know Plex compares the first minutes between the episodes and notes the points where the sound is the same. There is minimum intro length it detects. I don't know if it was mentioned before and I hope this will help your developers.

[samuelqwe 313]

3 hours ago, vittsof said:

As far as I know Plex compares the first minutes between the episodes and notes the points where the sound is the same.

This is the exact technique @chefis using currently using in his proof of concept plugin.

3 hours ago, vittsof said:

There is minimum intro length it detects.

They do in fact have a minimum intro length of 20 seconds, which is something that is also taken into account in the plugin.

As you can tell, we essentially have a functional intro detection plugin, but those detected intros can’t currently be skipped since plugins don’t have access to the video player to do that. So, it’s just a matter of if the Emby developers will implement it or not.

[rbjtech 4254]

I think it would be good to release this plugin beyond just a proof of concept by having it create and tag(name) a chapter point after the intro.  

Skipping the intro (on devices that support chapters..) is then just a case of 'skip' to the next chapter.

It would also be a good time to thoroughly test it outside the limited testing during the PoC - leave it as a Beta for sure - but I'd love to have the ability to create these chapter points on my TV collections 

Edited April 23, 2021 by rbjtech

[samuelqwe 313]

34 minutes ago, rbjtech said:

I think it would be good to release this plugin beyond just a proof of concept by having it create and tag(name) a chapter point after the intro.  

Skipping the intro (on devices that support chapters..) is then just a case of 'skip' to the next chapter.

I think for the moment we wanted to avoid modifying video files and adding chapters since we’re still unsure of the accuracy of the detection. It has worked pretty well in our testing, but that’s a relatively small sample size. However, it should be possible to provide a “chapters” file that could then be manually muxed in with a video.

41 minutes ago, rbjtech said:

It would also be a good time to thoroughly test it outside the limited testing during the PoC - leave it as a Beta for sure - but I'd love to have the ability to create these chapter points on my TV collections 

Agreed, and while you can already grab the plugin and test it (there were some links posted on this topic somewhere), I think there are changes that need be made to the plugin to simplify the process a little bit before we can tell people to really test it.

Hopefully @chef can continue his work on the plugin soon, when he becomes less busy. 

[rbjtech 4254]

5 minutes ago, samuelqwe said:

 However, it should be possible to provide a “chapters” file that could then be manually muxed in with a video.

Yep - a chapters.xml file should be a trivial task - when I played with the plugin - I did some hacking myself on this to see how easy it is to add and had reasonable success by just importing the XML at the command line using mkvtoolnix  - adding to existing chapters might need a bit of thought however as it needs to extract, add the intro chapter and re-import - there is no 'append'.

5 minutes ago, samuelqwe said:

Hopefully @chef can continue his work on the plugin soon, when he becomes less busy. 

Yep - too busy building out his basement to worry about coding .. can't he do this while the paint is drying or something ?! 

[TeamB 2352]

I was going to have a look at this again when the chromaprint thumb printing algorithm that was added to the Emby 4.6 beta (ffmpeg inbuilt muxer) is released.

At the moment the plugin needs to ship with the command line tool for multiple platforms to extract the chromaprint but when Emby 4.6 is released the plugin can use the shipped ffmpeg to generate the audio thumb prints.

I have no idea when the 4.6 beta will ship, its been months and months, no idea what the time frame for that is, I think that is why the plugin lost of lot of momentum.

Also there will be shows that this just does not work for, some it will work great with and others it is just going to flop on.

Edited April 23, 2021 by TeamB

[chef 3745]

On 4/23/2021 at 7:04 PM, TeamB said:

I was going to have a look at this again when the chromaprint thumb printing algorithm that was added to the Emby 4.6 beta (ffmpeg inbuilt muxer) is released.

At the moment the plugin needs to ship with the command line tool for multiple platforms to extract the chromaprint but when Emby 4.6 is released the plugin can use the shipped ffmpeg to generate the audio thumb prints.

I have no idea when the 4.6 beta will ship, its been months and months, no idea what the time frame for that is, I think that is why the plugin lost of lot of momentum.

Also there will be shows that this just does not work for, some it will work great with and others it is just going to flop on.

I will put a version on GitHub that I have with an editor. I wasn't entirely sure how to handle the episodes that would flop.

Perhaps, in the future, we could create a file share that would add JSON episode data for known title sequences that are un-scan-able. 

 

Unfortunately, I started a home improvement project, that was bigger then I thought it would be, and now I'm working diligently to finish it before my wife kills me .  

 

[rbjtech 4254]

On 25/04/2021 at 13:25, chef said:

Unfortunately, I started a home improvement project, that was bigger then I thought it would be, and now I'm working diligently to finish it before my wife kills me .  

Been there .. 'it'll only be a few hours..' 

Edited April 26, 2021 by rbjtech

[Sammy 735]

On 4/25/2021 at 5:25 AM, chef said:

I will put a version on GitHub that I have with an editor. I wasn't entirely sure how to handle the episodes that would flop.

Perhaps, in the future, we could create a file share that would add JSON episode data for known title sequences that are un-scan-able. 

 

Unfortunately, I started a home improvement project, that was bigger then I thought it would be, and now I'm working diligently to finish it before my wife kills me .  

 

And are you cooking again too?

[CloudWing93 26]

On 5/20/2020 at 3:37 PM, ebr said:

Has anyone actually tried it or just going from their marketing announcement?

I have used it and it actually works very well. It doesn’t always find the intro but if it does it displays the skip intro button. I’d say it successfully found the intros of about 95% of the shows that had them. While I was using it before I switched to Emby I never ran into an episode where the detected intro was in the wrong spot.

[Micael456 43]

Honestly, while Chapter points may make for good portability, I'd argue the best location to store the "inro segments" would be a section of the metadata database (though this is probably out of bounds right now). It would then also allow us to easily go in and modify, or even "train" the algorigthm by saying XXX-YYY is an intro, go find the rest.

Another thought struck me; there's also TV shows which have different intros as seasons go on- e.g. Star Trek DS9/ Enterprise with the newer-tempo later seasons, and Enterprise's Mirror Episode intros. It would need to be able to search for an intro out of the possible intros.

 

As for Chef's home improvement, I feel that pain. "Just have to swap out this wobbly backbox" turned into "Oh FFS there's just a hole here and that's the underside of the bath tub" to "Well I guess we're gonna need to repaint that whole wall." 

Edited April 29, 2021 by Micael456

[samuelqwe 313]

6 minutes ago, Micael456 said:

Honestly, while Chapter points may make for good portability, I'd argue the best location to store the "inro segments" would be a section of the metadata database (though this is probably out of bounds right now). It would then also allow us to easily go in and modify, or even "train" the algorigthm by saying XXX-YYY is an intro, go find the rest.

Of course, if this were an actually feature within Emby that’s how it would likely be done. Chapters were just proposed as an interim solution since there’s no other good way we can integrate the functionality for the moment within our plugin.

8 minutes ago, Micael456 said:

Another thought struck me; there's also TV shows which have different intros as seasons go on- e.g. Star Trek DS9/ Enterprise with the newer-tempo later seasons, and Enterprise's Mirror Episode intros. It would need to be able to search for an intro out of the possible intros.

The currently proposed solution would account for this as long as there are at least two episodes with the same intro in the season, since we’re already only comparing episodes within the same season. So, for example, an intro could change mid-season and it would still be detected just fine. 

[rbjtech 4254]

I would argue that chapter points are the obvious place to store them..

As long as the chapter 'Name' is kept consistent within the media file itself - then I really don't see why you would want to keep this exclusively elsewhere ?  What benefit does this serve, other than making it less portable and tied into the emby database ? 

If you write them into the media file (assuming it supports them of course) then all the other media applications can use them - DLNA, Kodi, VLC etc

Writing a new set of chapters to a MKV is trivial - you just have to modify the header, you do not need to write the entire file.

Maybe read these chapter points, and store them in the DB as extra fields if you like - and modifying them will write them back to media -  but please don't make this a closed system ...

[samuelqwe 313]

42 minutes ago, rbjtech said:

I would argue that chapter points are the obvious place to store them..

As long as the chapter 'Name' is kept consistent within the media file itself - then I really don't see why you would want to keep this exclusively elsewhere ?  What benefit does this serve, other than making it less portable and tied into the emby database ? 

If you write them into the media file (assuming it supports them of course) then all the other media applications can use them - DLNA, Kodi, VLC etc

Writing a new set of chapters to a MKV is trivial - you just have to modify the header, you do not need to write the entire file.

Maybe read these chapter points, and store them in the DB as extra fields if you like - and modifying them will write them back to media -  but please don't make this a closed system ...

The problem with relying on chapters is that it’s a "permanent" solution. What I mean is that once they’re in there, Emby can’t really take them out or change them since it doesn’t know with certainty which chapters are the added intro points other than by their name. So you have to hope the detection goes right, because relying solely on the name of the chapters is a bad idea.

Also, not to mention the fact that I think people generally don’t want Emby modifying their files, since you never know if something could go wrong, even with simple operations like this.

Though, I definitely agree that this shouldn’t be a closed system, but I think that the safest approach should be taken here.

Then again, I’m not the Emby devs, so it would ultimately be up to them to decide how they would implement such a feature as intro skipping.

Edited April 29, 2021 by samuelqwe

[chef 3745]

On 4/26/2021 at 8:48 AM, Sammy said:

And are you cooking again too?

Sort of... Nothing like it was.  Everything keeps shutting down where I am, and the schools are closed, so I've been home schooling... Which is the worst.

[Sammy 735]

28 minutes ago, chef said:

Sort of... Nothing like it was.  Everything keeps shutting down where I am, and the schools are closed, so I've been home schooling... Which is the worst.

We'll get there.. Everything is getting back to normal in California but masks are still required. Numbers continue to fall as more people get vaccinated but that program is stalling like a Brisket at 150 as everyone that wants one has it already and there's a lot of hesitation so we're not getting close to 80% yet..

Edited April 29, 2021 by Sammy

[Dibbes 431]

10 hours ago, chef said:

Sort of... Nothing like it was.  Everything keeps shutting down where I am, and the schools are closed, so I've been home schooling... Which is the worst.

it's one of the reasons I haven't had time to do anything... homeschooling two boys under 7 years old is very exhausting...

[Banquero 30]

Buenas tardes  ya tenemos la version 4.6.1.0 estable para Emby..Este plugin es casi una "necesidad" para esta plataforma...Se ha probado? Funciona? Está en desarrollo? Lo espero con mucha ansia...Muchas gracias por vuestro trabajo...Saludos...

[Justus 7]

A quick question what the current status of the project is at the moment?

[Luke 37049]

6 minutes ago, Justus said:

A quick question what the current status of the project is at the moment?

HI, it's planned for a future release. Thanks.

[chef 3745]

20 minutes ago, Luke said:

HI, it's planned for a future release. Thanks.

That's awesome news

 @samuelqwe

[samuelqwe 313]

1 hour ago, chef said:

That's awesome news

 @samuelqwe

It is indeed!

Looking forward to seeing this feature implemented, @Luke!

[GiGo 103]

While I wait for this amazing idea for an intro skip to become live. Has anyone considered how to match many videos that could be easier than just scanning the files? Lets be honest and admit that a lot of files that pople use Emby for can be obtained from the internet and can have a MD5 hash tag assigned to them, has this been consdiered?

A file is scanned on a users emby system, an MD5 tag is assigned, the user then confirms that the intro skip option has worked, this MD5 tag can then be stored somewhere then when someone else comes to scan a similar title an option to scan the MD5 tag can be put to the user to check against other MD5's on a central database?

I realise this in thoery could hold an issue for piracy and could basically give a big list of users that have then same file, but lets be honest it happens. Could this be an easier and quicker solution than scanning people entire collections?

Forgive me if this has been discused already but I couldn't find it in the thread.

[Micael456 43]

25 minutes ago, GiGo said:

I realise this in thoery could hold an issue for piracy and could basically give a big list of users that have then same file, but lets be honest it happens. Could this be an easier and quicker solution than scanning people entire collections?

I think this is the key line here. It makes it easier to pirate, and (imo) crosses the line to actively supporting piracy.

 

If, like myself, you use Emby with personal rips and toss the DVDs in the attic (which is what officially speaking you're meant to do), chances are that our md5 hashes will not match. Now, sure, in theory if we both ripped Stargate Atlantis S01e01&2 with the identical settings in MakeMKV and Handbrake, then they might match. But realistically speaking there'd be hundreds (thousands) of potential md5 hashes as everyone has their own setting combos/ app versions/ etc when they rip). Some people would statistically have the same file, most wouldn't. So there'd have to be a huge hashtable somewhere centralised, which wouldn't necessarily be quicker to search, or easy to transfer, and would force you to be connected to the 'net.  Processing files locally may take a little longer, but it's a reliable local solution.

 

The only place it would be guaranteed to be quicker is on episodes that were, *ahem*, acquired off the internet. And if you're creating a feature that just improves the life for pirates (vs. just scanning), then that's saying Emby is a place for pirates. I quite like emby, I'd rather they didn't get hit by lawyers.

 

 

tldr; supports piracy, doesn't offer legit advantages, imo.