diff --git a/core/spotify_client.py b/core/spotify_client.py
index 90c2f336..322e9021 100644
--- a/core/spotify_client.py
+++ b/core/spotify_client.py
@@ -63,9 +63,15 @@ _rate_limit_first_hit = 0    # Timestamp of the first hit in the current escalat
 _LONG_RATE_LIMIT_THRESHOLD = 60  # seconds
 
 # After a ban expires, wait this long before making any auth probe calls.
-# This prevents the "immediate re-probe → re-ban" cycle where Spotify's server-side
-# cooldown outlasts the Retry-After value they sent us.
-_POST_BAN_COOLDOWN = 300  # 5 minutes
+# This prevents the "immediate re-probe → re-ban" cycle where Spotify's
+# server-side cooldown outlasts the Retry-After (or our default ban
+# duration) we used. A user who'd just sat through a 4-hour MAX_RETRIES
+# ban had it expire, hit our 5-minute cooldown, made a single
+# get_artist_albums call 32 seconds after the cooldown ended, and got
+# slapped with another 4-hour ban — the post-ban cooldown was too short
+# for Spotify's server to forget the previous offense. 30 minutes is a
+# better empirical floor; can be revisited if reports persist.
+_POST_BAN_COOLDOWN = 1800  # 30 minutes
 
 # Escalation: if we get rate limited again within this window, increase ban duration
 _ESCALATION_WINDOW = 3600   # 1 hour — if re-limited within this, escalate
diff --git a/webui/static/helper.js b/webui/static/helper.js
index 9e65a2f8..e559977d 100644
--- a/webui/static/helper.js
+++ b/webui/static/helper.js
@@ -3443,6 +3443,7 @@ const WHATS_NEW = {
     '2.40': [
         // --- Search & Artists unification (in progress, not yet released) ---
         { date: 'Unreleased — Search & Artists unification', unreleased: true },
+        { title: 'Spotify: Longer Post-Ban Cooldown (30 min)', desc: 'A user reported their Spotify rate-limit ban expired after 4 hours, the system ran its 5-minute post-ban cooldown, and then 32 seconds after the cooldown ended a single get_artist_albums call from a background worker was hit with another 4-hour ban. Diagnosis: Spotify\'s server-side memory of the previous offense outlasted our 5-minute cooldown, so the very first call after cooldown got slapped immediately. The cooldown exists specifically to prevent the "ban expires → we probe → re-ban" cycle, but the value was too short. Bumped from 5 minutes to 30 minutes — same mechanism, just enough room for Spotify to actually forget. A more principled follow-up (adaptive cooldown that scales with the previous ban size, plus making the first post-cooldown call a single light probe rather than allowing background workers through) is documented as a future PR if reports persist after this bump', page: 'dashboard', unreleased: true },
         { title: 'Tidal: Reject Silent Quality Downgrades', desc: 'Netti93 reported that with Tidal set to "HiRes only" and quality fallback disabled, tracks were still downloading successfully — as m4a 320kbps files. Root cause: Tidal\'s API silently serves whatever tier your account + the track + your region permits. Ask for HI_RES_LOSSLESS on a track that\'s only in LOW_320K and Tidal returns the AAC stream without raising. The downloader wrote the m4a to disk, the filesize cleared the 100KB stub threshold, and the download reported success. The worker-level fallback chain (hires → lossless → high → low) also never got a chance to advance, because every tier "succeeded" at the first one that returned anything. Fix: after getting the stream, compare stream.audio_quality against what we requested using a rank-based tier comparison (LOW < HIGH < LOSSLESS < HI_RES < HI_RES_LOSSLESS). Same tier or better = accept (so occasional Tidal upgrades don\'t get thrown away). Lower tier = treat this tier as failed, which lets the fallback chain advance when fallback is enabled or fails the whole download honestly when the user has "HiRes only, no fallback" configured. Unrecognized audioQuality values (a new Tidal tier we haven\'t mapped yet) are rejected conservatively so the final diagnostic log can name the unknown value. Older tidalapi builds without the audio_quality attribute fall through to the pre-existing codec / file-size guards so nothing regresses', page: 'downloads', unreleased: true },
         { title: 'Search Source Picker Icon Row', desc: 'The Search page now has a row of source icons above the search bar — one per source (Spotify, Apple Music, Deezer, Discogs, Hydrabase, MusicBrainz, Music Videos, Soulseek). Typing searches only the currently-selected source instead of fanning out to every one by default. Click a different icon to switch; results come back on demand. The default icon on page load is your configured primary metadata source. Replaces the short-lived "Search from" dropdown that preceded this', page: 'search', unreleased: true },
         { title: 'Per-Query Source Cache (No More Re-Fetching)', desc: 'Once you\'ve searched a source for a given query, switching back to it is instant — results are cached for the current query. A small dot on each source icon shows which ones already have cached results this query. Type a new query and the whole cache resets. Same behavior in the sidebar global search popover. Net effect: roughly 6-7x fewer API calls per search compared to the old default fan-out', page: 'search', unreleased: true },