yocker 1869 Posted Thursday at 12:14 PM Author Posted Thursday at 12:14 PM 4 minutes ago, RedNo7 said: Thanks, but I have 17,824 shows - has it done them all (according to the original ETA it was going to take 300 hrs to complete). Depends on if you have the same libraries activated in scheduled task as in the manual detection. I can see from one of your screenshot that you only have one library activated for schedule task. I am going through your logs and settings now, I will report if anything stand out.
RedNo7 22 Posted Thursday at 06:12 PM Posted Thursday at 06:12 PM Thanks @yocker. I do only have 1 real TV library.
yocker 1869 Posted Thursday at 10:20 PM Author Posted Thursday at 10:20 PM 4 hours ago, RedNo7 said: Thanks @yocker. I do only have 1 real TV library. I have gone through the log, nothing in it stands out as a plugin problem. Tracing the progress i do see a small problem in the plugin it self. When scheduled task is running and auto detecting new files is enabled any new files found while a schedule task is running might actually reset the queue. I will fix that bug. What i did see in the log. A lot of files were skipped because they either already had end credit markers, had previously failed or time stamps were downloaded from TheIntroDB. If you have set the manual detection run to ignore those things it will take a much longer time than the schedule task. 1
yocker 1869 Posted Thursday at 10:28 PM Author Posted Thursday at 10:28 PM As said though. I always recommend doing manual detection when starting to add credit markers to videos. Once you have completed all videos then using auto detection and/or scheduled task to keep the library up to date. Running scheduled task to fill up the marks as a first run through is not really recommended as you are a bit out the loop as to what is happening.
RedNo7 22 Posted yesterday at 06:30 AM Posted yesterday at 06:30 AM 8 hours ago, yocker said: Tracing the progress i do see a small problem in the plugin it self. When scheduled task is running and auto detecting new files is enabled any new files found while a schedule task is running might actually reset the queue. I think that has happened to me. This morning I have '0' skipped and the ETA has doubled (was ~200 hrs yesterday)... What would explain me having multiple backups of the same show (when nothing has changed for that show)?
yocker 1869 Posted yesterday at 08:41 AM Author Posted yesterday at 08:41 AM 2 hours ago, RedNo7 said: I think that has happened to me. This morning I have '0' skipped and the ETA has doubled (was ~200 hrs yesterday)... What would explain me having multiple backups of the same show (when nothing has changed for that show)? Wow! You really are unlucky with finding bugs, Microsoft should hire you! I will look into what is causing it to ignore previously saved backups, this one i can replicate so should be easy to fix. I have fixed the scheduled task getting interrupted by auto detection, it will be in a future version. Btw. thanks for reporting the problems, it really helps make the plugin better! 1 1
RedNo7 22 Posted yesterday at 11:41 AM Posted yesterday at 11:41 AM 2 hours ago, yocker said: Wow! You really are unlucky with finding bugs, Microsoft should hire you! they can't afford me 2
yocker 1869 Posted yesterday at 01:51 PM Author Posted yesterday at 01:51 PM @RedNo7I've added a new beta version in the catalog (v2.7.1.7) which should fix the problems. Please report back.
RedNo7 22 Posted 9 hours ago Posted 9 hours ago (edited) OK, it looks like the scheduled task did not stop the already running task this time: ...the task itself has decided it now needs over 2,200 hours (10x the ETA was before and it has only checked ~140 episodes since I started it manually yesterday which is also significantly less then before.) Is it because everyone has failed with this comment: Edited 9 hours ago by RedNo7
yocker 1869 Posted 8 hours ago Author Posted 8 hours ago 1 hour ago, RedNo7 said: OK, it looks like the scheduled task did not stop the already running task this time: ...the task itself has decided it now needs over 2,200 hours (10x the ETA was before and it has only checked ~140 episodes since I started it manually yesterday which is also significantly less then before.) Is it because everyone has failed with this comment: Try the latest beta (v2.7.1.8), i fixed the problem. Basically chromaprint/hash trying to run on a single file when OCR failed and then fails because chroma needs a whole season for comparison. Everything should be perfect now. I very much appreciate reporting the bugs! Please keep it up when you find any. 1 1
yocker 1869 Posted 8 hours ago Author Posted 8 hours ago @RedNo7 I actually discovered the bug my self as well as i copied your settings and ran detections with those. From my testing that should be all the bugs fixed. One last thing, I recommend you edit the keywords it looks for to fit your collection better, the words per default are just generic fit all words that might not cover some series. 1
RedNo7 22 Posted 4 hours ago Posted 4 hours ago Thanks! v2.7.1.8 installed - just restarting the server now and will report back! 1
RedNo7 22 Posted 1 hour ago Posted 1 hour ago Humming along now, but the ETA is high, I assume because the "QI" TV series which is using Chromaprint (which was failing before your fix)? These episodes do have both credits and timed text subtitles In this example, the credits actually start at 29:00, but EmbyCredits says "00:27:56 / 00:298:26"
enterpr1se 0 Posted 55 minutes ago Posted 55 minutes ago Hi, thanks for your plugin! It seems like .strm support was dropped after version 2.7.0.5. Is there any chance you could add it back? I know .strm files aren't ideal for detection, but could we perhaps have an option to enable it at our own risk?
yocker 1869 Posted 36 minutes ago Author Posted 36 minutes ago 38 minutes ago, RedNo7 said: Humming along now, but the ETA is high, I assume because the "QI" TV series which is using Chromaprint (which was failing before your fix)? These episodes do have both credits and timed text subtitles In this example, the credits actually start at 29:00, but EmbyCredits says "00:27:56 / 00:298:26" Chroma detection is always a little hot and miss. Best you can do is look at an episode and see what words are used in the end credits and then add those words to the keywords lidt for the OCR to look for.
yocker 1869 Posted 35 minutes ago Author Posted 35 minutes ago (edited) 27 minutes ago, enterpr1se said: Hi, thanks for your plugin! It seems like .strm support was dropped after version 2.7.0.5. Is there any chance you could add it back? I know .strm files aren't ideal for detection, but could we perhaps have an option to enable it at our own risk? The code is still there but strm files were a mess to work with. I can look into seeing if I can make it better but in the end it's FFMpeg that needs to handle then properly. Edited 28 minutes ago by yocker
enterpr1se 0 Posted 7 minutes ago Posted 7 minutes ago 21 minutes ago, yocker said: The code is still there but strm files were a mess to work with. I can look into seeing if I can make it better but in the end it's FFMpeg that needs to handle then properly. Thanks so much! When I was on version 2.4.x, although it wasn't perfect, it still worked for over 60% of my videos (mostly anime). So I really hope it can be brought back as an optional setting. I also have another suggestion: when credit detection fails for a video, the credit start time defaults to 0:00. However, some third-party players (like SenPlayer) treat the video as completely watched the moment it starts playing due to this timestamp. Is it possible to add an option that sets the fallback credit start time to the very end of the video when detection fails?
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now