Adding a single podcast episode to an existing playlist can take down the entire Audiobookshelf server:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

The user who reported this has a podcast library with around 2,600 items. Adding one episode to an existing playlist ate through 8 GiB of heap and crashed; systemd logged a 12.4 GiB memory peak before the core dump. Creating a brand new playlist with the same episode? Instant, no problem. The bigger the library, the longer (and hungrier) adding to an existing playlist gets.

A contributor took the reporter’s database and reproduced it: “It looks like the issue is due to /api/playlists/:id/batch/add loading the entire podcast into memory to add the single episode to a playlist (this is a problem with a number of podcast related queries that probably needs to be cleaned up).”

You can see why in server/controllers/PlaylistController.js. The addBatch handler loads each library item with findAllExpandedWhere, and the “expanded” include tree pulls in every podcastEpisode row the podcast has. For a podcast with thousands of episodes, that’s thousands of rows hydrated into memory to add one of them. The V8 stack trace in the report dies inside the JSON parser, which lines up: Sequelize parses JSON columns on every row it hydrates, and at that row count the allocations pile up faster than the garbage collector can keep clearing.

Why creating a playlist works but adding to one doesn’t

The create endpoint takes the lean path. When you make a new playlist, the server only selects four columns per item (id, mediaId, mediaType, libraryId) and validates episode IDs with a bare ID lookup. No episode bodies, no expanded metadata. That’s why a fresh playlist with the same episode is fast.

addBatch is the heavy path, and it’s also what the web UI calls when you use “Add to playlist” on an item. So the workaround options below are mostly about staying off that path until the fix lands.

Fix 1: give Node more heap

The blunt workaround, confirmed by the reporter, is raising Node’s heap cap with NODE_OPTIONS. In their case 8 GiB was not enough; 16 GiB worked:

# docker-compose.yml
services:
  audiobookshelf:
    environment:
      - NODE_OPTIONS=--max-old-space-size=16384  # heap cap in MiB

For a native install managed by systemd:

sudo systemctl edit audiobookshelf

[Service]
Environment="NODE_OPTIONS=--max-old-space-size=16384"

Then restart the service. Two caveats. The flag only raises the ceiling, so your machine needs the RAM (or swap) to back it, and pick a number that fits the box. And it doesn’t make the operation cheap: even with 16 GiB the reporter saw a single add take more than 10 seconds. It stops the crash, that’s all.

Fix 2: build a new playlist instead of growing an old one

Since creating a playlist takes the lean path, you can sidestep the crash by batch-selecting everything you want (the episode checkboxes in the web UI) and creating a new playlist in one go, rather than adding items to an existing playlist one at a time. Awkward if you maintain a long-running playlist, but it’s free and it works on any version.

The actual fix is an open PR

PR #5145 (“Playlist podcast add cleanup”), open since March 23, 2026, fixes this properly: it filters the query by the requested episode IDs so only the relevant episodes get loaded, instead of the whole podcast. The reporter tested it the same weekend and said it works, and confirmed in May that “these patches still apply flawlessly to the current release 2.35.1 (and even git main)”.

It hasn’t been merged, so it’s not in any release as of v2.35.1. If you build Audiobookshelf from source you can apply the PR’s patch to your checkout and rebuild. That’s an unofficial route; for everyone else, watch the PR and update when it ships in a release.

The same unpaginated-playlist design shows up elsewhere: issue #2177 reports the Playlists tab on a podcast library hanging the server for over a minute. If playlists plus podcasts are slow for you in general, it’s the same family of problem.

Same error, different cause: check where your database lives

One user in the thread had similar symptoms (server unresponsive for 20 to 40 minutes on basic actions with about 2,300 books) that turned out to be something else entirely: their SQLite database was sitting on a NAS. Moving it back onto the machine running the server fixed it. A contributor was blunt about the setup: “Storing the database on a different device is not supported and will eventually corrupt your database.”

Audiobook files on a NAS are fine. The config directory with the database should be on local disk. If that’s your setup, the slow library scans post and the storage advice in the frequent logouts post cover the same ground from other angles.

Affected versions

The reporter hit this on v2.33.0 and said it had been happening “over several releases” before that. The heavy query path is still in place as of v2.35.1, the latest release at the time of writing, so any current version with a large podcast library can hit it. The fix arrives whenever PR #5145 merges and ships.