Library scans blow out the V8 heap and kill the process (still happens at mem_limit 1g)

[nickwolf]

Description

Library scans keep blowing out the heap and killing the process.

I started out at mem_limit: 512m. Bumping it to 1g helped but didn't actually fix anything, it still dies roughly once a day.

Reason the limit matters so much: Node 22 reads the cgroup limit and sets max-old-space-size to about half of it. So 512m gets you a ~256MB heap ceiling and 1g gets you ~524MB. Both are easy to hit.

What made this take me so long is that it doesn't look like a crash from the outside. docker inspect said ExitCode=0, OOMKilled=false,
Health=healthy, RestartCount=0 the entire time. I had 60 restarts in 16 days and nothing in the docker state said why.

When I finally counted the two mechanisms separately over that window I got 59 V8 heap aborts and 4 cgroup OOM kills. The cgroup ones only show up in dmesg on the host, not inside the container. So it's almost entirely V8 doing the killing, the kernel is barely involved.

Couple of debugging notes since both of these wasted my time:

• FATAL ERROR goes to stderr with no timestamp on it, so it doesn't interleave with seerr's normal timestamped output. grep -B3 FATAL gets you nothing useful. docker logs -t stamps everything including stderr, use that.
• Don't grep for just FATAL. A lot of movie titles have "Fatal" in them. I got 16 hits and only 3 of them were real.

What I found

Radarr, Sonarr and Jellyfin scanners each pull a whole library in one call:

• server/lib/scanners/radarr/index.ts:80 - this.items = await this.radarrApi.getMovies()
• server/lib/scanners/sonarr/index.ts:88 - this.items = await this.sonarrApi.getSeries()
• server/lib/scanners/jellyfin/index.ts:524 - this.items = await this.jfClient.getLibraryContents(library.id)

I measured the responses from inside the container. Radarr gives me 16,451
items, 79.7MiB on the wire, 75.8MiB once parsed. Here's a Radarr scan kicked off from a fresh restart:

BASELINE 165.4MiB
12:10:11 166.0MiB
12:10:22 499.6MiB   <- one 10s sample later
12:10:33 243.6MiB
...      sits at 250-275MiB for the rest of the scan

That's +335MiB inside a single sampling interval, right at the start, before it processes a single item. Makes sense, the parse is holding the raw response string and the object graph at the same time. On a 256MB ceiling that alone kills you. The Plex scanner doesn't do this, it pages through withpaginateLibrary.

Separate thing, and this one I understand less. RSS doesn't drop back down when a Plex Full Library Scan finishes:

01:27:14 178.5MiB   scanning, movie libraries, flat
01:31:12 198.7MiB
01:54:01 Full Scan Complete
02:45:27 608.6MiB   <- 50 minutes after it finished, nothing running
02:51:15 605.5MiB
(still around 621MiB at 09:00, 7+ hours later, idle)

So about 450MiB just stays there, and it's still there hours later.

That's what actually kills it, I think. The fetch spike on its own survived fine on a fresh process. But once seerr is already sitting at ~620MiB of leftovers, the next scheduled scan hits the same spike and there's no room for it:

10:00:00  radarr-scan fires (cron is 04:00 local)
10:00:09  FATAL ERROR: Reached heap limit          <- 9 seconds in
10:00:13  Starting Seerr version 3.4.0
10:30:00  sonarr-scan fires (cron is 04:30 local)
10:34:25  FATAL ERROR: Ineffective mark-compacts near heap limit
10:34:29  Starting Seerr version 3.4.0

The numbers line up with that. From a clean 165MiB start, 165 + 335 is about 500, which fits under 524 and my manual Radarr scan survived fine. From 620MiB of leftovers, 620 + 335 is about 955, and the scheduled one died 9 seconds in, right at the fetch.

It's pretty repeatable too. Manual Sonarr scan died 4m50s in, the scheduled one died 4m25s in.

Fixing either one would probably stop my box crashing. But the leftover memory is what'll bite me again once the library gets bigger, so that's the one I care about more.

Stuff that might help

1. Page or stream the Radarr/Sonarr/Jellyfin fetches like paginateLibrary already does for Plex. Gets rid of the spike.
2. Figure out what a full scan is holding onto.
3. BUNDLE_SIZE in server/lib/scanners/baseScanner.ts is hardcoded to 20, and each bundle runs concurrently through Promise.all. There's no setting for it, so if you hit this there's no way to trade scan speed for memory. Only lever you've got is raising the container limit, and that just scales with library size. I noticed test: add scanner update rate override for testing #3241 adds an update rate override for testing, might be somewhere obvious to hang this off.
4. Whatever happens with the rest, a minimum mem_limit in the docs would help. The way Node sizes its heap makes 512m kind of a trap.

Happy to test patches, I've got a box that reproduces this every day.

Version

3.4.0 (commit 2dbe8860179e83ed2044d5fc8ed17679ae05e5ad)

Steps to Reproduce

1. Run seerr in docker on Node 22, mem_limit: 1g, no NODE_OPTIONS set.
2. Hook up a Radarr with a big library. Mine's 16,451 movies.
3. Check what heap ceiling you actually got:
   docker exec seerr node -e "console.log(require('v8').getHeapStatistics().heap_size_limit/1048576)"
   512m gives ~256, 1g gives ~524.
4. Restart the container so you've got a clean baseline, then run Radarr Scan from Settings > Jobs with docker stats seerr open. RSS jumps by roughly the parsed size of your Radarr response within one sample.
5. For the actual crash: let it run a Plex Full Library Scan, check RSS is still high after Full Scan Complete, then fire off a Radarr or Sonarr scan.
   docker logs -t seerr gives you FATAL ERROR: Reached heap limit and thenStarting Seerr version 3.4.0 a few seconds later, while docker inspect is still telling you ExitCode=0 and OOMKilled=false.

Screenshots

n/a, server side

Logs

2026-07-29T10:00:09Z FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
2026-07-29T10:00:13Z [info]: Starting Seerr version 3.4.0
2026-07-29T10:34:25Z FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
2026-07-29T10:34:29Z [info]: Starting Seerr version 3.4.0

$ docker inspect seerr --format '{{.State.ExitCode}} {{.State.OOMKilled}} {{.RestartCount}}'
0 false 0

response sizes, measured from inside the container:
sonarr /api/v3/series: items=2352   wire=9.1MiB   heapDeltaOnParse=8.6MiB
radarr /api/v3/movie:  items=16451  wire=79.7MiB  heapDeltaOnParse=75.8MiB

Platform

desktop

Database

SQLite (default)

Device

Beelink mini PC, running Proxmox, seerr is in docker inside an LXC

Operating System

Debian 12 (LXC), Docker 29.6.1, Node 22.22.2

Browser

Firefox

Additional Context

Image is ghcr.io/seerr-team/seerr:latest. Library sizes are 16,451 movies in Radarr, 2,352 series in Sonarr, and two Plex libraries, one movies one TV.

The bulk fetch thing I'm sure about. It lands in one sample, right when the scan kicks off, and the response size accounts for how big the jump is.

The leftover memory I'm much less sure about. I know it's there and I know it persists, but I didn't sample continuously through the whole scan so I can't tell you which part of it accumulates, and I haven't worked out what's actually being held. I did chase down two of my own guesses and both were wrong:
AsyncLock cleans its keys up properly on release, and the recursive pagination doesn't seem to hold onto pages, since the Plex movie path runs that same code
and stays flat.

One last thing. Setting NODE_OPTIONS=--max-old-space-size=... on its own made things worse for me. All it did was turn a clean V8 abort I could grep for into
a kernel OOM kill, which was harder to work out. If you set it you have to move the container limit with it.

AI disclosure: I used an AI assistant to help collect and format the measurements here and to read through the scanner code. The numbers are all from my own instance, I ran them myself, and I've gone over everything above.

Search Existing Issues

• Yes, I have searched existing issues.
  Closest I found was infinite loop and crash with "JavaScript heap out of memory" #513 from 2023, but that's a request approval loop, different thing. Couldn't find anything open about scanner memory.

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[fallenbagel]

Thanks for the report

Two corrections first, so you don't spend time on the wrong thing.

1. BUNDLE_SIZE = 20 is the default in baseScanner.ts, but the Radarr, Sonarr and Plex scanners all pass bundleSize: 50 in their constructors. 20 only applies to the Jellyfin scanner. And test: add scanner update rate override for testing #3241 is a test-only change and it exists so the scanner tests don't sit through the 4 second update rate. It's not a settings surface and it isn't merged, so there's nothing to hang a knob off there, imo.

2. Everything you measured is RSS, but what's killing the process is the V8 old space limit. Buffers live outside the heap and don't count toward max-old-space-size, and axios buffers the whole response as chunks, concatenates, stringifies, then parses. For an 80MiB payload that's roughly 80 in chunks, 80 concatenated, 80 as a string and 76 as objects, and only the last two land in the heap. That's why your +335MiB spike is bigger than the heap pressure it actually creates. Same caveat on the 450MiB residue where V8 and the allocator don't hand freed pages back to the OS, so flat RSS after a scan doesn't tell us the heap is still holding anything.

So before I patch anything I'd rather have the heap data than RSS. Could you do two things, if you're up for it:

1. Run with NODE_OPTIONS=--heapsnapshot-signal=SIGUSR2 (see, https://nodejs.org/learn/diagnostics/memory/using-heap-snapshot#using-heap-snapshot) and take three snapshots: before the Plex scan, right after Full Scan Complete, and 30 minutes later. kill -USR2 1 inside the container. Serialising a 600MiB heap roughly doubles memory while it writes, so raise mem_limit for that run or you'll just trigger the thing we're trying to measure.

2. Scan your movie library and your TV library separately.

My guess is the residue is TV-only. processMovie takes an already-resolved TMDB ID and never calls TMDB, but the TV path goes through getTvShow, which requests aggregate_credits,credits,external_ids,keywords,videos,content_ratings,watch/providers and caches the result in a NodeCache with a 6 hour TTL and no size cap. So that's like one fat object per show, held six hours. Your own timeline fits this as its flat while the movie libraries were scanning, elevated afterwards. If movie-only stays flat and TV doesn't, that's a cache sizing problem rather than a leak, and it's a different fix.

On the fetch spike, paging isn't available to us. Radarr's /api/v3/movie and Sonarr's /api/v3/series return the full list with no paging parameters, so it means streaming the response through a JSON stream parser rather than reusing the paginateLibrary shape. Capping the caches isn't an easy option either as afaik, node-cache would throw ECACHEFULL on set instead of evicting, so it'd mean swapping the cache layer. Both are doable, but I just want to know which one is actually killing you before I pick.

P.S this report didn't come in through the issue form and our bug template applies awaiting triage and the bug type automatically and yours has neither, so I'm guessing the API or gh. Not a problem as long as you disclose the AI usage and actually verify it's output instead of dumping it raw and that's exactly what our policy asks for, but please use the form since it's what our triage is based off of. I've labelled it manually for the time being.

[nickwolf]

You're right on both counts. I stopped at baseScanner.ts and never looked at the constructors, and I read #3241 as a settings surface when it's a test-only change that isn't merged. And every number in the report is docker stats, so the chunk, concat, string, parse split means the spike overstates the heap pressure it creates, and the flat RSS afterwards doesn't prove anything is still retained.

The version has moved under me since I filed. I'm on 3.4.1 now, commit 69f73a6, and it aborted again on 2026-08-04 at 10:33 UTC with the same Reached heap limit.

I've started on both. The snapshots are on a clone rather than my own box, because my seerr runs in docker inside an LXC that has 3.5GiB for all of its containers and I can't give it room to serialise a 600MiB heap without risking the rest. Same image digest, and I set --max-old-space-size=476 so heap_size_limit comes out at 524MiB, matching what the 1g cgroup gives me in production.

First result is in and it looks like you're right about the residue. TV libraries only, from a clean start, RSS went 169.8MiB to 542.5MiB and stayed there after Full Scan Complete, which is the shape I reported. The heap snapshot taken at that point has a live heap of 7.1MiB. So there's nothing retained, and the 450MiB in my report was me reading RSS and calling it a leak. I'll do the movie-only run and the 30 minute snapshot before I write it up properly, but I didn't want to sit on that part.

Fair on the form. I used gh because I was pasting a lot of log output and didn't think about what the template does behind it.

AI disclosure, same as the issue: assistant helped with the writing and reading the code, the measurements are mine.

[nickwolf]

Correction first, because my last comment was wrong and it went the wrong way. The residue is real, and your original guess about getTvShow was right.

I was snapshotting the wrong process. The image runs npm start as PID 1 with the server as its child, so kill -USR2 1 gave me the npm wrapper, whose heap is a static ~7MiB. That is where "live heap of 7.1MiB" came from. Two things gave it away: a fresh-boot baseline and a post-scan snapshot came back with the same node count, 81,597 against 81,597, which can't happen across a scan; and --heapsnapshot-signal puts the pid in the filename, so every file I had read Heap.<date>.<time>.1.0.<seq>. Resolving the child pid first fixes it.

Everything below is the child process, on a clone of my install with the heap ceiling pinned to 524MiB so it matches production. I read the heap two independent ways, my own sum over the snapshot's self_size and CDP HeapProfiler.collectGarbage followed by Runtime.evaluate on v8.getHeapStatistics(). They agree within half a percent. I also calibrated the snapshot arithmetic against V8 on a deliberately inflated heap first, 70.23MiB measured against used_heap_size 72.24MiB.

Your movie versus TV split, which was the thing you actually asked for:

                                        live heap after forced GC
movie libraries only, full scan       95.27 -> 97.73 MiB    (+2.46)
TV libraries only, full scan          94.25 -> 434.04 MiB   (+339.79)

The movie scan ran for 21 minutes and did far more item lookups than the TV one, and it cost 2.46MiB. So it is TV-only, exactly as you predicted. The movie path put 13 entries in the tmdb cache in total, which fits processMovie never calling TMDB.

Then I flushed the caches one at a time to check it was actually the cache rather than something correlated with it:

after TV scan                         434.04 MiB
flush plexguid                        433.15 MiB   (-0.89)
flush tmdb                             95.51 MiB   (-337.64)

That is back to within 1.3MiB of the baseline, so the tmdb cache is holding 99.4% of it. plexguid ends the scan with a comparable number of keys and costs essentially nothing, so it is the payload size that matters and not the key count.

Introspecting the live cache through CDP, require('/app/dist/lib/cache.js') returns the loaded singleton so this is the real one:

mean entry        88.5 KiB
largest sampled   48,841 bytes
total as JSON     175.09 MiB      (heap cost is roughly double, useClones is on)
options           stdTTL 21600, checkperiod 1800, maxKeys -1
key shape         https://api.themoviedb.org/3/tv/<id>{"language":"en","append_to_response":"aggregate_credits,...

One small amendment to the 6 hour TTL you mentioned. That is the stdTTL on the cache itself, but getTvShow passes 43200 explicitly and a per-call ttl overrides stdTTL, so these entries actually live 12 hours. I measured ttl_remaining_s at 43001 on a fresh one. It doesn't change your diagnosis, it just makes the window twice as long as it looks from cache.ts. Worth saying I spent a while convinced the TTL wasn't being applied at all, because externalapi.ts has a DEFAULT_TTL of 300 and I'd read that as the effective value. It only applies when a caller passes nothing, and the TMDB client always passes.

And the failure itself, end to end. This was an earlier TV run on the same clone, which finished at 439.07MiB rather than the 434.04 above, so the two are separate runs and not the same numbers. From that state I ran a Sonarr scan:

14:25:20  Full Scan Complete            (TV only, heap 439.07MiB of 524)
14:34:13  sonarr-scan triggered
14:36:51  FATAL ERROR: Ineffective mark-compacts near heap limit

2m38s in, ExitCode=1, OOMKilled=false. So the composition is the thing, and it is not really about the fetch spike. The scan doesn't kill anything by itself, it just ends holding most of the ceiling, and then the next scheduled job has nowhere to go.

For what it's worth on my actual box rather than the clone, idle, five hours after a restart, no job running:

used_heap 451.99 MiB   total_heap 469.76 MiB   limit 524.00 MiB

86% of the ceiling doing nothing. That is the state every scheduled scan starts from, which is why raising mem_limit only ever bought me a few days.

So to answer which of the two you should pick, I think it is the cache rather than the fetch. Capping it is the fix that matters, and maxKeys alone won't do it since node-cache throws ECACHEFULL on set rather than evicting, which is the swap you already flagged. Trimming what getTvShow stores would also work, since the scanner only needs a small part of that payload and the 12 hour TTL means a whole library's worth of aggregate_credits sits there for half a day.

Happy to test whichever way you want to go, and happy to run any of the above again if you want a number I haven't taken.

AI disclosure, same as the issue: assistant helped with the writing and reading the code, the measurements are mine.

[fallenbagel]

Thanks for running that down.

I guess I was right. It is the getTvShow, and the you're right on the 12h TTL (I glossed over it). Good catch on the non-English trailer fallback in the same function passes 43200 too, so a non-en locale caches two entries per show.

However, from your report, two things don't check out though:

• mean entry 88.5 KiB can't sit next to largest sampled 48,841 bytes. 88.5 KiB is 90,624 bytes, bigger than the max you sampled. Can you rerun that one? Sizing any cap depends on the real per-entry number and right now I can't tell what it is.
• Your claim "heap cost is roughly double because useClones is on" doesn't match the source either. _wrap clones once on write, _unwrap clones again on read, so what's retained is one copy. The second clone only exists transiently for the caller. Your 1.93x heap-to-JSON ratio is just normal V8 object overhead.

On the two fixes you proposed, capping the cache is the one to do and not trimming what getTvShow stores because that entry is shared. routes/tv.ts feeds the full response straight into mapTvDetails for the /tv/:id page, routes/media.ts reads external_ids off it separately, and the subscribers and availability sync all call the same function. Cutting fields will break the detail page. What might actually work is a second, narrower call for the scanner path only, append_to_response trimmed to what the scanner needs, under its own cache key so it doesn't collide with the full one. I will have to check on that.

Also cache vs fetch isn't really either/or. Sure fixing the cache buys back the residue, but an 80MiB Radarr/Sonarr payload still costs roughly double that in transient heap on the way in, since axios buffers, concatenates, stringifies and parses before any of it lands as a normal object. That might still be fatal on a small enough ceiling even with the cache fixed, so I'll have to check on that too.

Eitherways, I think I'll go ahead with the scanner-specific TMDB call, a cap on the tmdb cache, and the streamed fetch for Radarr/Sonarr fix and see if it's any better for you. Will let you know once I have it working

[nickwolf]

You're right on both, and the mean was the one to re-run.

This time it's every key rather than a sample, taken on the production instance while idle. Each entry sized with Buffer.byteLength(JSON.stringify(entry.v)) read straight off the internal store, so nothing gets cloned on the way out:

n                    2,013
total          183,248,800 bytes   (174.76 MiB)
mean                91,033
min                  2,248
p25                 33,166
median              59,246
p75                104,082
p95                272,227
max              2,942,650

The mean holds up. The max was the broken figure: 48,841 came from a bounded sample that I reported as though it were the largest, and it sits below the median of the full set. What the sample hid is how skewed this is. The mean is 91,033 against a median of 59,246, and 337 of the 2,013 entries hold half the bytes.

For what it's worth the total also lines up with the clone I measured earlier in the thread, 175.09 MiB over 2,025 keys against 183,248,800 bytes over 2,013 here, so 90,664 bytes mean there and 91,033 here. Different instance, different day, 0.4% apart.

On useClones you're right and I was wrong. _wrap clones on write, _unwrap clones on read, and the read clone belongs to the caller, so one copy is retained. The 1.93 is heap against JSON text and I shouldn't have put a mechanism behind it.

The tail is aggregate_credits, which matters for sizing a cap. Five largest entries, with the cast and crew counts from the same objects:

2,942,650 bytes    27 seasons     545 eps    7,551 cast    404 crew
2,776,281          29 seasons     595 eps    7,610 cast    362 crew
1,393,863          25 seasons     508 eps    3,849 cast    213 crew
1,327,417          53 seasons   1,009 eps    2,749 cast    494 crew
1,185,626          24 seasons     466 eps    3,243 cast    247 crew

Median aggregate_credits.cast across all 2,013 entries is 50. So a long-running show carries a four-figure cast list and lands about fifty times the median entry.

One thing I did not expect, and it may matter more than the sizes. This cache was not filled by a library scan. The container had been up since 10:34:46Z with no scan run, and dating every entry from getTtl(key) - 43200000 puts 2,009 of the 2,013 inside one hour:

earliest set   2026-08-06T10:35:00.798Z
median set     2026-08-06T11:50:21.545Z
latest set     2026-08-06T11:52:49.333Z

The job covering that window is Media Availability Sync, which started at 11:00:00.050Z. So the daily availability sync populates the whole TV side of the cache by itself, 174 MiB of it, without any scan involved. plexguid was sitting at 3 keys the whole time, which is what made it obvious the Plex scanner had nothing to do with it. I had assumed the scans were the only path in and that is not right.

Which cuts at the plan a bit, so worth saying plainly: a scanner-specific call with a trimmed append_to_response wouldn't have stopped any of this, because no scanner was involved. Whatever narrow call you add would need to cover the availability sync path as well, or the cache still fills to the same place once a day.

On the cap, sizing it by key count is awkward either way. Near the mean it still admits a 2.8 MiB entry, and low enough to exclude the tail it evicts most of what the cache is for. Sizing on bytes would bound it properly, but node-cache won't tell you: its own vsize stat reports a flat 3,200 per key here regardless of contents, so it can't be used for this.

Two notes on the measurement itself. It didn't disturb what it was reading, used_heap_size was 452.59 MiB before and 452.78 MiB after against the 524 MiB limit, both after two forced collections. And the TTL check still reads 12 hours, 23,316 seconds remaining on a sampled key out of 43,200.

AI disclosure, same as the issue: assistant helped with the writing and reading the code, the measurements are mine.

[fallenbagel]

Pushed a preview build with a possible fix: preview-tmdb-cache-tier. Since you have a daily repro, testing it against your instance would be more useful than anything I can measure here.

Scanners and availability sync now request only keywords,external_ids instead of the full append list, and write to their own cache with a 15 minute TTL rather than sharing the interactive one at 12 hours. Both TMDB caches are also LRU-bounded now instead of growing without a cap, and aggregate_credits.crew / credits.cast are stripped before caching since nothing reads them.

Heap snapshots on my instance:

	before	after
idle	110 MB	107 MB
post-scan	270 MB	124 MB
+30 min, forced GC	269 MB	121 MB

~159 MB retained before, ~14 MB after. Both runs did the same work (since i forgot to take screenshots let me just jot them down): 482 lookups and 33 cache hits either way, so that is the same set of shows resolved in both cases. With the fix run all 482 went to the scan tier and the interactive cache (manual browsing one now tracked separately) stayed empty, and the scan tier drained to 11 keys thirty minutes later, which indicates that the TTL is doing its job properly.

[nickwolf]

It works. The nightly failure is gone on my instance, and the retention it was blamed on is gone with it.

Same sequence on both arms from a fresh container: restart, idle probe, trigger Media Availability Sync, probe, wait 30 minutes, probe, then a Sonarr scan. Heap is used_heap_size after two forced collections over CDP.

                              69f73a6 (latest)   45f78ca (preview)
idle after restart               99.68 MiB          98.83 MiB
after availability sync         451.22 MiB         128.47 MiB
+30 min, forced GC              452.63 MiB         116.01 MiB
Sonarr scan from that state      died at 2m28s      completed in 4m46s

The sync took 810s on latest and 840s on the preview, so both arms did the same work. After it, the tmdb cache on latest holds 175.03 MiB of JSON against 7.29 MiB in tmdbscan on the preview, and the scan tier had drained to zero keys by the 30 minute probe. The Sonarr scan is the job that has aborted here on each of the last five nights: on latest it started at 23:14:10 and hit FATAL ERROR: Reached heap limit at 23:16:38, and on the preview it started at 01:55:29 and logged Sonarr scan complete at 02:00:15 with the heap at 115.47 MiB afterwards.

One caveat on that last row. The preview scan started from 116 MiB rather than 452 MiB, so it shows the composition broken, not the fetch spike getting cheaper. Both probes are post-completion, so I have nothing on the transient getSeries() parse cost you were worried about. Say the word and I will probe inside the first twenty seconds of a scan.

TMDB_SCAN_MAX_KEYS assumes 12 KiB per entry. The narrow entries here run a median of 3,310 bytes with a largest of 54,664, so the 2,730 key cap is worth about 8.6 MiB rather than the 32 MiB it is written for. Tighter than you meant, no problem for me.

TMDB_MAX_KEYS is still a count rather than bytes. At the 91,033 byte mean I measured earlier in this thread a full interactive cache is about 87 MiB of JSON, so roughly 168 MiB of heap at the 1.93 ratio from the flush test, which I am not putting a mechanism behind. Nothing but browsing fills that tier now, so I doubt it matters.

On the strip: /api/v1/tv/1399 returns 587 cast and 35 crew, /api/v1/tv/82856 returns 159 and 34. On your branch credits.crew is what feeds models/Tv.ts:219 and it is kept, and I found no read of aggregate_credits.crew or credits.cast. Media status counts in the database moved by single digits over the run, so the narrower payload is not making the sync misjudge availability.

Two things about my setup. My Plex full scan is weekly rather than daily, left over from working around this, so the preview arm never had scan traffic sitting on top of the sync. And I had a cron restarting the container before the nightly job block, which I have now taken off, so tonight's unattended 04:00, 04:30 and 05:00 run starts from whatever the day leaves behind. I will report back with that and with a longer soak.

AI disclosure, same as the issue: assistant helped with the writing and with reading the code, the measurements are mine.

[fallenbagel]

Thank you, and I appreciate you running this and testing it on real hardware. Your table is pretty helpful. Seeing it die at 2m28s pre-patch and complete in 4m46s with my fix, from the same starting state, is pretty strong evidence that my fix addresses the issue.

Both probes are post-completion, so I have nothing on the transient getSeries() parse cost you were worried about. Say the word and I will probe inside the first twenty seconds of a scan.

Appreciate the offer, but I don't think it's needed. The thing that decision was waiting on was whether the spike is still fatal with headroom back, and a completed scan answers that question tbh.

However, I still wanted to ask, TMDB_SCAN_MAX_KEYS assumes roughly 12 KiB per entry, and your measurement puts the real median at 3,310 bytes. You called that "no problem", but can you walk me through the reasoning there? I'm more interested in how you arrived at that conclusion than the conclusion itself.

Separately, and I'd rather say this plainly now than let it sit unsaid, our contributing guide is pretty strict about AI-assisted comments needing to be in your own words and based on reasoning that you actually understand, rather than relaying an assistants answer. The "“meat proxy” section" is what I'm referring to here.

Disclosing that an assistant helped with the writing doesn't change that requirement. Disclosure does not exempt a submission from the policy above it, and it is more about the transparency and how much scrutiny we can apply, rather than making a relayed reasoning acceptable.

I'm not accusing you of anything here, but you did say on #3308 (comment) that a PR there would be "AI driven" if you took it on, so I just wanted to be upfront about where our line is rather than assume you already know it. If disclosure alone were enough, there wouldn't really be much point in having you in the thread, and I could just ask the model myself.

That said, the measurements and the testing you're doing are genuinely valuable, and that's not in question. I was more so specifically emphasising on the reasoning around those measurements that needs to be yours going forward.

Thank you.