intro-skipper
intro-skipper copied to clipboard
[Feature Request]: Show credit information in "Manage Fingerprints" page.
Describe the bug
I noticed that credits were not scanned/being skipped for a show I have so I wanted to check on the plugin page, but the timestamps for the credits are not listed there. It would be helpful information to have access to and/or edit.
Jellyfin installation method
apt
Container image and tag
No response
Operating System
Ubuntu 20.04
Support Bundle
* Jellyfin version: 10.8.13
* Plugin version: 0.1.17+c2727ea4e482
* Queue contents: 19349 episodes, 1243 seasons
* Warnings: `UnableToAddSkipButton, InvalidChromaprintFingerprint`
* FFmpeg: `okay`
FFmpeg version:
ffmpeg version 5.1.4-Jellyfin Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04)
configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-libs=-lfftw3f --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-libdrm --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libsvtav1 --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-opencl --enable-vaapi --enable-amf --enable-libmfx --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
### Jellyfin logs
_No response_
Could you please install the preview version to see if it resolves the problem? There is a bug in the current release version that causes chromaprint calculations to fail for credits when an intro timestamp is already present. https://github.com/jumoog/intro-skipper/releases/tag/10.8%2Fpreview
Okay, I changed the ownership of that file and moved it to the plugin directory. Now, the detect credits is taking a long time (which is a good sign). I suspect this was the fix, but won't know until it finishes (probably be a few hours at least). Will report back after.
@rlauuzo So, that new dll you linked did cause the credits to get picked up, but on the show I tested the timing is off about 50 seconds (starts ~50-55 seconds too early). Also, intro only skipped first 30 seconds instead of the entire intro. I tried deleting and rescanning but got the same results. I looked through the settings and nothing is changed on my end. Not sure if this is a regression or not. I replaced the dll with the old one and rescanned and that fixed the intros, but after rescanning the credits it is using the old (wrong) value (assuming this is because it cannot scan for a new one with the older version). So, I deleted the cache again and rescanned the intro only, but the same wrong time for the credits persist unfortunately. I seem to be worse off than when I started. Guess I'll just have to turn off auto skip for credits and wait until the next stable update comes out. Thanks for the help anyways though.
I believe the 55-second offset is directly caused by the maximum credit length increasing from 240 to 300 seconds in the preview version. This change likely explains why you needed to perform a full rescan. @AbandonedCart
If you're still using the preview version, try doing this:
- Delete the existing season timestamps in the plugin settings.
- Restart Jellyfin (this is important to apply the changes).
- Start a new scan.
That's an odd issue with the 30-second intro detection. I haven't encountered that, and I'm not aware of any recent changes to the detection logic. Could you provide some more details?
Oh, I did not restart jellyfin. I guess I should have because I was replacing a plugin file? I'll run some more tests tomorrow and see if I cannot figure this out. Yeah, the 30 second thing was weird. Not sure what other details I could provide. The log files usually just say scanning show etc... If there is something that still needs to be fixed I don't mind waiting for the next stable release. I will restest tomorrow though and report back.
Oh, I did not restart jellyfin. I guess I should have because I was replacing a plugin file? Yes, plugins are loaded on startup.
I believe the 55-second offset is directly caused by the maximum credit length increasing from 240 to 300 seconds in the preview version. This change likely explains why you needed to perform a full rescan.
But then by that theory, you can't ever change the user settings. If it was a 60 second offset, I would be more convinced. It's only the maximum duration, though.
I've also experienced the shift. For me credits for episodes added before the maximum duration change were shifted by exactly 60 seconds. Aren't chromaprints for credits calculated relative to (runtime - maximum credit length).
It only changes where the analysis starts, but chromaprints don't use it. It's black frame.
The issue is that credit chromaprints are created relative to the CreditsFingerprintStart point. When the maximum credit length changes, this point shifts, but the cached chromaprints remain tied to the old starting point, causing the misalignment.
So the ability for the user to change the value is broken, since the premise for that change was that credits were being ignored for newer shows.
the cached chromaprints remain tied to the old starting point, causing the misalignment.
I'm not sure if this is a feature or a bug. But recreating the whole cache is very expensive.
The chromaprints themselves aren't tied to anything. It's the resulting calculation.
Either the max duration needs to be 10 minutes (the absolute longest credits currently known are around 9.5) and not be an option or the logic to setting them needs to be reworked to adjust. As is, though, it sounds like users will break all their timings trying to change anything.
I can't test it since I don't have access to shows with credits long enough. However, wouldn't this method work better for longer credits, when using black frames? https://github.com/jumoog/intro-skipper/pull/132
I was estimating 50-55 seconds before in my test, so it very well could be 60 seconds as stated by @rlauuzo I am not sure. I did not actually change any settings in the gui at all, I just replaced the dll file with the one that was provided. If it helps, my show credits are only usually around 90 seconds for the most part.
Since my entire cache was rescanned, it seems like I am going to have to delete it all and rebuild it. Going to wait for the next update to do this instead of retesting now. Not sure if I need to go in and delete the files or if the "Erase all end credits timestamps (globally)" option will do the trick (I guess we'll see). I could just delete the files that end in -credits and then delete the credits.xml file while the jellfin daemon is stopped (are we still moving towards a single xml file or is that not a thing anymore?)? Anyway, sound like I need to hold tight here and do nothing for now while things get sorted out. Thanks for the additional testing/help everybody.
I was estimating 50-55 seconds before in my test, so it very well could be 60 seconds as stated by @rlauuzo I am not sure. I did not actually change any settings in the gui at all, I just replaced the dll file with the one that was provided. If it helps, my show credits are only usually around 90 seconds for the most part.
Since my entire cache was rescanned, it seems like I am going to have to delete it all and rebuild it. Going to wait for the next update to do this instead of retesting now. Not sure if I need to go in and delete the files or if the "Erase all end credits timestamps (globally)" option will do the trick (I guess we'll see). I could just delete the files that end in -credits and then delete the credits.xml file while the jellfin daemon is stopped (are we still moving towards a single xml file or is that not a thing anymore?)? Anyway, sound like I need to hold tight here and do nothing for now while things get sorted out. Thanks for the additional testing/help everybody.
If you're still using the preview version, you might try to change the maximum credits duration to 240.
@rlauuzo No, I completely removed the plugin and plugin folder and reinstalled from the repo and then disabled auto skip for credits. Re-scanning takes me like 8-10 hours and I cannot test for the next few days anyway as I have a couple other projects to finish. So, it was a scan duration issue?
Any credits over 4 minutes won't be detected at 240. That's the catch.
Before, for credits near the end of the episode, it skipped the credits all the way to the end of the episode so I can just play the next one. I hope that is still a thing with the duration changes. I was going to look at what my values are but since I am back on the stable version I do not think I have these options (Just the "Modify Intro Perameters"). I did not see them anyway. For credits at the very end of an episode it seems to me that some credits will exceed 4 minutes when you include both the credit sequence and the produciton information etc... Seems like a pretty big catch to me just saying.
I can't test it since I don't have access to shows with credits long enough. However, wouldn't this method work better for longer credits, when using black frames? #132
I did some testing. I changed the maximum credits duration to 3 minutes, and it successfully detected the credits in the new Fallout show, which are 5 minutes long. It appears to be working.
That also means the user setting is essentially meaningless.
Reverting to not having one is fine, but should probably be explained in settings this time. The biggest issue before wasn't necessarily the lack of a setting but the lack of a reason for not having one.
Is that problematic? It's still utilized for chromaprints and chapters. However, considering chapters are essentially free, perhaps the maximum duration for them should also be increased.
The settings text only mentions audio Similar sounding audio which is longer than this duration will not be considered credits.
The issue is less functionality and more "but my maximum is 3 minutes and it's including credits that are five minutes long so is it broken?"
I'm saying remove the input part and replace it with something like "Credits duration is determined automatically based on precise video indicators"
Yes. I really need this to manually adjust credit timestamps. Some anime show doesn't recognize the right credit timestamp. e.g: Shangri-La Frontier. It could be better if you could adjust 1 episode credit and re-analytic the rest based on that episode's ChromaprintFingerprint.
I suspect the issue is with chapter markers. Some anime label the outro scene as "credits start" and the epilogue as "credits end". This likely causes the chapter analyzer to mistakenly identify the epilogue as the credits.
I suspect the issue is with chapter markers. Some anime label the outro scene as "credits start" and the epilogue as "credits end". This likely causes the chapter analyzer to mistakenly identify the epilogue as the credits.
The file I tested only have 4 chapters: chapter , chapter 2, chapter 3 and chapter 4.
I downloaded Shangri-La Frontier, and here's how the chapter markers are formatted:
00:00:00.000 : ja:Prologue
00:00:41.000 : ja:Opening
00:02:11.000 : ja:Episode
00:21:54.000 : ja:Credits Start
00:23:24.000 : ja:Credits End
[Link removed] I downloaded subsplease S1 batch.
I checked the subsplease files and they don't have chapter markers. The issue is likely that the plugin currently scans only the last 4 minutes, and the outro begins earlier.