Jump to content

Show Intro Skip Option


Liquidfire88

Recommended Posts

Cheesegeezer
13 minutes ago, rbjtech said:

Any reason why this value would be missing in the first place ?

Forcing a metadata refresh just to get this value seems a tad extreme and may overwrite peoples changes if they have not locked the metadata - if it's just the show runtime, then could we not ask emby to get it via an API call ?

Sure we can, it would be returned in the itemDTO model.  but we need it so what do we do stack a list of episodes that are not populated with runtime during the FP task and force a refresh .anyway

Link to comment
Share on other sites

I'm good either way. Running the meta task before ours is probabaly okay, as long as the users don't accidentally have the option which swaps out their images on them enabled.

Then we be causing that to happen.

 

Link to comment
Share on other sites

Cheese can we add these items without runtime data to our stats somehow? 

Like if the detection algorithm, held a list of items that failed for this reason?

It's extra memory, I dunno.

What'd'ya think?

Link to comment
Share on other sites

Cheesegeezer
10 minutes ago, chef said:

Cheese can we add these items without runtime data to our stats somehow? 

Like if the detection algorithm, held a list of items that failed for this reason?

It's extra memory, I dunno.

What'd'ya think?

 

This will be easy enough.  the query is running anyway so it's nothing extra for the stats taske.

 

the stats are based on what id's we have in our database and forms the query.  we can add a counter to say how many episodes in a season don't have runtimes or have a percentage, if this correlates to the percentage of episodes with an issue.... we know what the problem is.

 

Edited by Cheesegeezer
  • Like 1
Link to comment
Share on other sites

Cheesegeezer

updated the other thread with the latest version.

More details here.  Please follow the other thread for any updates on builds

 

  • Like 1
Link to comment
Share on other sites

fbrassin
3 hours ago, rbjtech said:

 

@fbrassin - Just copy the DLL over the existing one, and restart emby.  Do NOT delete the titlesequence.db file !

Re-run the FP and Detect tasks - if it runs through very quickly, then this is not the issue, but if it stops part of the way through, then it is picking up items it missed during the FP and/or Detect.  Once complete, hopefully your results match mine. 👍

Just sent you embyserver log in PM

  • Thanks 1
Link to comment
Share on other sites

Painkiller8818
On 11/17/2021 at 12:02 AM, chef said:

 The plugin or the actual skip button?

the plugin

Link to comment
Share on other sites

Cheesegeezer
1 minute ago, Painkiller8818 said:

the plugin

we are very close, just need to wrap up some bug issues.

 

  • Like 2
Link to comment
Share on other sites

fallenwitch3r

@Cheesegeezer did you mean the implementation of the skip button to the emby core?

I did a complete rescan with the latest build. The maximum series to chromaprint at once is set to 6.

The maximum series to attempt intro detection at once is set to 4

Fast detection is off

My low end CPU had a heavy load with this settings.

Episode audio fingerprinting took around 13h.

Episode title sequence detection took around 8h

Introskip Chapter insertion took around 1h

The accuracy is still reall good. The reason why I do a rescan is because the older build was stopping sequence detection after every season. 

The last title sequence detection with the new version works fine without any breakups.

 

Edited by fallenwitch3r
  • Thanks 2
Link to comment
Share on other sites

rbjtech
16 minutes ago, fallenwitch3r said:

@Cheesegeezer did you mean the implementation of the skip button to the emby core?

I did a complete rescan with the latest build. The maximum series to chromaprint at once is set to 6.

The maximum series to attempt intro detection at once is set to 4

Fast detection is off

My low end CPU had a heavy load with this settings.

Episode audio fingerprinting took around 13h.

Episode title sequence detection took around 8h

Introskip Chapter insertion took around 1h

The accuracy is still reall good. The reason why I do a rescan is because the older build was stopping sequence detection after every season. 

The last title sequence detection with the new version works fine without any breakups.

 

Thanks for the update and feedback on the settings.

With a low end CPU/NAS we would recommend using 2 for Fingerprint and 2 for Detect - the default settings - especially if the system is in active use.  6 is brave ! I expect your storage got a good workout with those settings - haha.

Fingerprint is very disk I/O dependent while Detect is very CPU intensive (it's analysing the FingerPrint data).

Link to comment
Share on other sites

fallenwitch3r
1 hour ago, rbjtech said:

With a low end CPU/NAS we would recommend using 2 for Fingerprint and 2 for Detect - the default settings - especially if the system is in active use.  6 is brave ! I expect your storage got a good workout with those settings - haha.

Fingerprint is very disk I/O dependent while Detect is very CPU intensive (it's analysing the FingerPrint data).

Yes i know that but my system was not in use during this time and yes, the load on the cpu was heavy but the result is good. I cant wait to see the Skip button :)

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

FrostyCoolSlug

Hi there, firstly, awesome work on the plugin!

I've been running the plugin across my library and checking for any problems, I've noticed an intro detection 'miss' in Star Trek: The Original Series for Season 1 Episode 13. It's flagged the intro as occurring at 00:00, instead of around 04:23..

Fast Detection is off, and confidence is at the default 0.6, everything else in the season seems to have been detected properly (screenshot below).

image.thumb.png.f1ea34105eac7c75f6d6e264e8f7a401.png

 

Happy to send logs across if needed (let me know which ones please!) if you're unable to verify this yourselves.

[EDIT] Log Output:

Quote

2021-11-19 06:08:56.208 Debug Intro Skip: Star Trek Season 1 Episode 13:
Credit sequence audio detection start: 00:58:03.5230000.
No black frame detected within contiguous regions.
2021-11-19 06:08:56.208 Debug Intro Skip: 
DETECTION processed 29 compared items for Star Trek Season 1 Episode 13.
Best result: Star Trek - Season 1 Episode 13 
TITLE SEQUENCE START: 00:00:00 
TITLE SEQUENCE END: 00:00:51 
CREDIT START: 00:58:03.5230000
CREDIT END: 00:59:27.5230000
CREDIT CONFIDENCE: 1.29
TITLE SEQUENCE CONFIDENCE: 1

 

Cheers.

 

Edited by FrostyCoolSlug
  • Thanks 1
Link to comment
Share on other sites

rbjtech
4 hours ago, FrostyCoolSlug said:

Hi there, firstly, awesome work on the plugin!

I've been running the plugin across my library and checking for any problems, I've noticed an intro detection 'miss' in Star Trek: The Original Series for Season 1 Episode 13. It's flagged the intro as occurring at 00:00, instead of around 04:23..

Fast Detection is off, and confidence is at the default 0.6, everything else in the season seems to have been detected properly (screenshot below).

image.thumb.png.f1ea34105eac7c75f6d6e264e8f7a401.png

 

Happy to send logs across if needed (let me know which ones please!) if you're unable to verify this yourselves.

[EDIT] Log Output:

 

Cheers.

 

Hi - thanks for the feedback.

You may not be aware (we need to make this more obvious..) but you can directly add/edit any of the times listed under the thumbnails by overtyping the time - and then hit the 'Save' button on the right.

For one off's such as this - then there is 'something' (inaudible to you and I) that is off with that audio - thus it is not being matched to anything else - so a manual edit, is likely the only way to correct it I'm afraid.

I need to confirm what happens after you make the correction, I believe it re-runs the chapter insertion with your corrected data.. - brb.

update - so any corrected time data is saved but the chapter info is not being updated even after manually running the chapter/thumb task.  You may have discovered a bug (or something we forget to add lol).  Thanks - We'll need to look at this.. 👍 

@chef @Cheesegeezer - I'll ping you in the PM chat - I've done some quick testing on this.

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

Just updated the server to .18 and the plugin to .22 but now the dashboard shows the plugin with version "0.0.0.0":

image.png.20c99701241b9579ef6394955dc7cbd7.png

Anyone else seeing this?
Is it "safe" to fingerprint, in the sense that I get proper data?

  • Thanks 1
Link to comment
Share on other sites

rbjtech
10 minutes ago, neik said:

Just updated the server to .18 and the plugin to .22 but now the dashboard shows the plugin with version "0.0.0.0":

image.png.20c99701241b9579ef6394955dc7cbd7.png

Anyone else seeing this?
Is it "safe" to fingerprint, in the sense that I get proper data?

Ah yes, the version has not been updated internally but is safe to use - thanks.

Capture.PNG.bed2fce61cfec676d8ba915cebc35c77.PNG

  • Like 2
Link to comment
Share on other sites

BaukeZwart

My docker container updated to 4.7.0.18 beta and I don't know if it's reated to the upgrade but I lost thumbs for all episodes.
Any idea what going on here?
I tried both Chrome and Edge.
Could it be the thumbs are saved in the container it self, and not in the mapped config folder. That would explain why they are lost after an update.
 

chrome_rqEF6qHTJ2.png

Edited by BaukeZwart
  • Thanks 1
Link to comment
Share on other sites

Cheesegeezer
20 minutes ago, BaukeZwart said:

My docker container updated to 4.7.0.18 beta and I don't know if it's reated to the upgrade but I lost thumbs for all episodes.
Any idea what going on here?
I tried both Chrome and Edge.
Could it be the thumbs are saved in the container it self, and not in the mapped config folder. That would explain why they are lost after an update.
 

chrome_rqEF6qHTJ2.png

the release notes state that ffmpeg was updated to 4.5

Let me check on my test system.

 

  • Like 1
Link to comment
Share on other sites

BaukeZwart
9 minutes ago, neik said:

If you haven't tried to clear your cache I would do that and retry.

Makes no difference, added a new episode (E10), also no thumbs.

chrome_7vMq4DrnGt.png

Edited by BaukeZwart
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, BaukeZwart said:

My docker container updated to 4.7.0.18 beta and I don't know if it's reated to the upgrade but I lost thumbs for all episodes.
Any idea what going on here?
I tried both Chrome and Edge.
Could it be the thumbs are saved in the container it self, and not in the mapped config folder. That would explain why they are lost after an update.
 

chrome_rqEF6qHTJ2.png

Oh, that's interesting. 🤔

Wonder what's happening there?

We are extracting thumb images on the fly.

If you open dev tools are you getting 404 messages for the image loading on the page?

Link to comment
Share on other sites

BaukeZwart

@chef getting this in console.
I also tried IP:port bypassing the reverse proxy, same output in console.

 

chrome_hjqYWkb1B0.png

Edited by BaukeZwart
  • Thanks 1
Link to comment
Share on other sites

1 minute ago, BaukeZwart said:

@chef getting this in console.

 

chrome_hjqYWkb1B0.png

Okay, let me just make sure my beta is the same version, check the API  and we'll brb!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...