[BUG] unnecessary log spam

[Tragen]

You fixed the bugs from #27

But the log is still spammed with unnecessary entries.

Updated to v1.1.1.0, restarted, and ran a Media Segment Scan. The core fix works exactly as you described — thank you for the quick turnaround, and for explaining the midnight bucket. That was not something I could have seen from the outside.

Confirmed

The reset is no longer clamped. First request of the run:

[INF] TheIntroDB API response: StatusCode=TooManyRequests for .../v3/media?tmdb_id=...
[WRN] TheIntroDB API "daily usage limit" exceeded. Will not send requests until
      09/16/2026 23:59:59 UTC. Retry-after: 25646s. Consecutive 429 responses: 1

25,646 s instead of the five-minute ceiling, and the stored time is the bucket rollover. Counted over the whole run:

requests actually sent	1
daily usage limit exceeded	1
rate limit is currently active. Skipping request	1

The probing loop is gone. My daily budget was already spent before the update, so this run could not fetch anything — that part is expected, and the plugin handled it the way it should.

Two observations from the same run

1. The skip path still logs twice per item. The run covered 18,099 items:

[WRN] … request was "rate limited" for "X"; preserving existing segments	18,099
[INF] Fetching from TheIntroDB API: tmdbId=…	18,099
total log lines during the 12 min 17 s the scan ran	95,004

That rotated the Jellyfin log file once mid-run. rate limit is currently active is indeed down to one, so the change works for that message — the other two still fire per item.

2. The scan does not stop while the budget is exhausted. It walked the whole library and finished Completed after 12 min 17 s. Searching that run's log for re-run, rerun, run again, stopping and aborting gives 0 hits.

Not harmful in itself, since nothing is sent. It is only worth mentioning because a scan that reports Completed after touching nothing looks exactly like one that worked — which is the same shape as the original bug, just cheaper.

Neither of these touches the important half: one request instead of thousands. Happy to run it again after the bucket rolls over and report what a real pass looks like, or to test anything specific.

[Pasithea0]

Thanks for the detailed run report. Both points are fixed on main and will ship in the next release.

The skip path no longer logs per item. GetMediaSegments now checks the shared rate-limit gate right after resolving the item's ids and returns the existing segments before the fetch code runs. Concretely:

• Fetching from TheIntroDB API: tmdbId=... no longer fires at all when nothing is sent (the client already logs the actual request URI when one goes out)
• The preserving existing segments warning now fires only for genuine errors. Rate-limited items log at Debug, because the client already emits the one-warning-per-back-off-period line
• The per-item Movie / Episode / Video identity lines moved to Debug as well. They fired for every scanned item regardless of outcome, so even a healthy full-library run was ~18k lines of inventory narration at Information level

Expected outcome for the same run (budget exhausted, 18,099 items):

	before	after
requests actually sent	1	1
daily usage limit exceeded	1	1
rate limit is currently active. Skipping request	1	1
Fetching from TheIntroDB API	18,099	0
preserving existing segments	18,099	0 (Debug only)
WRN/INF lines total	~95,004	2

On the scan not stopping: that is a Jellyfin constraint the plugin cannot override. MediaSegmentExtractionTask iterates the whole library unconditionally, and MediaSegmentManager.RunSegmentPluginProviders catches provider exceptions per item and continues, so a provider cannot abort a scan. Throwing would only trade 18k warning lines for 18k error stack traces. What changed instead: a parked scan now leaves exactly two lines in the log, so "Completed" after touching nothing is immediately diagnosable rather than indistinguishable from a working run.

Happy to re-verify against a real pass once your bucket rolls over.

[Tragen]

Verified on 1.1.2.0, Jellyfin 12.1.0, full Media Segment Scan over 18,099 items,
2026-09-18 14:58:29Z – 15:15:40Z (17.2 min).

This run differed from the reported one in a way worth stating up front: the daily budget was
not exhausted at the start, so the first seven minutes were real work — 1,162 requests sent.
The limit was reached mid-run, at 17:05:30 local, which turned the same run into a direct
before/after of exactly the path you changed.

After the limit, over ~15,200 items and 10.2 minutes, the plugin logged nothing at all:

	before 17:05:30	after 17:05:30
runtime	7.0 min	10.2 min
items	~2,900	~15,200
lines total	5,023	15
TheIntroDB lines	4,901	0
Fetching from TheIntroDB API	992	0
preserving existing segments	170	0

The 15 remaining lines are other subsystems (webhook notifiers, the task's own completion
entry) — they are the control showing logging was still active.

The switch itself is exactly the two lines you predicted:

[WRN] TheIntroDB API "daily usage limit" exceeded. Will not send requests until ... Retry-after: 32070s.
[WRN] TheIntroDB API rate limit is currently active. Skipping request. The rate limit will reset at ...

preserving existing segments now fires only for genuine errors, as designed: all 170 sit
directly behind an HTTP 400 from the API. None of them is a skip.

On the log size, which turned out to be the sharper half of the original report. The
17 September log hit a 10 MiB ceiling and is truncated at 12:03 — the scan ran until 12:07, so
its own tail is gone, and so is the rest of that day's logging from every other subsystem. The
counts in my first report (18,099) could not be reconstructed afterwards; what survives is
11,933 Fetching and 11,103 preserving lines, both lower bounds.

Today's whole run added 715 KB. The file never came close to the ceiling.

A parked scan used to delete the record it was supposed to appear in. That is a better
argument for this fix than the line count.

Thanks for the quick turnaround. One new finding came out of the quiet log and is filed
separately: 170 requests per scan carry season=0 or episode=0 and are rejected with
both season and episode are required for TV shows — they were invisible underneath the old
noise.