Strona feedu spadla z 310-470 ms do 50-130 ms (srednio 85 ms na 30 stronach,
0 powtorek). Postgres nie ma max(uuid): koniec okna liczony po rzutowaniu na
tekst (ten sam porzadek dla malych hex w stalym formacie).
Pierwszy backfill po niszach przy ~3 zapytaniach/s po ~65 zapytaniach wpadl
w trwale 429 (cialo: delay 1167 s, subject per IP i endpoint) i przemielil
40 kolejnych nisz w bledach. Teraz: 1/s, odstep z Retry-After albo
error.delay, powyzej 5 min RateLimited i koniec przebiegu (wznowienie --skip).
Nowy wertykal krotkich pionowych klipow tworcow, osobno od scen: inne kolumny
(tworca, audio, lajki, nisze), inny cykl zycia, inna taksonomia, brak filtra
60 s. Tabele `clips` (unikalne source+source_id) i `clip_tags` z indeksem
(tag, clip_id) pod skan po tagu od losowego uuid w przyszlym feedzie.
Zrodlo nr 1: RedGifs, oficjalne API v2 z tokenem tymczasowym (zwiazany z IP
i UA, na 401 odnowienie). Globalne `order=latest` bez search_text daje ~100
na strone, kazde zapytanie widzi maks. 10 000 wynikow, wiec katalog chodzi
sie po niszach (skrypt backfillu). Pliki media.redgifs.com sa publiczne i bez
podpisu (206 z VPS-a i z telefonu), do bazy wchodzi gotowy adres.
Scheduler: job clips-latest co godzine (5 stron), zatrzymuje sie na stronie
bez nowych. Reaper (HEAD, 403/404/410 -> dead_at) jako skrypt, upsert
odzywia klip, ktory zrodlo znow podaje. API: GET /clips i /clips/stats do
pilota; wlasciwy feed, pamiec widzianych i telemetria to etap 3.
Sprawdzone tego dnia i odlozone: nsfwswipe (lustro v.redd.it, bez audio,
stoi od 19.08), Pornhub Shorties (zrodlo nr 2, HLS z tokenem 2 h, Referer
na segmentach, 0/110 performerow z kanonu).
- DOOD_OVERLAY_JS (injectedJavaScript po zaladowaniu): fixed + z-index > 100000 bez
Cloudflare -> pointer-events none, iframe sandbox/srcdoc usuwany; co 700 ms
- diagnoza devtools: pelnoekranowy div opacity 0.01 z z 2147463647, iframe reklamowy i
pusty kwadrat 80x80 dokladnie na przycisku play; popunder u nas zablokowany, wiec
warstwa nigdy nie znikala (zgloszenia e9fc12e8, 1278eb49)
- changelog 2026-09-14c, OTA 69b27e52 na 1.3
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- random: md5(seed) -> uuid startu, okno 2000 id (8000 dla wertykalow) po pk_scenes,
filtry na oknie; bez okna planer robil Merge Anti Join po 2,3 mln wierszy (7,6 s)
- duration_desc/asc: bez NULL, do 10 h, indeks ix_scenes_duration (migracja 0035)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- ScenesFilterModal: Reset all filters stosuje domyslne i zamyka arkusz (f5193fba)
- ScenesScreen: has_playback domyslnie wlaczone nie liczy sie jako filtr, za to sort,
min. dlugosc, min. jakosc i stuby tak
- MovieFiltersSheet: rok poza 1900..2100 ignorowany zamiast 422 (2b6dbc75)
- changelog 2026-09-14a, OTA 6cca22ce na 1.3
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- _search_base: hak _thumbnail_map (mapa url -> miniatura z calej strony) przed
szukaniem <img> w oknie tekstu; xhamster mial 54% zrodel bez miniatury
- mypornerleak search: karty maja teraz src zamiast data-src; browse (REST) bez
featured media -> og:image ze strony posta
- scripts/backfill_thumbs.py: uzupelnia miniatury ze strony sceny, od najnowszych
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- screenOptions: tlo ekranu, bez cienia, tytul 17 display, tint accentText
- HeaderIconButton (star/star-outline, eye-off-outline) na 5 ekranach zamiast ★/🚫
- BottomTabsBar: 76 dp, pierscien statyczny w iconBox w spoczynku, kapsula tylko w
trakcie przejscia, srodki zaokraglone do piksela
- changelog 2026-09-08b/c, OTA 1cbb9181 i 18ba425a na 1.3
- WebView: przed pierwszym onLoadEnd kazda nawigacja top-frame to lancuch redirectow
serwera, nie popunder; po zaladowaniu przeskoki w obrebie rodziny DoodStream tez OK
- SiteScenes: wyszukiwarka w obrebie strony + ikona tagow z licznikiem + X
- PerformerScenes: licznik scen + ikony szukaj-wiecej/filtr w jednym wierszu, chipsy
top-tagow wyciete (tagi sa w filtrze), zbedne zapytanie performer-tags usuniete
- changelog 2026-09-07h, OTA 49cda698 na 1.3
- scripts/site_icons.py: apple-touch-icon / icon / favicon.ico, PIL do 64x64 PNG,
proxy Bright Data w odwodzie, mapa domen dla sitetagow bez TLD
- /sources: icon_url gdy plik istnieje (BACKEND_PUBLIC_URL albo wzgledne)
- SitesScreen: SiteLogo z literowym fallbackiem, SortSheet (most scenes, recently
updated, best rated, name) zapamietany w SecureStore, koniec wiersza Top/Recent
- changelog 2026-09-07g, OTA 1e90f427 na 1.3
- useAutoHideOnScroll: licznik drogi w jednym kierunku (48 px w dol chowa, 24 w gore
pokazuje), strefy zawsze-widoczny przy gorze i dole listy, overscroll ignorowany
- HomeScreen useFocusEffect pokazuje pasek po powrocie z ekranu szczegolow
- changelog 2026-09-07e/f, OTA 40931479 i 8604dadb na 1.3
- lib/bottomBar.ts: stale paska, szyna scroll-top, wartosc Animated do chowania
(hysteresis po przebytej drodze, strefy gora/dol), inset dla list
- BottomTabsBar: absolute nad trescia, translateY z native drivera, null przy klawiaturze
- Scenes: Performers/Tags/Favorites jako IconButton obok lejka i zebatki, chipsy
zapisanych wyszukiwan tylko przy fokusie albo wpisanym tekscie, Save jako chip
- changelog 2026-09-07d, OTA 3f7e21c5 na 1.3
- pasek dolny nizszy (62) i przyciety na krawedzi ekranu, zaokraglone tylko gorne rogi
- IconButton (filter-variant z licznikiem) zamiast pigulki Filter, SettingsButton w
wierszu narzedzi Scenes/Movies/Sites
- ustawienia: sekcje Support the project i Backend (host + wylogowanie), tytul Settings
- changelog 2026-09-07c, OTA 5c8895d6 na 1.3
- BottomTabsBar: pigulka nad krawedzia, aktywna ikona w pierscieniu; przy zmianie
przednia krawedz wystrzela, tylna dogania (kapsula od starej do nowej), jeden
kolor accentText z miekka poswiata zamiast neonu z reela
- naglowek: nazwa sekcji obok logo zamiast gornego paska
- BugReportFAB wisi nad paskiem na ekranie-gospodarzu
- changelog 2026-09-07b, OTA a2328005 na 1.3
Nowe strony wchodza po stronie backendu, wiec bez publish OTA uzytkownik nie
dostaje popupu What's new (changelog jedzie w bundlu). Sam wpis, bez zmian w
kodzie apki.
tubepornclassic.com to SPA sieci TXXX (ten sam silnik co vjav): HTML ma pusty
<title> i zero linkow do scen, wszystko idzie z JSON API. Listing
/api/json/videos2/<cache>/str/latest-updates/60/..<page>.all...json oddaje
60 rekordow z pelnymi metadanymi (tytul, slug, dlugosc, post_date, obsada,
kategorie+tagi, miniatura), wiec nie ma fetchu per scena. ~168 tys. wideo,
wgrania codziennie. Koniec katalogu = 200 z code=videos_not_found.
Stream: videofile.php -> dekod video_url -> get_file -> f=video.m3u8 -> HLS
na ahcdn (klucz time-bound, nie IP-bound: adres wybity z VPS gra z lacza
domowego). Ten tor zyl dotad w tubes/vjav.py; wyniesiony do
_txxx.extract_hls, vjav i tubepornclassic wolaja to samo. HLS zamiast mp4,
bo mp4 z tego samego get_file ma w URL CDN speed=... (~1,2 MB/s), a segmenty
HLS leca ~3,6 MB/s. Wyzwanie 429 (ciasteczko w ciele) obsluzone w
ekstraktorze, scraperze i juz wczesniej w /proxy/hls.
Bramka: 38% tytulow to generator SEO ("Fabulous Sex Movie Vintage Try To
Watch For Ever Seen"). Z doczepionym nazwiskiem scena jest odnajdywalna
i zostaje; bez obsady (22%) nie wchodzi, bo nie ma po czym jej znalezc
ani z czym zdeduplikowac. Obsada u 46% scen, studiow brak.
Pilot: 2 strony, 120 scen, 111 nowych, 9 juz w bazie, wszystkie z dlugoscia.
Odtworzenie na emulatorze: playback_events success (ttff 3,3 s), AudioTrack
started. vjav po refaktorze: ten sam wynik ekstraktora co przed.
Z szesciu stron z listy piec juz jest lub bylo w bazie: fullmovies.xxx,
hdporn.gg, neporn.com sa zywe (ingest z dzisiaj, odtwarzanie 84-99%),
a hqfap.com i 4k69.com nadal oddaja Cloudflare JS-challenge na podstronach
(403 "Just a moment" takze z lacza domowego, wiec to nie blokada po IP).
Jedyna nowa to porndupe.
Porndupe wyglada jak KVS, ale to atrapa: kazdy get_stream/<id>-<q>.mp4?md5=
odpowiada doslownie "error" (sprawdzone z sesja, Refererem strony i embedu,
z permutacja md5 kodem licencyjnym). Prawdziwy tor widac w DevTools:
generate_mp4('<b64 JSON>', '<haslo>', '<okid>', '<id>')
-> {ciphertext, iv, salt, iterations: 999}
-> PBKDF2-SHA512 + AES-256-CBC -> klucz sesji OK.ru (staly; haslo i
ladunek zmieniaja sie co wczytanie, to zaciemnienie)
-> api.ok.ru/fb.do method=video.get -> url_low/medium/high/fullhd,
duration (ms), created_ms, thumbnail_url
Wariant PBKDF2 ustalony empirycznie: SHA-1/SHA-256 daja bad decrypt,
SHA-512 oddaje dokladnie klucz z trace'u.
okcdn: srcIp wbite w URL, NIE egzekwowane (URL z lacza domowego pobrany
z VPS -> 206, 514 MB, ftypisom) -> mobile_direct_ok. Cap 720p, bo OK.ru
dlawi polaczenie do ~2,1 Mbps (decyzja z 4k69/8kporner).
Browse po id (vjav pattern): kazdy listing to catch-all z tymi samymi 24
linkami, sitemapy pokrywaja 3500 z 12 887 id. /video/<id>/ -> 301 slug
(istnieje) albo 302 / (brak). Dlugosc z api.ok.ru przy ingescie (HTML nie
ma duration ani uploadDate). Daty CELOWO nie: created_ms to dwie fale
hurtowego wgrania (07.2024, 04.2025), nie premiery.
Katalog ZAMROZONY od kwietnia 2025, wiec to jednorazowy import, nie zrodlo
swiezosci. Wchodzi, bo 87% scen (52/60) nie mamy, a to tresc studyjna
(Nubile Films, NF Busty, Family Strokes) trafiajaca w kanon, w odroznieniu
od hentaicloud (17%). Pilot crawl_page(1): 22/22 z dlugoscia, 21/22 z
performerem, studia i tagi per-video.
Blad diagnostyczny po drodze: strona blankuje sie do about:blank po wykryciu
CDP (disable-devtool z jsdelivr); trace przezyl, DOM nie.
Zgloszenia "Playmogo nie dziala tutaj" (1278eb49, 2026-09-04) i seria
"Myvidplay nie dziala" (3b75cb54, d3af0813, 11d7b17b). myvidplay to 301
na playmogo, a playmogo to klon DoodStream z KLIKANYM Turnstile: widzet
pojawia sie po tapie w play i przeladowaniu, wiec pass_md5 nie ma w HTML
i telefon nie rozwiaze tego sam. Telemetria: ZERO zdarzen odtwarzania
w 30 dniach (droga WebView nic nie raportuje), gdy mixdrop/voe/luluvid/
vidara graja w ~99%.
Przyczyna kolejnosci: _movie_origin_priority dawal tym originom neutralne
500, wiec sortowaly sie z dzialajacymi po created_at DESC, a doply/playmogo
bywaja dopisane jako OSTATNIE -> ladowaly na GORZE "Watch on". Zgloszony
film 12e9d0c1 mial obok zywy mixdrop.
Pomiar 2026-09-05: rodzina siedzi w 54 446 filmach, 54 320 (99,8%) ma
dzialajaca alternatywe, tylko 126 zalezy od niej wylacznie. Nowy tier 800
(za neutralnymi 500, przed martwa rodzina seekplayer 900): dla tych 126
zostaje jako ostatnia deska ratunku, wiec nikomu nie zabiera dostepu.
Weryfikacja po deployu: film 12e9d0c1 -> [mangoporn:mixdrop, mangoporn:playmogo].
- person_named_in: jednowyrazowe nazwisko tylko co do znaku (albo zlepek sasiednich
czlonow tytulu), przedrostek co najwyzej o 2 znaki; "Thebdck" lapal kazde "the"
- sxyprn: autor z sciezki miniatury, _BLOCKED_AUTHORS (Shizuka, Ajx, Denzel),
karty z >20 hashtagami wchodza bez tagow
- scripts/sxyprn_purge_uploaders.py: dry-run/apply, sceny tych autorow + smieciowi performerzy
Dwie prosby z apki 2026-09-02.
Sites: dlugie nacisniecie przypina albo odpina strone (gwiazdka i akcent na ramce),
przypiete ida na gore listy w tej samej kolejnosci co reszta, takze przy szukaniu i przy
sortowaniu "Recent". Stan po stronie serwera (/favorites/sites), wiec przechodzi kodem
synchronizacji jak inne ulubione.
Filtry: `usePersistedState` w SecureStore, osobny klucz dla Scenes, JAV, Anime
(`filters_<sekcja>`) i Movies. Zapis dopiero po wczytaniu, zeby domyslne z pierwszego
renderu nie nadpisaly zapisanych; odczyt scalany z domyslnymi, zeby nowe pole w kolejnej
wersji dostalo wartosc. Zapytanie o liste czeka na wczytanie (`enabled`), bez podwojnego
strzalu. SecureStore ma ~2 KB na klucz; przy bardzo dlugiej liscie tagow zapis moze sie
nie udac i wtedy filtr zyje tylko do zamkniecia apki, ale ekran sie nie wywraca.
tsc: 11 bledow przed i po (baza). Wpis w changelogu 2026-09-02b.
Prosba z apki 2026-09-02: ulubione strony maja siedziec na gorze zakladki Sites. Po
stronie serwera jak reszta ulubionych, bo kod synchronizacji to device_id i tabele
kluczowane po nim przechodza na nowe urzadzenie razem. Origin bez klucza obcego
(zrodla nie maja tabeli po origin), za to przy dodawaniu sprawdzany w playback_sources,
a sam napis ograniczony wzorcem, zeby nie dalo sie wpisac smieci.
Migracja 0034 (create table, bez blokad). Sprawdzone TestClientem w kontenerze api:
dodanie, powtorne dodanie (created=false), lista w kolejnosci dodania, nieznany origin
404, zly wzorzec 422, usuniecie 204.
Scorer tytulu (`movie_score._title_signal`), na zywym ingescie:
* sklejanie ogonkow apostrofu obejmowalo KAZDA pojedyncza litere, wiec "watch a whore s
tale" dawalo "watcha", a przedimek "a" nigdy nie wpadal do wypelniaczy; lustra z A/I
na poczatku tytulu przestawaly sie laczyc. Teraz tylko s/t/d.
* rowne zbiory zlozone z samych liczb ("adult movie 2019" vs "porn film 2019" -> {2019})
dawaly 1.0; teraz sufit.
* zaostrzenie "rozne slowa = sufit" zabijalo warianty zapisu: Vol./Volume, Pt./Part,
Gang-Bang/Gangbang, literowki, liczbe mnoga. Skroty rozwijane, zlepki porownywane po
zdjeciu spacji, slowa wlasne obu stron parowane jeden do jednego: liczba mnoga = 0.95,
literowka tylko przy >= 0.92 i slowach od 4 liter. Prog 0.85 na slowie przepuszczal
"sexy"/"sex", "intense"/"interns" i "infedele"/"fedele" (niewierna vs wierna), a
porownanie calych posortowanych ciagow "girls only 4" vs "girls on girls 4".
Sprawdzone na 28 parach, w tym wszystkich przykladach z review.
`merge_movies`: ulubione i postep odtwarzania przenoszone na `keep` przed skasowaniem
`drop`. Oba maja FK ondelete=CASCADE, wiec kazde scalenie po cichu wymazywalo userowi
dane. Dotyczy tez dedup po TPDB.
Skrypt rozdzielania:
* `_istniejacy_film` dostaje pelna liste performer_id (jak resolver), nie tylko przekroj,
ktory zawyzal Jaccarda (3 z 5 wspolnych dawalo 1.0); kandydaci z trigramow PLUS
dokladne trafienie w title_normalized, bo LIMIT 50 gubil "control 2" wsrod sasiadow;
wstepny test tytulu oszczedza zapytan o obsade; flush przed blokowaniem.
* klastry rozdzielone w tym samym filmie nie moga sie do siebie dolaczyc (klastrowanie
juz orzeklo, ze to rozne filmy).
* przed przepisaniem kotwicy sprawdzenie, czy zbior refow nie zmienil sie w trakcie
pobierania (wyscig miedzy shardami).
* dry-run pokazuje tez dolaczanie do istniejacych; liczniki liczone przy tworzeniu.
* sprzatanie dubli po `updated_at` (created_at jest cofane i nie nadaje sie na znacznik
przebiegu), keep = wiecej refow, potem starsze pierwsze zobaczenie; try/except per
film; --after-id; naiwny timestamp = UTC.
Trzy skutki pierwszego przebiegu rozdzielania (2026-09-02, 5846 nowych filmow), oba
zgloszone z apki tego samego dnia:
1. Duble (a5cdda7f). Klaster poza kotwica dostawal ZAWSZE nowy film, choc "Control 2"
z innego zrodla juz istnial: 798 nowych o tytule sprzed przebiegu, 408 dubli miedzy
soba. Teraz najpierw `find_movie_candidates` + `score_movie_candidate` (ten sam
resolver co ingest) i przy >= 0.85 refy ida do istniejacego. Tryb
`--dedupe-created-after <ts>` scala juz utworzone przez `merge_movies` (691 scalonych).
2. Scorer przepuszczal jeszcze pary z roznymi slowami po obu stronach: "hardcore
fucking sluts 2" vs "foot fucking sluts 2", "santa list gangbang" vs "gangbang d"
(token_set 85-94, ze zgodnym studiem i rokiem auto-merge). Lustra nie zmieniaja
tytulow, wiec: rowne zbiory slow po zdjeciu wypelniaczy SEO = 1.0, podzbior albo
rozne slowa po obu stronach = sufit 0.6. Ogonki po apostrofie sklejane ("she s" ->
"shes"), bo normalize() tnie apostrof na spacje. Lista dubli spadla z 941 do 691 i
sa to same identyczne tytuly.
3. Falszywe "+N nowych" (1db95176). Nowy film dostawal created_at = teraz, a badge w
ulubionych od lipca sumuje sceny i FILMY: 2196 filmow z obsada z dzisiejsza data
zapalilo "+N" u kazdego z performerem w ulubionych, przy zerze nowych scen na liscie.
Teraz created_at = pierwsze zobaczenie refow klastra; 5231 juz utworzonych
poprawione w bazie tym samym kryterium.
Pierwszy prawdziwy przebieg na "The Doctor" padl na kluczu glownym movie_performers:
helpery resolvera sprawdzaja "czy juz jest" SELECT-em, ktory bez flush nie widzi
wierszy dodanych przez poprzedni profil klastra, wiec ten sam performer z dwoch luster
wpadal dwa razy. Teraz flush po kazdym profilu; transakcja per film, wiec nieudany
film wycofuje sie w calosci i nic nie zostaje w polowie.
Dopelnianie pol (tylko braki) z kazdego pobranego lustra klastra, nie tylko ze wzorca:
wzorcem bywa paradisehill bez roku, a mangoporn ma rok i studio ("Doctor Adventures 14"
tracil rok 2013).
`--shard k/n` po hashtext(id) do rownoleglych kontenerow: 8204 filmy w jednym watku to
~16 h (40 filmow w 4,6 min w probie), w trzech ~6 h.
Wynik na "The Doctor": 16 refow -> 11 filmow, kotwica z jednym refem i rozdzialami,
"Granny's Doctor Games" z dokladnie swoimi dwiema stronami i embedami, 76 zwietrzalych
lub cudzych hosterow skasowanych z kotwicy, 115 przeniesionych do wlasciwych filmow.
Skrypt `scripts/movie_unmerge.py` rozdziela filmy, ktore stary scorer zlepil z kilku
tytulow (8204 filmy z >=2 refami z jednego zrodla, 31 299 refow). Musi pobierac strony
na nowo, bo rekordy zewnetrzne filmow trzymaja tylko {slug, html_len} / {hex_id,
html_len}, a ingest jest przyrostowy, wiec skasowane rekordy same sie nie odbuduja.
Dla kazdego filmu: refy pobierane przez konektory zrodel (paradisehill, dooplay x4,
freeomovie; reszta profil ze sluga), klastry union-find po wspolnym adresie embedu
(bez prefiksu zrodla, ten sam plik siedzi pod mangoporn/pandamovies/streamporn) albo
po nowej ocenie zlozonej >= 0.85. Klaster z najstarszym refem zostaje filmem
(zachowuje id, ulubione, postep), kazdy inny dostaje nowy film z refami, hosterami,
obsada, tagami i rozdzialami. Kotwica zostaje z hosterami potwierdzonymi przez swieze
strony; reszta z rodzin luster leci, bo pandamovies zdazyl zrotowac hostery (swieza
strona ma 0 z 4 kluczy z bazy), wiec to i tak zwietrzale linki.
Proba na "The Doctor" ujawnila druga luke scorera: po normalizacji zostaje samo
"doctor", a jedno slowo jest podzbiorem kazdego tytulu z tym slowem, wiec "granny s
doctor games" i "we need a doctor" dostawaly 100 i szly do kotwicy. Teraz podzbior z
prawdziwymi dodatkowymi slowami ma sufit 0.6, a przedrostki SEO luster ("watch cece
adult movie online free") sa zdejmowane przed testem, zeby prawdziwe lustra nadal sie
laczyly. Po poprawce "The Doctor" rozpada sie na 11 klastrow, kotwica to sam
paradisehill, a "Doctor Adventures 14" laczy swoje cztery lustra.
Zgloszenie 386ef7ab (Galaxy S25, Android 16, nawigacja trzema przyciskami): pasek
przewijania niewidoczny w pionie. `controlsBottom` mial `bottom: 0` i stale
`paddingBottom: 18`, bez marginesow systemowych. Od Androida 15 apka rysuje pod paskiem
nawigacji, wiec przy trzech przyciskach (~48 dp) scrubber ladowal pod nimi.
Dolozony `useSafeAreaInsets()`: dol plus lewy i prawy, bo w poziomie pasek przyciskow
siedzi z boku. Z gestami margines to kilka dp, wiec wyglad prawie bez zmian.
`SafeAreaProvider` juz owija apke, ten sam hook jest w nawigacji.
tsc: 11 bledow przed i po, zadnego w okolicy zmiany. Wpis w changelogu 2026-09-02a.
Zgloszenie 32100b94: "w pierwszym linku jest granny porn". Pod filmem "The Doctor"
siedzialo 55 zrodel z co najmniej 9 roznych filmow pandamovies (Doctor Adventures 14 i
21, Granny's Doctor Games, Pervy Doctor 9, The Doctor Is In 2, We Need a Doctor...).
Przyczyna: tytul porownywany przez `token_set_ratio`, ktore mierzy czesc wspolna, wiec
tytul bedacy podzbiorem drugiego dostaje pelne 100 ("the doctor" vs "the doctor is in
2", "fantasies" vs "dark fantasies 3"). Numerowane serie wychodza na 90-96, tez ponad
progiem auto-merge 0.85. Gdy zrodlo nie ma roku ani studia, o wszystkim decyduje sam
tytul i cala seria zapada sie w jeden wpis: "Her way to use Tinder 61" ma 102 strony,
"Women Seeking Women 56" 87. W bazie 1878 filmow ma >=2 rozne strony z pandamovies.
Dwie zasady oparte na numerze serii (ostatnia liczba w tytule, z pominieciem lat):
* oba tytuly maja numer i sie rozni -> twarde odrzucenie,
* numer ma tylko jedna strona -> tytul najwyzej 0.6, wiec sam nie wystarczy do
auto-merge, ale ze zgodnym studiem i rokiem trafia do recznego przegladu.
Podzbior bez numerow zostaje bez kary celowo: "cece" vs "watch cece adult" to prawdziwe
lustro z przedrostkiem SEO, dla niego jest token_set.
Sprawdzone na 11 parach z bazy, w tym kontrolnych (lustro SEO bez kary, rok nie liczy
sie jako numer). Dziala tylko w przod; rozdzielenie juz polaczonych to osobna robota.
Osobno `scripts/browse_catchup.py`: jednorazowe nadrobienie N stron jednego browse-
scrapera z pliku. Powstal, bo `docker compose run -d ... python3 -` ze skryptem na
stdin nigdy nie startuje: przy -d stdin nie jest domkniety i python czeka w
nieskonczonosc. Tak "chodzilo" nadrabianie porndoe przez 2 dni bez jednego zapisu.
Na forum padlo pytanie, gdzie sa zrodla, bo na stronie nie ma do nich ani jednego
odnosnika. Sluszny zarzut przy projekcie, ktory sprzedaje sie jako otwarty. Dodane w
dwoch miejscach: stopka i lista linkow.
Liczby byly zawyzone. Prawdziwe na 2026-08-31, z bazy:
* sceny 3,8 mln -> 3,3 mln. Liczymy sceny z ZYWYM zrodlem (3 342 052), bo tyle user
realnie widzi w apce. Wierszy w tabeli jest 4 046 223, ale czesc nie ma czego odtworzyc.
* performerzy 108k -> 110k, filmy 45k -> 46k, zrodla 46 -> 43 (w trzech miejscach).
Dodany wpis do "What's new" o sprzataniu martwych zrodel i naprawie odtwarzania, bo
ostatni byl z Chromecasta.
ZOSTAWIONE swiadomie: ostrzezenie o wersji 0.2.2. Wyglada na przeterminowane, ale nie
jest: instalacje starsze niz 0.2.2 byly podpisane kluczem, ktorego juz nie mamy, wiec
Android odmawia aktualizacji w miejscu i trzeba odinstalowac. Ta instrukcja z kodem
synchronizacji jest dla tych ludzi jedynym sposobem, zeby nie stracic ulubionych.
Plik w repo rozjechal sie z produkcja (repo mialo jeszcze 0.2.2, produkcja 0.3.0), bo
strone edytowano bezposrednio na serwerze. Teraz site/index.html to dokladnie to, co
stoi na goon-foss.org.
Watchdog zglaszal "tube:porndoecom (browse) bez nowych tresci (173h, prog 48h)" i
potraktowalem to jako szum razem z alertami dla tubow, ktore faktycznie przestaly
publikowac. Bledna ocena: porndoe to nasze czwarte co do wielkosci zrodlo (356 tys.
zrodel), a ostatnia nowa scena wpadla 2026-08-21.
Przyczyna: porndoe zaczal oddawac HTTP 403 na IP serwerowni. Scraper dostawal strone
bledu, znajdowal zero linkow i konczyl sie bez wyjatku, wiec z zewnatrz wygladalo to na
"tub sie wyczerpal", a nie na awarie. Ten sam ksztalt pomylki co przy porntrex, gdzie
cicha zmiana markupu ukryla 6479 scen.
Sprawdzone 2026-08-31: bez proxy 403 i 0 scen, przez Bright Data ISP proxy 200 i 31 scen
z pierwszej strony, z datami z 30 sierpnia, dlugosciami i obsada. Wzorzec i uzasadnienie
kosztowe jak przy superporn: ISP proxy jest ryczaltowe, wiec deep-crawl nie kosztuje
wiecej, a przez proxy leci sam HTML, nigdy strumien.
Bez skonfigurowanego proxy `crawl_page` zwraca pusta liste zamiast dobijac sie o 403.
Sprawdzenie dwoch tubow, ktore w statystyce bledow odtwarzania wygladaly zle. Oba maja
inna przyczyne niz vjav i ZADEN nie jest awaria calego tuba.
**perverzija.** Naglowkowe "44% bledow" jest mylace: 132 ze 176 bledow pochodzi z awarii
13-18 sierpnia, ktora sama minela (te dni maja zero udanych odtworzen). Ostatnie 8 dni to
~16%. Wszystkie trzy sceny, ktore realnie padly u userow, resolwuja sie dzis poprawnie i
przechodza przez /proxy/hls jako prawidlowy manifest, wiec biezacej awarii nie ma.
Zostaje jednak realna dziura: hoster potrafi oddac 200 z trescia, ktora manifestem nie
jest (strona bledu albo reklama). Przepuszczalismy to dalej jako
`application/vnd.apple.mpegurl` ze statusem 200, a odtwarzacz konczyl komunikatem "Input
does not start with the #EXTM3U header" (203 zdarzenia w 14 dni). Gorsze od samego bledu
bylo to, ze przy statusie 200 apka uznawala odpowiedz za dobra i nie probowala odswiezyc
zrodla. Teraz w takiej sytuacji leci 502.
**8kporner.** Bledy to 502 i 400 z okcdn, rozlozone rownomiernie, przy stale dzialajacym
tubie. To zwietrzaly zapisany adres, ten sam wzorzec co watchporn. Potwierdzone na
czterech scenach, ktore padly u userow: swiezy resolve kazdej z nich oddal 206 z trescia.
Jeden przypadek w tej probce byl bledem DNS po stronie klienta, nie naszym.
Stad oba origins dopisane do `BACKEND_RERESOLVE_ORIGINS`, czyli mechanizmu juz dzialajacego
dla watchporn i galaxyporn.
Sprawdzone na prodzie po wdrozeniu: prawdziwy manifest dalej przechodzi (200, 58 kB),
a odpowiedz nie bedaca manifestem dostaje 502 zamiast 200 ze smieciami.
vjav mial 587 bledow odtwarzania i ZERO udanych, przez caly czas, odkad zbieramy dla
niego zdarzenia. Kazdy blad to ten sam komunikat odtwarzacza: "Source error Response
code: 429". Dotyczylo to 58 779 zrodel, czyli tub nigdy ani razu nie zagral.
Siec TXXX dlawi ruch z serwerowni: zamiast tresci oddaje 429 i mikroskopijna strone,
ktora w JS ustawia jedno ciasteczko i przeladowuje sie. Wartosc stoi wprost w tej
odpowiedzi, wiec wystarczy ja odczytac i powtorzyc zapytanie, bez wykonywania JS.
Ekstraktor vjav robil dokladnie to od 2026-08-21, ale TYLKO przy `videofile.php`. Adres
manifestu oddawany odtwarzaczowi tej sztuczki nie dostawal, a `/proxy/hls` pobiera go z
VPS przy KAZDYM odtworzeniu. Stad komplet bledow.
To dlatego bug byl niewidoczny z zewnatrz: `try_extract` konczyl sie sukcesem, wiec w
kazdym pomiarze zrodla vjav wychodzily jako zywe (149 na 150), podczas gdy u userow nie
dzialalo nic. "Zywe" znaczy "ekstraktor zwrocil adres", a nie "to gra".
Sprawdzone na prodzie: przed poprawka /proxy/hls oddawal 429, po poprawce 200 i poprawny
#EXTM3U z segmentami na vjav0.ahcdn.com. Ponowienie odpala sie wylacznie przy 429 z
odpowiedzia ponizej 4 KB, wiec nie dotyka pozostalych hosterow.
Osobno potwierdzone, ze blokada jest po adresie IP: ta sama strona z VPS oddaje 429, a
przez proxy z innym IP 200 i 72 KB tresci.
`.gitignore` ma regule na `_*.py` (pliki robocze), przez co wspolny modul sondy wypadl z
poprzedniego commita i zostaly w nim dwa skrypty importujace nieistniejacy modul.
Uogolnienie `sxyprn_reap_dead.py` na pozostale tuby. Werdykt bierze sie z `try_extract`,
czyli z kodu, ktorego uzywa aplikacja przy odtwarzaniu, wiec sonda nie widzi czegos
innego niz user. Martwe pada TYLKO na 404/410 albo `HosterDead`; pusty wynik ekstraktora
to "nieznane" i zrodla nikt nie rusza.
Bramka odpala sie ZA KAZDYM URUCHOMIENIEM, zamiast polegac na tym, ze ktos pamieta wynik
wczesniejszego pomiaru. Sprawdza jednoczesnie, czy sonda widzi smierc (adresy scen, ktore
nie moga istniec, musza wrocic martwe) i czy nie zabija zywych (sceny odegrane w ostatnich
7 dniach musza wrocic zywe). Nie zdana bramka konczy skrypt bez tkniecia bazy.
Wynik pierwszego pomiaru: przemial ma sens dla hqporner (~29%) i galaxyporn (~14%).
porntrex, xvideos, neporn, supjav i reszta soft-404 odpadaja, bo sonda ich smierci nie
widzi. youperv odpada, bo oddaje martwe na 25% scen, ktore realnie sie odegraly.
Trzy rzeczy, ktore wyszly dopiero przez kontrole, nie przez czytanie kodu:
* Pierwsza wersja sondy pytala tylko o status HTTP i uznala SXYPRN za tuba, na ktorym nic
nie widac (0/6), chociaz wlasnie wygasilismy tam 34% zrodel. Sxyprn oddaje skasowany
post jako HTTP 200, a `HosterDead` leci dopiero z ekstraktora. Po przejsciu na
`try_extract` negatywna daje 7/7.
* Kontrola pozytywna przy 12 probach byla za ciasna: jeden trup to 8% i przewracal prog
5%, chociaz realny szum galaxyporn to ~3%. Stad 40 prob i okno 7 dni zamiast 14, bo im
swiezsze odtworzenie, tym mocniej "martwe" wskazuje na nasz blad, a nie na kasowanie.
* Budowanie adresow nieistniejacych przez podmiane cyfr nie dzialalo dla tubow BEZ numeru
sceny w adresie (hentaigasm, mypornerleak, freshporno). Wychodzily jako "0/0", czyli
niezmierzone, a to okolo 950 tys. zrodel. Teraz kolejno: numer w query, segment-
identyfikator, a dopiero na koncu slug. Kolejnosc jest istotna, bo psucie segmentu
trasy (`videos`) sprawdzaloby, czy tub obsluguje adres, a nie czy istnieje scena, wiec
tub oddajacy 404 na zla trase i 200 na nieistniejaca scene falszywie zdalby bramke.
Sonda siedzi w `_reap_probe.py` wspolnym dla pomiaru i przemialu, zeby bramka testowala
dokladnie ten kod, ktory potem mieli baze.
Po sxyprn (34% martwych na 188 tys. zrodel) nasuwa sie przemielenie tak samo calej
reszty. Metoda sxyprn nie przenosi sie wprost:
* Twardy sygnal smierci (`HosterDead`) ma tylko 6 z 42 ekstraktorow. Dla reszty "nic nie
zwrocil" znaczy naraz "skasowane", "zmienil sie markup" i "rate limit". Wygaszanie na
tej podstawie schowaloby ZYWE sceny, jak przy porntrex (6479 scen po cichej zmianie
markupu).
* Zywych zrodel jest ~3,9 mln, czyli ponad tydzien ciaglego pukania do wlasnej podazy.
Dlatego najpierw pomiar. Skrypt jest wylacznie do odczytu, niczego nie oznacza.
Martwe pada tylko na twardych sygnalach: HTTP 404/410 albo `HosterDead`. Pusty wynik
ekstraktora to "nieznane" i zrodla nikt nie rusza.
Kazdy tub dostaje DWIE kontrole, bo sam wynik proby niczego nie dowodzi: "0% martwych"
znaczy albo "tub zdrowy", albo "nie widzimy trupow".
* Pozytywna: zrodla scen, ktore realnie odegraly sie w ostatnich 14 dniach. Musza wrocic
zywe. Lapie tuba, ktory zaczal oddawac 404 wszystkiemu bez sesji, czyli przypadek, w
ktorym przemial skasowalby caly katalog. Prog to 5%, nie zero, bo czesc scen znika
naprawde. Odsetek z kontroli odejmuje sie od wyniku proby.
* Negatywna: prawdziwy adres z numerem sceny podmienionym na absurdalny. Taka strona nie
moze istniec, wiec musi wrocic martwa.
Negatywna od razu sie oplacila: pierwsza wersja pytala tylko o status HTTP i uznala
sxyprn za tuba, na ktorym sonda jest slepa (0/6), chociaz wiemy, ze ma tam 34% trupow.
Powod: sxyprn oddaje skasowany post jako HTTP 200, a `HosterDead` leci dopiero z
ekstraktora. Po przejsciu na `try_extract` negatywna daje 7/7.
Tuby resolvowane tylko w WebView na telefonie sa pomijane, bo z VPS sa nieweryfikowalne.
Po wznowieniu przerwanego przebiegu pierwsza porcja dala 498 zywych i ZERO martwych,
przy sredniej 35%. Powod: przebieg idzie `ORDER BY id`, a poprzedni zdazyl sprawdzic
151 tys. pozycji. Martwe wypadly ze zbioru, ale 100 763 POTWIERDZONYCH JAKO ZYWE
zostalo i skrypt sprawdzal je po raz drugi. To 73% pracy i tyle samo zbednych zadan do
sxyprn, czyli dokladnie to, czego chcialem uniknac przy tym zrodle.
Dolozony `--after-id`: pomija wszystko o id <= podanego. Granice bierze sie z bazy jako
najwyzsze id wsrod juz oznaczonych (`max(id::text)::uuid`), sposob zapisany w komentarzu
przy zapytaniu.
Sprawdzone, ze granica jest wlasciwa: przed nia 0 martwych na 500, zaraz za nia
6 martwych na 10. Do zrobienia zostalo 37 391 zamiast 138 154.
Przebieg po 151 tys. sprawdzonych zrodel przepadl, bo sam ubilem go wlasnym
`docker compose restart worker` przy wdrazaniu poprawek seekplayera. Log urwal sie
o 06:54, kontener wystartowal o 06:58. Proces zostal jako pusta skorupa (jeden watek,
zero postepu), a wygladalo to na zawieszenie: sxyprn odpowiadal normalnie w 0,2 s,
baza byla bez blokad.
Trzy zmiany, kazda usuwa jedna slabosc, ktora to ukrywala albo pogarszala:
* PORCJAMI po 500, ze swieza pula na kazda porcje. `pool.map` na calej liscie
kolejkowal 188 tys. zadan naraz, wiec przerwanie w polowie nie zostawialo zadnego
punktu zaczepienia, a pamiec rosla bez potrzeby.
* JEDEN `UPDATE` na porcje zamiast jednego na wiersz.
* `flush()` po kazdej porcji. Log do pliku byl buforowany i milczal godzinami, przez co
martwy przebieg wygladal identycznie jak pracujacy.
W docstringu jawne ostrzezenie: to zadanie NIE MOZE chodzic w kontenerze workera, bo
kazdy deploy backendu je ubija. Odpalac przez `docker compose run -d --rm worker`,
czyli w osobnym kontenerze. Wznawianie jest darmowe, bo bierzemy tylko zywe zrodla.
Stan: 52 998 zrodel juz oznaczonych martwymi, wznowione na pozostalych 138 154.
Na prosbe Jana wygaszone hurtem 338 904 zrodla rodziny seekplayer (easyvidplayer,
embedseek, seekplayer, upns, player4me, rpmplay) na 26 248 filmach.
Dowody, ktore to uzasadnily, trzy niezalezne:
1. Swieze identyfikatory wziete PROSTO ze strony serwisu tego samego dnia zachowuja sie
tak samo jak nasze z bazy: brak adresu albo 404. Czyli to NIE jest nasza staroc,
tylko hoster nie serwuje (przy galaxyporn ten sam test wychodzil odwrotnie).
2. Pomiar per marka, po 6 probek na kazda: 0 grajacych na 36.
3. Rozkodowany ich wlasny player: komunikat "Media source is not playable" pada dopiero
po wyczerpaniu WSZYSTKICH czterech sciezek CDN (Ce.shift() az do pustej listy). Czyli
ich klient tez sie poddaje.
Zabezpieczenie: NIE wygaszono zrodel filmu, ktory nie ma nic innego (4 zrodla, 1 film),
zeby nic nie zniknelo z katalogu. Po operacji 0 filmow stracilo wszystkie zrodla, a te,
ktore mialy ta rodzine, maja srednio 10,6 zywych zrodel.
Odwracalne: ustawiamy dead_at + czytelny dead_reason, nie kasujemy wierszy.
Skrypt: `_probe` deleguje teraz do `seekplayer_engine.extract`, zeby werdykt byl TEN SAM
co u resolvera aplikacji. Wczesniej mial wlasna, luzniejsza regule (sa pola = zywe) i
uznawal za zywe zrodla z adresem do usunietego pliku, na ktorych CDN oddaje 502.
Usuniete nieuzywane importy i akapit docstringu, ktory po tej zmianie mowil cos
przeciwnego niz kod.
Zgloszenie Jana: myvidplay i easyvidplayer na filmach dalej nie dzialaly, mimo
wczorajszych poprawek backendu.
Backend byl OK, sprawdzone na zywo: myvidplay resolwuje sie teraz na playmogo.com, a
easyvidplayer oddaje 410 i znika z listy. Problem byl PO STRONIE APLIKACJI.
Playmogo (tam laduja myvidplay i doply) zmienil zabezpieczenie. Nasza notatka mowila, ze
to niewidzialny Turnstile przechodzacy automatycznie. To juz NIEPRAWDA: ich strona wola
turnstile.render z size flexible, czyli WIDOCZNY widget, i to dopiero po kliknieciu w
przycisk play, a po weryfikacji przeladowuje strone i dopiero wtedy pojawia sie pass_md5.
Nasz wstrzykiwany skrypt psul dokladnie ten przeplyw. Widget siedzi w kontenerze o klasie
captcha-player z z-index 100000, czyli w tym, co nasz usuwacz nakladek traktuje jak
reklame, a nasze auto-klikniecie w plakat odpalalo brame, zanim widget zdazyl sie
wyrenderowac. Do tego patchujemy prototypy HTMLMediaElement, co Turnstile potrafi uznac
za podejrzane srodowisko (dokladnie ten sam objaw mielismy na vikingfile).
Straz, ktora dotad obejmowala tylko vikingfile, obejmuje teraz cala rodzine bramkowana
Cloudflare. Na stronie pliku i tak nie potrzebujemy ani wyciszania autoplay, ani ad-blocka.
Pulapka po drodze, warta zapamietania: komentarz z backtickami wewnatrz literalu
szablonowego INJECTED_JS przerywa ten literal i wywala parsowanie calego pliku.
Zweryfikowane: regex po rozwinieciu szablonu pomija playmogo/myvidplay/doply/vikingfile/
d0000d/ds2play, a zostawia dzialajacy skrypt na galaxyporn, sxyprn i eporner; podobnie
brzmiacy goodplay.com sie nie lapie. Typecheck wrocil do bazowych 11 bledow.
NIE mam na to dowodu z urzadzenia: przejscie Turnstile trzeba potwierdzic na telefonie.
Zgloszenie a405b9d6 "znowu galaxyporn nie dziala". Przyczyna byla inna niz sie wydawalo:
nasz resolver dzialal, tylko oddawal adres do pliku, ktorego juz nie ma.
Co ustalone przez reverse engineering ich bundla i pomiary:
1. Adres strumienia siedzi w KILKU polach, a serwis sam podaje w `streamingConfig`,
ktorej sciezki uzyc i w jakiej kolejnosci:
{Cloudflare: cf, Tiktok: hlsVideoTiktok, Google: hlsVideoGoogle, "In-House": source}.
Czytalismy WYLACZNIE `source`, wiec sceny majace tylko `hlsVideoTiktok` traktowalismy
jak martwe. A one graja: zweryfikowany manifest 1080p, 200 i z serwerowni, i z lacza
domowego. Doszlo skladanie adresu wg ich regul (`/hls/` -> `/hlsmod/<domain>/` + params).
2. WAZNIEJSZE: adres do usunietego pliku wyglada normalnie, a CDN oddaje na niego 502.
Sprawdzone: wezly 94.131.217.172/175/177 rotuja i WSZYSTKIE daja 502 dla jednego pliku,
podczas gdy TEN SAM wezel .172 serwuje inny plik poprawnie. Czyli CDN zyje, brakuje
konkretnych plikow. Oddawalismy taki adres jako dobry, aplikacja pokazywala czarny
ekran, a ratunek z vikingfile nigdy sie nie uruchamial, bo lista zrodel nie byla pusta.
Teraz kazdy kandydat jest sprawdzany (`_responds`) i zwracamy tylko ten, ktory
naprawde odpowiada manifestem.
3. galaxyporn: gdy player mowi wprost, ze pliku nie ma, a na stronie NIE MA tez linku do
vikingfile, przepuszczamy `HosterDead` dalej zamiast zwracac None. Wczesniej takie
sceny dawaly 503 "sprobuj ponownie" i wracaly w kolko.
Weryfikacja, ze `_responds` nie odrzuca dzialajacych: scena `#puwcko` -> http=200,
responds=True, prawdziwy #EXTM3U (przyjeta); `#bgitoa` -> 502 na wszystkich wezlach
(odrzucona). Na probce 20 scen galaxyporn 85% trafia teraz do vikingfile zamiast dostawac
martwy adres. Scena ze zgloszenia zostala oznaczona martwa przez prawdziwy endpoint
resolve (410 zamiast czarnego ekranu).
Czego NIE zrobilem: vikingfile wymaga tokenu z WIDOCZNEGO checkboxa Cloudflare
(`POST <adres strony>` z `cf-turnstile-response=<token>`). Obchodzenia tego nie buduje.
Obserwacja Jana: scena sxyprn z widoczna miniatura gra, bez miniatury w ~90% nie, i
jest sporo takich smieci. Sprawdzone i potwierdzone mechanicznie.
Miniatura sxyprn NIE jest brana z zapisanego thumbnail_url (te sa podpisane czasowo,
TTL < 1h, dawno wygasly), tylko z /proxy/sxyprn-thumb/<id>, ktory NA ZYWO pobiera
strone posta i wyluskuje poster. Odtwarzanie bierze data-vnfo z DOKLADNIE tej samej
strony. Skasowany post = pusty kafelek ORAZ brak streamu. Stad korelacja widoczna w apce.
Sygnal smierci jest twardy: usuniety post zwraca HTTP 200 ze strona "Post Not Found"
(soft-404), a ekstraktor rzuca wtedy HosterDead. Tylko to oznaczamy martwym. Strona
bez data-vnfo (niepewny przypadek) zostaje nietknieta.
Oznaczamy dead_at (odwracalne), NIE kasujemy wiersza: gdyby to byl chwilowy blad albo
sxyprn wskrzesil post, wystarczy wyzerowac znacznik. Efekt w UI ten sam co kasowanie.
Wolno i grzecznie (3 watki, 0,5 s odstepu), bo sxyprn to nasz TOP origin (~12 tys.
odtworzen miesiecznie) i nie chcemy bana. Przebieg testowy 5000: 65% zywych, 35%
martwych (1755 oznaczonych), 2 niepewne, 18 min, zero oznak rate-limitu.
Pelny przemiał 188 602 zywych zrodel uruchomiony odpiety w kontenerze.
Prosba 39314780: "Add similar filters to when we search for videos by pornstars".
Ekran performera dostaje TEN SAM modal co glowny feed (ScenesFilterModal), nie osobny:
jakosc, minimalna dlugosc, sortowanie, zrodlo/hoster, tagi, studia oraz "Also featuring"
(sceny takze z inna osoba). Chipsy top-tagow zostaja OBOK, jako jednodotykowy skrot na
najczestszy przypadek; ich wybor scala sie z tagami z modala.
Trzy roznice wzgledem glownego feedu, wszystkie zamierzone:
* domyslne sortowanie po dacie premiery (tak ten ekran dzialal od zawsze),
* prog dlugosci domyslnie 0 (wejscie w konkretnego performera nie ma ukrywac scen o
nieznanej dlugosci, bo NULL nie przechodzi `>= 60`; wybor "5+ min" podnosi go jawnie),
* "Also featuring" zamiast "Performers": backend laczy performer_ids koniunkcja, wiec
wybrani sa dokladani do biezacego performera przez AND, nie zastepuja go. Modal
dostal na to prop `performersLabel`.
Licznik na przycisku liczy sie wzgledem domyslnych TEGO ekranu, inaczej has_playback=true
podbijaloby "Filter 1" na czysto.
Backend bez zmian: /scenes juz przyjmuje wszystkie te parametry.
Zgloszenie 23c64a28: "Search more scenes button not working". Przycisk DZIALAL, tylko
wygladal na zepsuty: endpoint byl synchroniczny i przy performerce z 871 scenami search
po ~25 tubach trwal dluzej, niz telefon utrzymuje polaczenie. W logu zostaly 4 starty
performer_driven bez ANI JEDNEJ domknietej odpowiedzi HTTP: kazdy tap konczyl sie
"Refresh failed", uzytkownik klikal znowu i szukania mielily sie rownolegle, a wyniki
i tak dopisywaly sie w tle, tylko bez zadnego sygnalu dla czlowieka.
Endpoint startuje teraz watek i odpowiada od razu (`status="started"`). Rate-guard 60s
bez zmian, `last_searched_at` idzie w gore PRZED startem watku, wiec chroni tez przed
zdublowaniem samego startu. Watek ma wlasna obsluge bledow, bo nie ma juz requestu,
ktoremu moglby oddac wyjatek.
Mobile: przy `status="started"` komunikat "Searching... new finds appear within a
minute or two" i odswiezenie listy po 60 s. Stare pola odpowiedzi zostaly, wiec klient
sprzed OTA pokaze "0 new scenes", co jest znosne przez kilkuminutowe okno do publikacji.
Zweryfikowane na produkcji: odpowiedz w 0,03 s, drugi strzal 429, watek tla skonczyl
po 30 s i zalogowal wynik.
