Plugin: EmbyCredits, detect end credits and add auto skip.

[sydlexius 297]

35 minutes ago, yocker said:

OCR detection now supports much better Japanese detection. (Requires latest EmbyCredit tesseract docker!!).

This does indeed seem to be an improvement!  I've had a few stubborn series that I tried adding custom keywords to; sometimes it worked, some didn't.  For what it's worth, here's some keywords I've experimented with:

director
narration
original picture
painting
prop design
Released by
script
storyboard
ufotable
©
おわり
キャラクターデザイン
シリーズ構成
スタッフ
プロップデザイン
プロデューサー
主演
作画監督
制作委員会
協力
原作
原画
提供
撮影
撮影監督
無断転載を禁じます
絵コンテ・演出
編集
美術監督
美術設定

 

[yocker 1247]

Small fix uploaded to github.

Well i just made a fool of my self.
I had tested for hours last night getting audio fingerprinting to work but failing and ended up with the conclusion that the FFmpeg in Emby didn't support it.
Just found out i tested with the wrong ffmpeg commands. 

So i have quickly added this version with audio fingerprint as i originally intended.

Please note the settings are set rather conservative to avoid missing any end credits, they can in most cases be set much better and detections be made much faster as a result.
If you don't understand how it works then just leave it all as is and choose the preferred detection method.

@sydlexiusJust a poke because i see you already have downloaded the other version.

[Neminem 1518]

@sydlexiusThanks for the list of,  well to me foreign letters

Will come in use.

[yocker 1247]

I need some people to test a beta version.

I have changed the detection a bit, it should now be MUCH faster and more precise when using hash detection but i need more testing done with it.
Please note: that single episode detection is disabled when using hash detection, this is because it needs as many episodes as possible to do a comparison with.
It's well worth is it for the extra precision and speed, you will se!

WARNING!! WARNING!! WARNING!!
This is a beta and bugs might happen!

EmbyCredits.dll

[adamzetpl 2]

1 hour ago, yocker said:

I need some people to test a beta version.

I have changed the detection a bit, it should now be MUCH faster and more precise when using hash detection but i need more testing done with it.
Please note: that single episode detection is disabled when using hash detection, this is because it needs as many episodes as possible to do a comparison with.
It's well worth is it for the extra precision and speed, you will se!

WARNING!! WARNING!! WARNING!!
This is a beta and bugs might happen!

EmbyCredits.dll 807 kB · 1 download

For me this version is a lot faster compared to previous

[adamzetpl 2]

18 minutes ago, adamzetpl said:

For me this version is a lot faster compared to previous

I'm not sure if I found a bug or if it's something on my side. When I use the "Detect End Credits on TV Shows" schedule, it only shows X/Y. Y is the number of episodes in the season. It doesn't show all the episodes in the queue, and I have to refresh the plugin page after each season, or it seems like the plugin has no activity. When I refresh, it shows X/Y activity for the next season in the queue not all episodes in queue.

 

[yocker 1247]

3 hours ago, adamzetpl said:

I'm not sure if I found a bug or if it's something on my side. When I use the "Detect End Credits on TV Shows" schedule, it only shows X/Y. Y is the number of episodes in the season. It doesn't show all the episodes in the queue, and I have to refresh the plugin page after each season, or it seems like the plugin has no activity. When I refresh, it shows X/Y activity for the next season in the queue not all episodes in queue.

 

Will look into it.
Though for now it's just meant as a test of the detection to see if people like it more than the old one.  

Edited February 4 by yocker

[yocker 1247]

Hopefully last beta before release...

Improved the detection.

EmbyCredits.dll

[sydlexius 297]

10 hours ago, yocker said:

I need some people to test a beta version.

I have changed the detection a bit, it should now be MUCH faster and more precise when using hash detection but i need more testing done with it.
Please note: that single episode detection is disabled when using hash detection, this is because it needs as many episodes as possible to do a comparison with.
It's well worth is it for the extra precision and speed, you will se!

WARNING!! WARNING!! WARNING!!
This is a beta and bugs might happen!

EmbyCredits.dll 807 kB · 3 downloads

I can confirm the speed improvements as well.  Are there any specific settings you'd like to have tested in conjunction with this?

[yocker 1247]

2 minutes ago, sydlexius said:

I can confirm the speed improvements as well.  Are there any specific settings you'd like to have tested in conjunction with this?

I'd rather not say what i would like tested.
People tend to find bugs i would never had thought about on their own.  

[sydlexius 297]

Just a quick suggestion. Adding a manual timestamp in Season Batch Validation to a single episode kicks you out after applying. It would be my preference to allow as many CRUD operations as I'd like, and when I'm actually finished I can click the "close" button. 

[yocker 1247]

1 hour ago, sydlexius said:

Just a quick suggestion. Adding a manual timestamp in Season Batch Validation to a single episode kicks you out after applying. It would be my preference to allow as many CRUD operations as I'd like, and when I'm actually finished I can click the "close" button. 

Will be fixed in next version.

[yocker 1247]

New version out (v2.1.1.0) on yocksers/EmbyCredits Github.

Added:

1. Support for PaddleOCR. PaddleOCR supports GPU hardware acceleration with Nvidia GPUs for faster detection.
   Use: yock1/embycreditpaddle:latest as the docker container.
   Note: The container image is very big, will take 20GB+ after install.
   Instructions are in the setup guide of the plugin settings.
2. Option for anime specific detections, this is to improve detection for anime.

Changed:

1. Removed some irrelevant settings.
2. Cleaned up the settings.
3. Improve detections.

Fixed:

1. Small bug with episode comparison.
2. Minimum number of keywords come in some cases not be respected by the plugin.

---

PaddleOCR is a faste, more modern version of Tesseract and supports Nvidia GPUs.
There are cons to using it over the Tesseract. First of it's VERY large and takes 20GB+ of space.
Second It WILL take all your GPU if it can while scanning.

I don't know how to install it on Unraid with it using appdata cache, if any one can make a small guide for people i would very much appreciate it!

Important:
PaddleOCR is NOT mine and is from: PaddlePaddle/PaddleOCR:  Github.
All credit for PaddleOCR goes to them or who ever made it.

Special thanks to @Neminemfor helping with this plugin!

[Neminem 1518]

@yockerI made a quick and dirty unRaid guide in you github discussion.

To keep in there.

unRaid PaddleOCR setup guide. · yocksers/EmbyCredits · Discussion #5

[sydlexius 297]

@yockerIs there any possibility of configuring an always-on logging facility (complete with log directory)?  I've noticed that the plugin will hang after a few hundred episodes, but when I cancel, then run a single episode detection on the "problem child" it runs fine.  I suspect we may be dealing with some sort of memory leak, or zombie processes (I've set a limit of 450 seconds for detection timeout, but it's not being respected).  Running top in the Emby container shows that ffmpeg is doing something on the problematic episode, but it's not clear what:

 

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
1329799 1329782 99   S     390g195.2  10  0.0 /system/EmbyServer -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
1402608 1329799 99   SN   58012  0.0  14  0.0 /bin/ffmpeg -hide_banner -loglevel warning -ss 2139.735 -i /share/Rachel_TV/Chopped Junior/Season 04/Chopped.Junior.(2015).S04E08.Yay.H
1403036   0 root     R     1372  0.0  12  0.0 top
1329782 171 root     S     1368  0.0  25  0.0 sh ./run
  171     1 root     S      208  0.0  39  0.0 s6-supervise emby-server
   32     1 root     S      208  0.0  37  0.0 s6-supervise s6-fdholderd
    1     0 root     S      204  0.0  26  0.0 s6-svscan -t0 /var/run/s6/services

 

Additionally, even though that counter shows there are 450 failed episodes, the list of failed episodes falls far short of that number (it appears to stop after 200 entries).  If this is intentional behavior, then it probably won't match user expectation.  If this is done to improve page load times, then perhaps some sort of FIFO system should be used instead of truncating?  Or some sort of pagination?

 

Edited February 6 by sydlexius

[yocker 1247]

3 hours ago, sydlexius said:

@yockerIs there any possibility of configuring an always-on logging facility (complete with log directory)?  I've noticed that the plugin will hang after a few hundred episodes, but when I cancel, then run a single episode detection on the "problem child" it runs fine.  I suspect we may be dealing with some sort of memory leak, or zombie processes (I've set a limit of 450 seconds for detection timeout, but it's not being respected).  Running top in the Emby container shows that ffmpeg is doing something on the problematic episode, but it's not clear what:

 

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
1329799 1329782 99   S     390g195.2  10  0.0 /system/EmbyServer -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
1402608 1329799 99   SN   58012  0.0  14  0.0 /bin/ffmpeg -hide_banner -loglevel warning -ss 2139.735 -i /share/Rachel_TV/Chopped Junior/Season 04/Chopped.Junior.(2015).S04E08.Yay.H
1403036   0 root     R     1372  0.0  12  0.0 top
1329782 171 root     S     1368  0.0  25  0.0 sh ./run
  171     1 root     S      208  0.0  39  0.0 s6-supervise emby-server
   32     1 root     S      208  0.0  37  0.0 s6-supervise s6-fdholderd
    1     0 root     S      204  0.0  26  0.0 s6-svscan -t0 /var/run/s6/services

 

Additionally, even though that counter shows there are 450 failed episodes, the list of failed episodes falls far short of that number (it appears to stop after 200 entries).  If this is intentional behavior, then it probably won't match user expectation.  If this is done to improve page load times, then perhaps some sort of FIFO system should be used instead of truncating?  Or some sort of pagination?

 

I could maybe make some persistent log, though it might be a very niche thing.
I will look into it.

I can't replicate that but will look into it!

Many thanks for reporting!

[yocker 1247]

@sydlexiusactually, thinking about it.
Do you have thumbnails on? I put a limit of 200 of them to avoid exesive memory and disk usage.

[sydlexius 297]

45 minutes ago, yocker said:

@sydlexiusactually, thinking about it.
Do you have thumbnails on? I put a limit of 200 of them to avoid exesive memory and disk usage.

I do.  But I don't see thumbnails for Failed detections.

[yocker 1247]

30 minutes ago, sydlexius said:

I do.  But I don't see thumbnails for Failed detections.

Just another problem i might have identified. Nothing major.

Anyway, yes there is a limit on the failed episodes.
There might be people running with small computers so i have been very conservative (way to much maybe) with it. So it was hardcoded to 200, i have changed that to 5000 in the next version.

Will look into the logging also, should be no problem saving the already generated log to disk.
I might need to make them easier to read before that if users want to save and go through logs.

The hanging you noticed might be the start of a new season or black frame detection fallback being run.
I sadly can't make a propper progress bar for black frame so it might seem like it's hanging.
That said, i should add some (better) protection against that stuff and will look into that for next version.

You have given me some stuff to do.  

[sydlexius 297]

55 minutes ago, yocker said:

Anyway, yes there is a limit on the failed episodes.
There might be people running with small computers so i have been very conservative (way to much maybe) with it. So it was hardcoded to 200, i have changed that to 5000 in the next version.

Perhaps a future enhancement might include options like a historical tab (of both successful and failed detection), for which you could simply paginate your way through the entire history?  Further, a way to mark "failed" detections to never run again would be nice (as well as a "manual detection" option to ignore said markers <lol>).

[yocker 1247]

2 hours ago, sydlexius said:

 Further, a way to mark "failed" detections to never run again would be nice (as well as a "manual detection" option to ignore said markers <lol>).

I made (tried) something like that at one point.

Didn't work well because files change all the time and having to account for that was a mess and would result in many files not getting scanned.
For example, you find a Dolby Vision version of funnycatvidio.mkv, making the plugin know it's a new version and not the old one was a mess.
At least for me.  

[yocker 1247]

@sydlexiusI believe i have fixed the issues plus put in protection against hanging processes.
It will sadly be a little while before it's released as i'm also working on some "rules" options so people can set different detections for different tags and studios.

Sadly still can't think of a way to do the "already detected" thing, no way i can think of will work right in my head.

[yocker 1247]

New version up (v1.2.4.0) on yocksers/EmbyCredits Github.

Added:

1. Rule system.

Fixed:

1. Improved hanged thread protection. Note: If a thread has hung for 5 minutes it will end it.

Edited February 12 by yocker

[sydlexius 297]

12 minutes ago, yocker said:

New version up (v1.2.4.0) on yocksers/EmbyCredits Github.

Added:

1. Rule system.

Fixed:

1. Improved hanged thread protection.

That rules engine melts my brain with all the possibilities!  Any chance you could have a rule that instead of detecting, just sets the credits using an offset like -00:01 or some such?

[yocker 1247]

2 minutes ago, sydlexius said:

That rules engine melts my brain with all the possibilities!  Any chance you could have a rule that instead of detecting, just sets the credits using an offset like -00:01 or some such?

Wouldn't that defeat the purpose of the plugin to just set a marker at 30 seconds from the end?
Emby already does this.