Cheesegeezer 3086 Posted November 17, 2021 Share Posted November 17, 2021 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 More sharing options...
chef 3745 Posted November 17, 2021 Share Posted November 17, 2021 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 More sharing options...
chef 3745 Posted November 17, 2021 Share Posted November 17, 2021 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 More sharing options...
Cheesegeezer 3086 Posted November 17, 2021 Share Posted November 17, 2021 (edited) 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 November 17, 2021 by Cheesegeezer 1 Link to comment Share on other sites More sharing options...
Cheesegeezer 3086 Posted November 17, 2021 Share Posted November 17, 2021 updated the other thread with the latest version. More details here. Please follow the other thread for any updates on builds 1 Link to comment Share on other sites More sharing options...
fbrassin 35 Posted November 17, 2021 Share Posted November 17, 2021 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 1 Link to comment Share on other sites More sharing options...
Painkiller8818 203 Posted November 18, 2021 Share Posted November 18, 2021 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 More sharing options...
Cheesegeezer 3086 Posted November 18, 2021 Share Posted November 18, 2021 1 minute ago, Painkiller8818 said: the plugin we are very close, just need to wrap up some bug issues. 2 Link to comment Share on other sites More sharing options...
fallenwitch3r 41 Posted November 18, 2021 Share Posted November 18, 2021 (edited) @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 November 18, 2021 by fallenwitch3r 2 Link to comment Share on other sites More sharing options...
rbjtech 4257 Posted November 18, 2021 Share Posted November 18, 2021 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 More sharing options...
fallenwitch3r 41 Posted November 18, 2021 Share Posted November 18, 2021 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 2 2 Link to comment Share on other sites More sharing options...
FrostyCoolSlug 6 Posted November 19, 2021 Share Posted November 19, 2021 (edited) 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). 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 November 19, 2021 by FrostyCoolSlug 1 Link to comment Share on other sites More sharing options...
rbjtech 4257 Posted November 19, 2021 Share Posted November 19, 2021 (edited) 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). 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 November 19, 2021 by rbjtech 1 Link to comment Share on other sites More sharing options...
neik 837 Posted November 19, 2021 Share Posted November 19, 2021 Just updated the server to .18 and the plugin to .22 but now the dashboard shows the plugin with version "0.0.0.0": Anyone else seeing this? Is it "safe" to fingerprint, in the sense that I get proper data? 1 Link to comment Share on other sites More sharing options...
rbjtech 4257 Posted November 19, 2021 Share Posted November 19, 2021 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": 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. 2 Link to comment Share on other sites More sharing options...
BaukeZwart 94 Posted November 19, 2021 Share Posted November 19, 2021 (edited) 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. Edited November 19, 2021 by BaukeZwart 1 Link to comment Share on other sites More sharing options...
Cheesegeezer 3086 Posted November 19, 2021 Share Posted November 19, 2021 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. the release notes state that ffmpeg was updated to 4.5 Let me check on my test system. 1 Link to comment Share on other sites More sharing options...
neik 837 Posted November 19, 2021 Share Posted November 19, 2021 If you haven't tried to clear your cache I would do that and retry. 1 Link to comment Share on other sites More sharing options...
BaukeZwart 94 Posted November 19, 2021 Share Posted November 19, 2021 (edited) 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. Edited November 19, 2021 by BaukeZwart 1 Link to comment Share on other sites More sharing options...
chef 3745 Posted November 19, 2021 Share Posted November 19, 2021 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. 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 More sharing options...
BaukeZwart 94 Posted November 19, 2021 Share Posted November 19, 2021 (edited) @chef getting this in console. I also tried IP:port bypassing the reverse proxy, same output in console. Edited November 19, 2021 by BaukeZwart 1 Link to comment Share on other sites More sharing options...
chef 3745 Posted November 19, 2021 Share Posted November 19, 2021 1 minute ago, BaukeZwart said: @chef getting this in console. 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 More sharing options...
chef 3745 Posted November 19, 2021 Share Posted November 19, 2021 I have the same beta... I'll have to inspect further. One moment. Link to comment Share on other sites More sharing options...
BaukeZwart 94 Posted November 19, 2021 Share Posted November 19, 2021 Found this in the Emby log https://0bin.net/paste/VhloJXIm#A7yc17CoQ-85l/vzuh/g/RPQ2Sln3ldaI+YShaKfE2z Link to comment Share on other sites More sharing options...
chef 3745 Posted November 19, 2021 Share Posted November 19, 2021 51 minutes ago, BaukeZwart said: Found this in the Emby log https://0bin.net/paste/VhloJXIm#A7yc17CoQ-85l/vzuh/g/RPQ2Sln3ldaI+YShaKfE2z Okay, I'm not sure a proper web socket connection has been created then. If you restart the server instance, does the error disappear? Link to comment Share on other sites More sharing options...
Recommended Posts