[FEAT] Allow Jellyfin Media Server to submit timestamps from users who had Jellyfin scan for Intros and Credits

[trevordotson07]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Jellyfin does Intro and Credit detections, there should be a way for the plugin to submit that information to the IntroDB and grow the amount of media covered by the database. This would be easier than having users submit the timestamps which most people are not likely to do.

Describe alternatives you've considered
None

Additional context
None

[Pasithea0]

Thanks for the suggestion! This one comes up now and then, so it's worth addressing properly. Short version: auto-submitting Jellyfin's built-in detections would grow the quantity of data, but at the cost of the accuracy that's the entire point of TheIntroDB.

A few reasons why:

1. Jellyfin's built-in detection is a heuristic, not ground truth. Its intro/credit detection uses audio fingerprinting tuned for a local skip button — where a false positive costs one viewer a single click. It regularly misfires on montages, reused footage, cold opens/recaps, and credits that vary episode to episode. But a timestamp in TheIntroDB isn't served to one person — it's served to every client that looks up that media. One bad auto-submitted timestamp means a wrong skip for thousands of users.

2. It bypasses the verification model the database is built on. Entries go through human submission and are averaged across multiple independent submissions — that's also why entering your API key prioritizes your submissions in the averaging calculation; the pipeline is built around trusted, verified contributions. Auto-submitting one server's detections doesn't just add noise: one server's systematic errors get replicated across its entire library and can skew the average for everyone. That's data poisoning, even with zero malicious intent.

3. Media matching is genuinely hard to get right. Jellyfin detects segments per-file, on your server, for your release. Different cuts of the same episode (broadcast vs. streaming vs. DVD) have different intro lengths and different recaps, and detection output varies with server settings. Mapping a per-file detection to the correct canonical entry in the DB — at the right version — without introducing mismatches is a lot harder than it sounds.

4. It moves the cost, not the problem. Either we accept unreviewed data (which contradicts everything above), or we end up manually triaging a flood of noisy submissions — neither is sustainable.

That said, the underlying goal is to lower the barrier to contributing. I'll continue to look into a solution, and if we ever do add submissions within Jellyfin, I would prefer it to be a UI confirmation, something the SDK doesn't yet support.

Happy to keep discussing if you have thoughts on that.

[trevordotson07]

I wonder if you could store Jellyfin generated data in a separate area (or have it tagged). This would allow users who want to take a risk with unreliable data to have a toggle to use it. In the end, I think something is better than nothing.

[Pasithea0]

I'll look into this. I just need to carefully weigh the pros and cons of data pollution.

[trevordotson07]

I think this extra data can be function as a way to entice more to try the addon and encourage more to contribute to the database.

[Tragen]

The main problem is that Jellyfin has no option to tell where the media segment is coming from. Is it from TheIntroDB, another provider or by scanning the library with Intro-Skipper.

[trevordotson07]

I think you don't need to rely on Jellyfin to tell you where it came from. You could assume based on a couple of factors: 1. You could have the plugin log which media segments it has put into to Jellyfin. 2. The database could assume the time from Jellyfin came from IntroDB if the timestamps are an exact match. 3. If the segment data came from another provider, it should not matter since it is more data and can be coraberated by data from other user, so bad data would be overshadowed by good data.

[Tragen]

It could be the opposite way also. good data could be overshadowed by bad data.
And without knowing when and who wrote the data, you cannot check for updates without checking the segments and comparing them against the current data on TheIntroDB servers. More work and more network traffic which is bad.

[trevordotson07]

To fix the network trafffic problem, you could maybe add something to the plugin that monitors what adds segments to media in the Jellyfin library, this would have the work then happen on the Jellyfin servers themselves. I think with your concern over too much bad data, your right that it could cause problems, but if it was stored in a different way than the regular database (kind of like a less reliable toggle for user if they want) this would be the best of both worlds.

[AbandonedCart]

Jellyfin itself does not detect segments. That data is actually sourced from either media chapters (using the Jellyfin Chapter Segments Provider Plugin) or another plugin, such as Intro Skipper.

[trevordotson07]

Jellyfin itself does not detect segments. That data is actually sourced from either media chapters (using the Jellyfin Chapter Segments Provider Plugin) or another plugin, such as Intro Skipper.

I forgot that the Intro Skipper is not stock even though it is pre-installed. When I reference Jellyfin detecting, I really mean the Intro-Skipper or any other plugin that provides segments.

[AbandonedCart]

It's not pre-installed, either. Intro Skipper is still considered an unofficial plugin.

[trevordotson07]

It's not pre-installed, either. Intro Skipper is still considered an unofficial plugin.

I must have just forgot them. My bad

[AbandonedCart]

No worries. I happened to stumble on this because one of our issues linked here.