diff --git a/app/api/scenes.py b/app/api/scenes.py
index 082f9f5..dfeeba1 100644
--- a/app/api/scenes.py
+++ b/app/api/scenes.py
@@ -670,14 +670,14 @@ def _is_rotting_thumb(url: str) -> bool:
     slim-thumbnaila — używamy tylko gdy scena nie ma żadnej innej miniaturki."""
     if "trafficdeposit.com" in url:
         return True
-    # imgs.xiaoshenke.net (fullporner) oddaje 200 z ~153-bajtową ATRAPĄ zamiast obrazu.
-    # Formalnie „ma miniaturę", więc przechodziło warunek `find(s => s.thumbnail_url)`
-    # w apce i WYGRYWAŁO jako pierwsze źródło — a działająca miniatura (np. hqporner,
-    # 22 kB) leżała niżej i nigdy nie była użyta. Objawiało się dopiero po scaleniu scen
-    # („3 źródła live, a miniaturki nie ma", zgłoszenia a01dc891 / 2fbba822 / b437d5f7):
-    # przy jednym źródle brało się to dobre, po merge na czoło wchodziła atrapa.
-    if "imgs.xiaoshenke.net" in url:
-        return True
+    # imgs.xiaoshenke.net (fullporner) było tu wpisane 2026-08-02, bo host oddawał 200
+    # z ~153-bajtową atrapą zamiast obrazu (zgłoszenia a01dc891 / 2fbba822 / b437d5f7).
+    # To był stan PRZEJŚCIOWY: pomiar 2026-08-11 na 300 losowych URL-ach z bazy dał
+    # 298 prawdziwych JPEG-ów (5-25 kB), tak samo z VPS jak i z łącza domowego.
+    # Blokada zdjęta, bo szkodziła bardziej niż pomagała: w SceneDetail (linia ~879)
+    # rotting-thumb jest ZEROWANY, więc sceny mające tylko fullporner traciły miniaturę
+    # całkowicie („Jakiś problem z miniaturkami z fullporner"). Dotyczyło 53 tys. źródeł.
+    # Gdyby atrapy wróciły, filtruj po ROZMIARZE odpowiedzi w image-proxy, nie po hoście.
     # tn.sextu.com (fullvideosporn) — CDN odrzuca ruch z IP datacenter (429), więc nasze
     # image-proxy NIGDY tej miniatury nie pobierze (znany problem tego źródła). Traktujemy
     # jak martwą, żeby scena po merge sięgnęła po działającą z innego źródła.