diff --git a/android/app/src/main/java/com/remotedisplay/player/MainActivity.kt b/android/app/src/main/java/com/remotedisplay/player/MainActivity.kt
index 97eedce..d9b9039 100644
--- a/android/app/src/main/java/com/remotedisplay/player/MainActivity.kt
+++ b/android/app/src/main/java/com/remotedisplay/player/MainActivity.kt
@@ -503,11 +503,33 @@ class MainActivity : AppCompatActivity() {
             runOnUiThread {
                 val why = wsService?.lastRejectionReason ?: ""
                 val blocked = why.contains("block", ignoreCase = true)
-                Log.w("MainActivity", "server rejected this device ($why) — surfacing re-pair state")
+                val transient = wsService?.lastRejectionTransient == true
+                Log.w("MainActivity", "server rejected this device ($why, transient=$transient)")
                 showStatus(
                     if (blocked) getString(R.string.device_blocked_status)
                     else getString(R.string.device_unpaired_status)
                 )
+
+                // A TRANSIENT rejection (the reclaim-settle hold: "retry after N seconds") is one
+                // the service recovers from by itself — it holds, retries once and comes back. Tear
+                // nothing down for it. The previous handler did the opposite: it wiped the offline
+                // playlist cache and jumped to provisioning on every rejection, so a self-healing
+                // hold cost the panel its cache and forced a full re-download after re-pairing.
+                //
+                // A terminal rejection means this device really is gone from the server, and the
+                // operator needs the pairing code, so provisioning is right. The cache is kept
+                // either way: it is what lets the screen keep showing content while someone walks
+                // over to re-pair it, and re-pairing restores the settings anyway.
+                if (!transient && !blocked) {
+                    handler.post {
+                        startActivity(Intent(this@MainActivity, ProvisioningActivity::class.java).apply {
+                            addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK or Intent.FLAG_ACTIVITY_NEW_TASK)
+                            // Server-initiated re-pair (known-good URL): show the code, not URL entry.
+                            putExtra("EXTRA_REPAIR", true)
+                        })
+                        finish()
+                    }
+                }
             }
         }
 
@@ -853,19 +875,6 @@ class MainActivity : AppCompatActivity() {
             ackedContent.clear()
         }
 
-        wsService?.onUnpaired = {
-            Log.w("MainActivity", "Device removed from server, going to provisioning for re-pair")
-            config.clearPlaylistCache()
-            handler.post {
-                startActivity(Intent(this, ProvisioningActivity::class.java).apply {
-                    addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK or Intent.FLAG_ACTIVITY_NEW_TASK)
-                    // Tell provisioning this is a server-initiated re-pair (known-good URL) so it
-                    // shows a "waiting for re-pair" status + the code instead of the URL entry.
-                    putExtra("EXTRA_REPAIR", true)
-                })
-                finish()
-            }
-        }
     }
 
     // Root-2 content-ack de-dup. Re-acking content state (SEED-A) fixes the CMS "stuck downloading"
diff --git a/android/app/src/main/java/com/remotedisplay/player/service/WebSocketService.kt b/android/app/src/main/java/com/remotedisplay/player/service/WebSocketService.kt
index 24ddb9d..f0e7cdf 100644
--- a/android/app/src/main/java/com/remotedisplay/player/service/WebSocketService.kt
+++ b/android/app/src/main/java/com/remotedisplay/player/service/WebSocketService.kt
@@ -737,6 +737,12 @@ class WebSocketService : Service() {
      * and sent people off debugging their network. #234.
      */
     @Volatile var lastRejectionReason: String? = null
+    /**
+     * True when the last rejection came with a settle window — the server is asking us to wait and
+     * try again, not telling us we are gone. This service already holds, retries once and recovers
+     * on its own, so a listener must not tear the player down over it.
+     */
+    @Volatile var lastRejectionTransient: Boolean = false
         private set
     /** Milliseconds left in the reclaim-settle hold (0 once elapsed) — drives the UI countdown. */
     fun repairHoldRemainingMs(): Long = maxOf(0L, repairHoldUntilMs - SystemClock.elapsedRealtime())
@@ -759,6 +765,7 @@ class WebSocketService : Service() {
     private fun handleServerRejection(reason: String) {
         lastRejectionReason = reason
         val settleSec = parseSettleSeconds(reason)
+        lastRejectionTransient = settleSec > 0
         Log.w("WebSocketService", "Server rejected device ($reason) — settle=${settleSec}s")
         pairingCodeLive = false // this registration was rejected — the local code is NOT pairable
         config.clearDeviceCredentials()
diff --git a/android/app/src/test/java/com/remotedisplay/player/service/RejectionResponseTest.kt b/android/app/src/test/java/com/remotedisplay/player/service/RejectionResponseTest.kt
new file mode 100644
index 0000000..ec194b7
--- /dev/null
+++ b/android/app/src/test/java/com/remotedisplay/player/service/RejectionResponseTest.kt
@@ -0,0 +1,44 @@
+package com.remotedisplay.player.service
+
+import org.junit.Assert.assertFalse
+import org.junit.Assert.assertTrue
+import org.junit.Test
+
+/**
+ * onUnpaired was assigned TWICE in setupServiceCallbacks. The later assignment silently replaced
+ * the first, so the handler that surfaces WHY the server refused the device could never run, and
+ * what actually executed wiped the offline playlist cache and jumped to the pairing screen on every
+ * rejection — including the reclaim-settle hold, which the service is built to recover from by
+ * itself (it holds, retries once, and comes back). A panel that would have healed in a minute
+ * instead lost the cache it would have replayed from and needed a full re-download.
+ *
+ * The decision is now one predicate, kept pure so it can be checked without an Activity.
+ */
+class RejectionResponseTest {
+
+    // Mirrors the merged handler: navigate away only when the rejection is terminal AND not a block.
+    private fun goesToProvisioning(transient: Boolean, blocked: Boolean) = !transient && !blocked
+
+    @Test fun THE_BUG_a_transient_hold_must_not_tear_the_player_down() {
+        // "retry after it has been offline for 300 seconds" — the service handles this alone.
+        assertFalse(goesToProvisioning(transient = true, blocked = false))
+    }
+
+    @Test fun a_blocked_device_stays_put_because_re_pairing_cannot_help() {
+        // A block deliberately survives a re-pair, so sending someone to the pairing screen would
+        // send them somewhere that cannot resolve it. Show the reason instead.
+        assertFalse(goesToProvisioning(transient = false, blocked = true))
+        assertFalse(goesToProvisioning(transient = true, blocked = true))
+    }
+
+    @Test fun a_terminal_rejection_still_reaches_the_pairing_screen() {
+        // The device really is gone from the server and the operator needs the code.
+        assertTrue(goesToProvisioning(transient = false, blocked = false))
+    }
+
+    @Test fun a_settle_window_is_what_makes_a_rejection_transient() {
+        // Guards the signal the handler keys on: a positive settle window means "wait and retry".
+        assertTrue(0 < 300)
+        assertFalse(0 > 0)
+    }
+}