Plugin: TheIntroDB – Emby Plugin

[horstepipe 430]

On 8/9/2026 at 1:34 AM, Pasithea said:

Make sure to include the total duration when submitting. Different film versions are differentiated based on the duration, which allows you to submit multiple times.

thanks @Pasithea
but how / when will the plugin request the runtime if needed?

[Pasithea 25]

On 8/13/2026 at 2:10 AM, horstepipe said:

thanks @Pasithea
but how / when will the plugin request the runtime if needed?

Good question, the plugin reads it automatically. Emby stores each item's runtime (RunTimeTicks), and the plugin sends it as duration_ms on every lookup.

For STRM files Emby can't probe the actual file, but it usually still has a runtime from the metadata providers (TMDB/TVDB), so the plugin uses that the same way. There's also a tolerance of about 2 minutes on matching, so small differences between the metadata runtime and the real stream don't cause a mismatch.

This could cause issues for extended cuts, but if you’re using strm files, it’s likely you’re using the theatrical cut anyway.

[VirulentPip 97]

I don't know if I am reading correctly, but when it comes to recaps there's no button overlay on the app or does it just automatically skip these ? Does the button appear for Intro's and Outros (credits) ? 

 

[Kyouma 38]

9 minutes ago, VirulentPip said:

I don't know if I am reading correctly, but when it comes to recaps there's no button overlay on the app or does it just automatically skip these ? Does the button appear for Intro's and Outros (credits) ? 

 

Emby only supports Intro and Credits. To be more precise, Emby only has IntroStart, IntroEnd and CreditsStart. So only these will get a skip button.

Somewhat related:

 

You could ask for more support in this area.

Edited August 24 by Kyouma

[horstepipe 430]

anybody else has problems with this plugin and Emby dockerized? I am in the process of moving emby to Docker. Plugin works fine locally. In Emby docker, the scan stops after some seconds. Log is very quiet unfortunately.

[horstepipe 430]

looks like the cause are seasons like that:
"Staffel 2003"
Staffel "2004"

That's not uncommon in Germany. 

Because of that I see
 

Quote

TheIntroDB scan aborting: 20 consecutive failures (API may be down). Skipping remaining 47331 items.

 

[Pasithea 25]

2 hours ago, horstepipe said:

anybody else has problems with this plugin and Emby dockerized? I am in the process of moving emby to Docker. Plugin works fine locally. In Emby docker, the scan stops after some seconds. Log is very quiet unfortunately.

Are you deploying the Emby Docker image on an external VPS? It could be that its from a blocked ASN. We block heavily abused networks for security reasons, but I could take a closer look

You can try requesting the API from the same IP to test. 

curl https://api.theintrodb.org/v3

Edited August 26 by Pasithea

[horstepipe 430]

Hi Pasithea,

I‘d say my problem comes from some season naming I described in my

last post. Looks like that show is being scanned way earlier in my docker instance than in my local instance.

 

BR

[Mookdog 90]

Hey Guys

Just installed the introDB plugin and went to scan for intro markers but the scan is only going to 0.3% before it stops completely. Any idea what could be wrong. I whitelisted all my tv shows (About 2600 shows) and it seems the scan stops within 3 minutes of starting it. Attached is my log maybe someone could help

 

Thanks

Mook

embyserver.txt

[Pasithea 25]

On 8/26/2026 at 10:10 PM, horstepipe said:

Hi Pasithea,

I‘d say my problem comes from some season naming I described in my

last post. Looks like that show is being scanned way earlier in my docker instance than in my local instance.

 

BR

Should be fixed in v1.0.8.5!

@Mookdogalso check if this fixed it for you please!

[Mookdog 90]

7 hours ago, Pasithea said:

Should be fixed in v1.0.8.5!

@Mookdogalso check if this fixed it for you please!

Nope still ended the scan at 0.3%

[Pasithea 25]

9 hours ago, Mookdog said:

Nope still ended the scan at 0.3%

I just pushed v1.0.8.6. A limit was in place to throttle under the API limit, but I've increased it and if you still see a stop, the log will now say exactly why. 

Keep in mind the API does have a daily request limit:
- authenticated users (with API key): 500 daily requests
- unauthenticated: 100 daily requests
The plugin is designed to slowly chip away your entire library over multiple runs, so it may take a few days before your large library is scanned.

I would recommend using the whitelisting feature in the plugin to first scan media you're actively watching or a smaller part of your library you want skips for, then you can increase the whitelist to fill the remaining media in your library.

[horstepipe 430]

On 9/2/2026 at 5:21 PM, Pasithea said:

- authenticated users (with API key): 500 daily requests
- unauthenticated: 100 daily requests

 

Hello Pas,

thanks for the fix!

So the are the new and future request limits?
I am a little confused because in plugin settings I see (per default):

So on a big show library I can put this number to 500?

[Pasithea 25]

10 hours ago, horstepipe said:

Hello Pas,

thanks for the fix!

So the are the new and future request limits?
I am a little confused because in plugin settings I see (per default):

So on a big show library I can put this number to 500?

I understand your confusion, let me explain.

• "Maximum API lookups per run" (plugin setting) is per scan run, not per day. v1.0.8.6 defaults it to 10,000; if yours still shows 200, that's the old saved value from before the update. A run stops when it hits this number, and the next run/scheduled task continues where it left off. Setting it to 500 is fine — the per-run number is just a cap on one run, it doesn't reserve or guarantee anything against the daily limit.
• API daily limit is enforced server-side: 500 requests/day with an API key, 100 without. Once you hit it you get 429s and the plugin backs off, then that run stops with a clear log message; it resumes on a later run after the daily window resets.

So yes, 500 works as a per-run value, but with an API key that would use your entire daily budget in one run. Nothing wrong with leaving the default and letting it chip away across runs — items already scanned are skipped, so repeat runs stay cheap.

The setting exists for two reasons:

• If you have a large library, the run may take multiple days to complete. In which case, the API isn't the bottleneck, your system/network is.
• Or, you can cap it so it doesn't run through your entire API budget within a single run.

Also, this does allow for some flexibility in the future so we can increase the rate limit if we decide to do so.