Server Version#: 1.43.2.10687
TL;DR: On my server the play_queue_items table’s AUTOINCREMENT counter reached INT_MAX (2,147,483,647). Once it does, every attempt to start playback fails because PMS can’t insert the next play-queue row. The client shows “An error occurred loading items to play,” and the server returns HTTP 500 on POST /playQueues. integrity_check passes, a database rebuild does not fix it, and the only real fix is to clear the transient play-queue tables and reset their sqlite_sequence counters. Posting in case it helps others — several “just restore an old backup / rebuild from scratch” reports are probably this. I also suspect a separate bug inflated that counter in the first place (see below) — 2 billion is not a realistic organic number.
Symptoms
- Playing anything (any movie, episode, library, client, local or remote) fails instantly with “An error occurred loading items to play.”
- It is server-side. In
Plex Media Server.logevery play attempt looks like this:
DEBUG - Request: [...] POST /playQueues?type=video&...&uri=server://<machine>/com.plexapp.plugins.library/library/metadata/<id>...
DEBUG - [Req#xx] PlayQueue: Converted '...' to 'library://x/item/...'
DEBUG - [Req#xx] PlayQueue: Start index: 0 End index: 0 Count: 1
ERROR - Got exception from request handler: std::exception
DEBUG - Completed: [...] 500 POST /playQueues ...
The item is found and counted, then it throws. The log only ever shows the generic std::exception.
- Browsing, scrobbling (mark watched), and creating playlists all still work — only play-queue creation fails. (Playlists use a different table whose counter hasn’t overflowed.)
Environment where I hit it
- PMS 1.43.2.10687 (Docker,
plexinc/pms-docker), but this is version-independent — it had been broken across several version updates.
Root cause
The real exception is hidden behind the generic std::exception in the log. By attaching gdb and catching the throw, the actual exception is:
DB::Exception: "Last row ID 2147483648 is greater than INT_MAX"
2147483648 = 2³¹ = INT_MAX + 1. PMS uses 32-bit signed integers for row IDs. The play_queue_items AUTOINCREMENT counter had reached exactly 2147483647, so the next insert (which happens on every play action) is rejected.
You can confirm it directly (server can be running for this read):
"Plex SQLite" "com.plexapp.plugins.library.db" \
"SELECT name, seq FROM sqlite_sequence WHERE name IN ('play_queue_items','play_queue_generators','play_queues');"
If play_queue_items is at (or extremely close to) 2147483647, this is your problem. For reference, on my server play_queues and play_queue_generators were only at ~980, while play_queue_items was pegged at exactly 2147483647.
How did the counter get to 2 billion?? (likely a separate bug)
This is the part I think Plex should look at. ~2.1 billion play_queue_items inserts is not a realistic number for organic use. Play queues are created when you press play, add to queue, shuffle, or when “up next”/Continue Watching is regenerated — but even a busy household generates maybe thousands of these per day, i.e. low millions over years. To burn through 2³¹ AUTOINCREMENT values you’d need on the order of hundreds of millions of inserts per year — thousands per minute, continuously.
That strongly implies that at some point a runaway loop or buggy background task was hammering inserts into play_queue_items (e.g. continuously regenerating play queues), rapidly consuming the ID space. The INT_MAX failure is just the eventual consequence. The overflow is easy to fix (below), but the thing that consumed 2 billion IDs is the more interesting underlying bug, and it could silently recur. If anyone else hits this, it’d be worth noting your server’s age and whether the other play-queue counters (play_queues, play_queue_generators) are also unexpectedly high, to help pin down the runaway producer.
Why the usual advice does NOT fix it
This one is sneaky because the standard troubleshooting steps all fail:
PRAGMA integrity_checkreturnsok. It’s a value overflow, not structural corruption, so integrity checks are clean.- Rebuilding the database (the official
.dump→ reimport repair) does NOT help —.dumpfaithfully reproduces thesqlite_sequencetable, so the overflowed counter is carried straight into the rebuilt DB. DELETE FROM play_queue_itemsdoes NOT help — deleting rows does not reset an AUTOINCREMENT counter;sqlite_sequencekeeps its high-water mark.- Restoring a much older backup appears to “fix” it — but only because an old enough backup predates the counter crossing 2³¹. It comes back as the counter climbs again. (I suspect this is what several threads here actually experienced.)
The fix
Play queues are transient/regenerable, so it’s safe to clear them and reset the counters. Stop PMS first, then:
DELETE FROM play_queue_items;
DELETE FROM play_queue_generators;
DELETE FROM play_queues;
UPDATE sqlite_sequence SET seq = 0
WHERE name IN ('play_queue_items','play_queue_generators','play_queues');
Run it with the bundled Plex SQLite against com.plexapp.plugins.library.db (back up the DB first, and delete the -wal/-shm files after). Start PMS — playback works immediately.
(Docker users: run Plex SQLite via a one-off container, e.g.
docker run --rm --user <PUID>:<PGID> --entrypoint sh -v /your/config:/config <plex-image> -c '"/usr/lib/plexmediaserver/Plex SQLite" "/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db" "<sql above>"')
Suggested PMS-side fixes
- Find/fix whatever can drive
play_queue_itemsinserts into the billions — that’s the real bug; the overflow is downstream. - Use 64-bit row IDs for the play-queue tables, or auto-reset the play-queue
sqlite_sequencewhen it nearsINT_MAX(these tables are disposable, so an automatic reset is safe). - At minimum, surface the
DB::Exceptionmessage (“Last row ID … greater than INT_MAX”) in the server log instead of a barestd::exception, so this is self-diagnosable without a debugger.
