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.
Regex w backendzie dopasowywal wylacznie vikingfile.com, mimo ze serwis rotuje
domena. Poszerzony na vik[i1]ngfile z dowolna koncowka. W aplikacji ten sam wzorzec
byl juz poszerzony, backend zostal w tyle.
Na 20 losowych scenach: 16 oddaje vik1ngfile.site, 4 nie maja zadnego zrodla (stary
player padl, a linku do vikingfile na stronie nie ma wcale). Te 4 to uczciwe 503, nie
awaria po naszej stronie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wczorajsza poprawka objela tylko galaz zapasowa (link vikingfile w tresci strony), a
nie te, ktora obsluguje nowsze sceny, gdzie vikingfile JEST iframem. Polowa katalogu
dalej dostawala wiec stary adres vikingfile.com, ktory oddaje 302 na inna domene,
WebView to blokowal i zostawal czarny ekran.
Znalezione dopiero, gdy sprawdzilem KONKRETNA scene zglaszana przez uzytkownika
("Stella Cox passes on tennis") zamiast losowej probki: resolve oddawal
vikingfile.com, mimo ze losowe sceny testowane wczesniej oddawaly juz vik1ngfile.site.
Po poprawce na 10 losowych scenach: 9 oddaje vik1ngfile.site, 1 bez zrodla.
Kontrola pliku: 2,93 GB, nazwa zgodna ze scena.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trzecia proba i tym razem z dowodem z emulatora, a nie ze zgadywania. vikingfile.com
oddaje 302 na INNA domene (dzis vik1ngfile.site). WebView w aplikacji celowo blokuje
przejscie top-frame na inny eTLD+1, zeby popundery nie przejmowaly ekranu, wiec to
przekierowanie bylo odrzucane i zostawal czarny ekran. Z serwera tego nie widac, bo
httpx sledzi przekierowanie po cichu; widac dopiero w przegladarce na urzadzeniu,
gdzie w pasku adresu stoi vik1ngfile.site.
Poprawki:
- ekstraktor oddaje adres DOCELOWY (rozwiazuje 302 przy kazdym resolve, bo domena
zapasowa rotuje), wiec aplikacja od razu otwiera wlasciwa domene i zadna zmiana
domeny w ogole nie zachodzi
- wzorzec hosta we wstrzykiwanym skrypcie obejmuje obie pisownie (vik[i1]ngfile.),
wczesniej dopasowywal tylko vikingfile.com, wiec po przekierowaniu w ogole sie nie
uruchamial
Przy okazji z emulatora widac, ze zabezpieczenie to CHECKBOX "Verify you are human",
czyli wymaga kliniecia. Dlatego strona musi byc widoczna i uzywalna, a nie schowana.
Opublikowane OTA na 1.2 i 1.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Korekta mojej wczorajszej diagnozy. Twierdzilem, ze stary katalog galaxyporn padl po
stronie hostera: player wypisuje "Video is not ready yet", a /api/v1/video oddaje
payload BEZ jakiegokolwiek adresu wideo (75% probki 16 scen). Objawy sie zgadzaly,
wniosek byl zly.
Na TYCH SAMYCH stronach jest link do vikingfile, tylko nie w iframie, lecz w zwyklym
<a href>, wiec go nie widzielismy. Pliki tam zyja: sprawdzone trzy, 890 MB, 742 MB i
2,5 GB, nazwy zgodne ze scenami. Zwietrzaly byl iframe (news.upns.pro,
sport.seekplays.com, galaxy.4meplayer.pro), zostawiony po migracji.
Szukamy wiec vikingfile po calym HTML. Kolejnosc celowa: seekplayer PIERWSZY, bo
resolwuje sie po naszej stronie i gra bez CAPTCHA, vikingfile jako ratunek, ktory
kosztuje usera przejscie Turnstile w WebView. Martwy player potrafi RZUCIC
(HosterDead przy 404), nie tylko oddac pustke, wiec lapiemy tez wyjatek, inaczej
ratunek nigdy sie nie wykonuje.
Na 12 losowych scenach: bylo 0 rozwiazanych, jest 11. ZADNYCH scen nie kasujemy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Znalezione w nocnym smoke tescie (9 ostrzezen, w tym trzy ekstraktory po 0/3).
vjav: /api/videofile.php oddaje z serwerowni 429 i 343-bajtowa strone, ktora w JS
ustawia JEDNO ciasteczko i sie przeladowuje. Wartosc jest wprost w tej odpowiedzi,
wiec czytamy ja i powtarzamy zapytanie, bez wykonywania JS. Sprawdzone: druga proba
oddaje 200 i poprawny JSON. Bylo 0/3, jest 5/5.
galaxyporn: serwis przenosi NOWE wgrania na vikingfile.com. Probka: 12/12 najnowszych
scen na vikingfile, 12/12 najstarszych dalej na rodzinie seekplayera. Vikingfile chowa
wideo za RENDEROWANYM Cloudflare Turnstile (turnstile.render, bez trybu invisible), a
<video> jest puste i ukryte, dopoki wyzwanie nie padnie. Serwerowo nie do obejscia,
wiec oddajemy embed jako type=hoster i telefon otwiera go w WebView z domowego IP.
Rozroznienie po hoscie, bo seekplayer jako SPA w WebView pokazuje pusty player.
Najnowsze sceny: bylo 0/3, jest 3/3.
ZOSTAJE OTWARTE: rodzina seekplayera zmienila format odpowiedzi /api/v1/video. Stary
klucz AES dalej odszyfrowuje poprawnie, ale w miejsce sources sa teraz pola pk,
streamingConfig i hlsVideoTiktok ze SCIEZKA wzgledna. Zlozenie jej z hostem playera
daje 404, a z domenami z streamingConfig 403, wiec URL jest podpisywany po stronie
klienta z pola pk. Dotyczy starego katalogu galaxyporn ORAZ pornbusy (0/5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1745 wystapien w 291 plikach (backend, scripts, mobile). Dominowal jeden ksztalt,
' — ' laczace zdania, wiec poszedl przecinek; myslnik otwierajacy mysl zdjety;
zakresy 0–5 i A–Z na dywiz.
Podzial komentarz/kod robil skaner stanow, nie regex, zeby nie ruszyc myslnika
stojacego w stringu albo w wyrazeniu regularnym. Potwierdzone maszynowo: po wycieciu
komentarzy z wersji HEAD i z dysku obie sa identyczne we wszystkich 291 plikach,
czyli poza komentarzami nie zmienilo sie nic. 233 pliki .py parsuja sie bez bledu,
tsc ma te same 11 bledow w tych samych 3 plikach co przed zmiana.
Dwie rzeczy wymagaly poprawki po automacie: wyrownane listy definicji, gdzie myslnik
byl separatorem kolumny (37 miejsc, kolumna przywrocona), i trzy przeniesienia mysli
do nowej linii, gdzie zostawal wiszacy przecinek na poczatku (poprawione recznie).
Bundla nie republikuje: Hermes i tak nie niesie komentarzy, wiec dla uzytkownika
to zero zmiany.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
galaxyporn.net carries paysite rips with a dedicated <div id="video-actors">
cast block (no sidebar pollution), studio + date in the title prefix, healthy
/page/N/ pagination. Measured orphan risk is low: 92% of a 75-performer
sample already have a tpdb/stashdb ref in our DB and 79% of titles match
scenes we already hold.
seekplayer_engine host regex widened to cover seekplays|4meplayer|ezplayer|
seeks|upn and the pro|cloud|one TLDs. This is the same engine (identical
AES key/IV and /api/v1/video endpoint), just newer domains; the whitelist is
additive so existing hosts keep matching (verified, including that
upns.evil.com is still rejected). Unlocks all four galaxyporn player hosts
and the same family on other sites.
Two things the extractor had to get right:
- Call seekplayer_engine directly rather than via extract_stream_from_hoster:
the wrapper verifies the resulting URL and the hotlink-guarded HLS 403s, so
it discarded correctly decoded streams.
- Referer must be the PLAYER origin, not galaxyporn.net. With the site referer
the manifest 403s; with the player origin it returns 200. Verified end to
end: manifest 200 -> variant 200 (570 segments) -> segment 206.
Duration is absent from the HTML, JSON-LD and player payload, and a NULL
duration would silently hide scenes behind the min_duration_sec filter (the
porntrex incident), so it is computed from the player's thumbnail.vtt last
cue. The player API throttles bursts, hence the retry/backoff: that took
missing durations from 9/21 down to 3/21. The value runs ~2% short of the
true length (one thumbnail interval), which beats having none.
Pilot: 21 scenes/page with studio 21/21 and clean cast (max 3), ingest of
2 pages = 42 seen, 34 new, 8 merged, 0 errors.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
