DEV Community: Christian Anderson

Your Spotify playlist reader isn't broken. It's reading a boolean.

Christian Anderson — Sat, 05 Sep 2026 07:23:16 +0000

If you have written anything against the Spotify Web API in the last two years, some of
your code is quietly wrong right now — and the failure mode is not an exception. It is a
function that returns [] and looks fine.

I hit this building two headless tools against the API. Everything below was measured
against the live API, not read in a changelog.

First: there were two events, and everyone conflates them

Almost every "Spotify API is broken" post on the internet blames one date for both. I did
this myself, in a README, and had to correct it before publishing. They are unrelated:

27 November 2024 — removals. /recommendations, /audio-features,
/audio-analysis, /related-artists, and the 30-second preview URLs. This is when the
data died. Every "build a playlist generator with audio features" tutorial dates from
before this and cannot work.

February 2026 — renames and trims. Nothing was deleted for good reasons here; things
moved, and limits tightened. This is when working code started failing without saying so.

If you are debugging a missing energy or tempo field, that is the 2024 event and it is
never coming back. If you are debugging an endpoint that used to work last year, read on.

The rename that costs you an afternoon

The paths moved:

Was	Now
`GET /playlists/{id}/tracks`	`GET /playlists/{id}/items`
`GET /users/{id}/playlists`	`GET /me/playlists`
library operations	`/me/library`

That part is annoying but loud — you get an error, you fix the URL, you move on.

The part that isn't loud: the row field renamed too.

Inside each row of the response, item["track"] became item["item"]. And here is the
bit that makes it expensive:

"track" did not disappear. It survives as a boolean.

So this code does not crash:

# looks fine, has always worked, now returns nothing
tracks = []
for row in resp["items"]:
    t = row.get("track")
    if not t or not t.get("id"):   # <-- t is now `True`
        continue                    #     True.get() never runs; `not True` is False...
    tracks.append(t["id"])          #     ...so this raises, or your lenient
                                    #     version skips every row silently

Depending on how defensive your reader is, you get one of two outcomes:

a strict reader raises AttributeError: 'bool' object has no attribute 'get'
a lenient reader — the common case, because everyone wraps this in a try — concludes the playlist is empty

An empty playlist is not an error. Your sync job runs, reports success, and writes
nothing. That is the whole problem with this particular change: it converts a rename into
a silent data loss.

The fix is trivial once you know:

t = row.get("item") or row.get("track")
if not isinstance(t, dict):
    continue

Artist genres are gone if you are in Development Mode

This one has no announcement I could find, and it is absolute:

batch GET /artists?ids=... returns 403
single GET /artists/{id} returns an artist object with no genres key at all

Note that second one carefully. It is not "genres": []. The field is absent. So a
.get("genres", []) gives you an empty list and you tag every artist unknown without
ever noticing the capability is gone.

If you were tagging or grouping by genre, that is dead for dev-mode apps. In my case the
only tag still derivable from the remaining metadata was release decade, so decade became
the default and genre tagging now raises an explicit error rather than silently labelling
the whole library unknown. Fail loudly on a capability you no longer have. Do not
let it degrade into a plausible-looking result.

The limits also moved, quietly

search limit is capped at 10. It was 50. Requests for more do not error — you just get 10, so pagination logic built on 50 silently under-fetches.
popularity is stripped from responses.
Premium is now required for playback.
Development Mode user allowlists dropped from 25 to 5.

That last one is worth dwelling on if you were planning to ship something. Between a
5-user allowlist, Premium being mandatory, and Extended Quota gated behind 250k MAU,
there is no path from "weekend project" to "product" here any more. Self-hosted script is
the realistic ceiling. Better to know that before you build a billing page.

403 means "removed", not "you lack a scope"

Removed endpoints answer 403, not 404. This one is already documented in several
places, so I will keep it short — but the practical rule saves real time:

Before you go re-reading the scopes documentation, check whether the path still
exists. A 403 on the Spotify API is far more often a dead endpoint than a permissions
problem.

The one that actually hurt: the quota window re-arms while you are throttled

This is the finding I would most want to have known in advance.

When you hit the daily quota you get a 429 with a Retry-After. I measured one at
82,510 seconds — roughly 23 hours. Fine. But then I kept making calls, and watched
Retry-After grow back toward 24 hours instead of counting down.

A client that retries in a loop can pin your app in a permanent 429 it never escapes.
Every retry pushes the window out again. The naive exponential-backoff loop you would
normally reach for is exactly the wrong tool.

What works is a circuit breaker that stops calling entirely:

# on 429: record an ABSOLUTE wake-up time and make no further calls until then
blocked_until = time.time() + int(resp.headers.get("Retry-After", 3600))
save(blocked_until)          # persist it — see below

Two traps in that ten-line fix, both of which I shipped wrong the first time:

Persist it, or a restart undoes it. If the process restarts it will happily call Spotify on boot and re-arm the window.
Persist the absolute timestamp, not the remaining seconds. I wrote an absolute epoch on save and read back remaining seconds on load. So a restored value of 3600 was interpreted as an epoch in 1970, the breaker computed a negative remaining time, concluded it was unthrottled, and called Spotify immediately — reproducing the exact bug it existed to prevent. The round trip has to agree with itself.

Also worth saying plainly: what exhausted my quota was bulk harvesting — paginating
120 deep across 40+ queries — not normal use. The architectural answer was to stop calling
the API on the hot path at all. A background thread tops up a local index inside a
token-bucket budget, and the user-facing action reads only from that index. It now serves
from 6,559 locally indexed tracks and makes zero API calls in the interaction path.

If your app calls Spotify in response to a user action, that is the design to move away
from.

The short version

Two separate events. 2024 removed the audio data; 2026 moved things and tightened limits.
row["track"] → row["item"], and track is now a boolean that will convince a tolerant reader your playlist is empty.
Artist genres is absent, not empty, for dev-mode apps.
Search limit silently caps at 10.
403 usually means the path is gone, not that your scopes are wrong.
Never retry a 429 in a loop. The window re-arms. Break the circuit and persist an absolute timestamp.

The two tools this came out of are MIT and on GitHub:
setlisted (headless playlist sequencing —
its test suite is fully offline, because the daily quota is genuinely exhaustible) and
spin-that-dice (the local-index
design described above).

I also wrote the whole thing up properly as a
6-page PDF, with a
2-page cheat sheet of just the renames if
that is all you need. Everything technical above is in the free repos too — the PDF just
saves you assembling it.

A dead GPU degrades gracefully. A working one crash-loops.

Christian Anderson — Sat, 05 Sep 2026 07:17:32 +0000

I put a used £30 Quadro P600 on a riser into a ZimaBlade, to accelerate machine
learning in Immich. It took months of intermittent debugging to get the PCIe link to
train.

Then I found out that fixing it would have broken the thing I was trying to speed up.

This is the write-up of both halves: the diagnostic method, which is reusable, and the
research I should have done first, which is the actual lesson.

The constraints nobody prints on the box

The ZimaBlade has a PCIe slot. What it does not have is a slot you can just use. From
lspci -vv on the root port:

LnkCap:  Speed 5GT/s, Width x4        # PCIe 2.0 x4, ~2GB/s ceiling
SltCap:  PowerLimit 25W               # slot budget
         HotPlug-                     # enumeration only at cold boot

Three things fall straight out of that:

25W slot budget. The P600 is a 40W card with no external power connector. It physically cannot be slot-powered here. You need a riser with its own 12V feed.
No hot-plug. echo 1 > /sys/bus/pci/rescan is theatre. If the card wasn't there at cold boot, it isn't there.
No Above-4G decoding. Every PCI window is sub-4GB, the largest about 1.25GB. Fine for a 2GB card with a ~256MB BAR aperture; a hard blocker for anything with real VRAM.

Also worth stating plainly, because the mining-riser marketing obscures it: a VER009S
riser is electrically x1, despite having an x16 slot on it. The USB3 cable is just the
physical medium, not the USB protocol. So the ceiling was PCIe 2.0 x1, roughly 500MB/s —
before anything went wrong.

And the stock ZimaBlade PSU is 12V/3A, 36W over USB-C. Board, RAM and two SATA disks
already eat 25–30W of that. There was never a version of this where the card ran off the
onboard supply.

The diagnostic worth stealing: presence detect

For a long time the link simply never trained — LnkSta: Width x0. The question that
matters when you have a card, a riser, a cable, a second PSU and a slot all in series is:
which end is at fault? You do not want to be swapping parts at random in a loft.

PCIe gives you a free answer. On every card, pins A1 (PRSNT1#) and B17 (PRSNT2#)
are shorted together on the card's own PCB. The host grounds A1 and pulls B17 high.
Seat a card, B17 gets pulled low through that short, and the slot reports PresDet+.

The useful property: this is pure DC continuity. It does not involve the data lanes, the
cable, the GPU, or the external supply. So:

SltSta: PresDet-   →  nothing is making contact in the slot. Stop.
                      Cable and ground theories are downstream and cannot be the blocker.
SltSta: PresDet+   →  the board is seated. The fault is further out.

Mine was flapping +/-, then went steady - — which told me the riser board was not
seated, and saved me from chasing driver and cable fixes for a mechanical problem.

I then over-read my own test, and it is worth admitting because it is the more useful
half. After reseating, PresDet read a solid + ten times running — and I briefly took
that as validating the whole chain. It doesn't. That A1↔B17 short is on the x1 board and
shorts two of the host's own pins inside the host's own ground domain. It reads + with
no cable and no GPU attached at all. It proves exactly one thing: that small board is in
the slot.

A test that can only pass tells you nothing. Know the narrowest claim your evidence
supports.

Two related rules that saved time:

Driver ≠ detection. lspci enumerates with no driver loaded; a driver only binds to an already-enumerated device. No driver install can make an undetected card appear. Don't debug drivers while the width is 0.
A spinning fan proves 12V and nothing else. It says nothing about data lanes.

It worked. Then it died 8.5 hours later.

The physical work eventually paid off. The card enumerated, the link trained, the
proprietary driver bound cleanly at boot, all four /dev/nvidia* nodes appeared.

Then, 30,709 seconds after boot:

NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from
      0x0 (None) to 0x1 (GPU Reset Required)

Xid 79 is textbook power-delivery or PCIe signal integrity. The corroborating evidence
was already in lspci:

LnkSta:  Speed 2.5GT/s (downgraded), Width x1 (downgraded)
DevSta:  CorrErr+ NonFatalErr+ UnsupReq+

Negotiated down to PCIe 1.0 x1 — below even the riser's own x1-at-5GT/s ceiling — and
the root port actively logging correctable errors. A link that trains but negotiates below
the worst thing in the chain is telling you the physical layer is marginal, not that it
works.

The prime suspect was a ground offset: the ZimaBlade on a floating two-pin 12V brick, the
GPU on an earthed ATX supply, the two domains bonded only through the thin ground wires in
a USB3 cable. PCIe receivers have a narrow common-mode range. That single theory predicts
all three observations — presence detect fine (internal domain), fan spinning (ATX 12V
present), lanes marginal (cross-domain signalling). Mining rigs solve this with tied PSU
grounds for exactly this reason.

One correction I had to publish against my own earlier notes: the ZimaBlade's power input
is USB-C, not a barrel jack. Every "pigtail it off a Molex" instruction I had written was
wrong. And be aware the SATA-to-6-pin adapters that ship in VER009S kits are a genuine fire
hazard — use proper Molex or PCIe leads.

The part that makes the whole project pointless

Before re-energising the card, I finally went and read what Immich v3 actually supports.

Immich v3 dropped machine-learning support for Maxwell and Pascal. ONNX Runtime no
longer ships kernels for compute capability 5.2 / 6.1. The P600 is Pascal GP107, compute
6.1.

The failure mode is the whole point:

The v3.x-cuda ML container does not print a helpful message and fall back. It dies on
exit 132 — SIGILL, an illegal instruction, and Docker restarts it forever.

Now compare that to the situation I was trying to escape. With the GPU dead, the container
logs CUDA failure 100: no CUDA-capable device is detected, falls back to
CPUExecutionProvider, and smart search and face recognition keep working — just slowly.

The broken state degraded gracefully. The fixed state would have crash-looped. Every
hour I spent on that riser was moving the system from "unaccelerated but working" to "down".

The cliff isn't only Immich, either. Driver branch 580 is the last one supporting
Maxwell, Pascal and Volta. cuDNN dropped them at 9.11 — 9.10.2 is the last usable
release. Three separate vendors retired that generation inside about a year.

That is the real reason a £30 used Quadro is a worse deal than the price suggests. You are
not buying a slow GPU. You are buying a component with an announced end date on every
software layer above it, and you find out by reading release notes, not benchmarks.

What I'd tell myself at the start

Check the software cliff before the hardware. One afternoon reading ONNX Runtime and driver release notes would have cancelled the project before I bought the card. Hardware debugging is absorbing and feels like progress; compatibility research is boring and decides whether the work is worth doing at all.
Graceful degradation can invert. "It's broken but working around it" is sometimes a better state than the fix. Ask what happens after success before you chase it.
Know the narrowest claim your evidence supports — my presence-detect test was sound and I still over-read it.
A link that negotiates below the worst component in the chain is a physical-layer warning, not a success.

The honest ending: the card is still dead, and I am no longer in a hurry to fix it. If I
do, it will be pinned to the last ML image that supports the architecture, or used purely
for NVENC transcoding — a fixed-function encoder, unaffected by any CUDA kernel cliff.

The full write-up, with the complete lspci output, the diagnostic decision tree and a
read-only script that runs every check above in one pass, is free and MIT on GitHub:
casareanderson/zimablade-gpu-immich.
There is a packaged copy on Gumroad if you'd
rather have it as one download — pay what you want, including nothing.

Every command output quoted here was captured from the running machine. The build is
documented at the point where the fault is understood and the cable has not yet been
replaced.