PusztaPlay – a gépház mélyéről
A PusztaPlayer infrastruktúrája
Nyilvános, titkok nélküli leírás: mi hogyan épül fel, miért úgy, és mi mire jó. A részletes üzemeltetési jegyzet a szerveren él — itt mindenki számára érthetően mesélünk.
Mit csinál a backend?
A PusztaPlayer egy IPTV-lejátszó: a tartalom a felhasználó saját, Xtream-kompatibilis előfizetéséből érkezik. A backend az intelligens középréteg a kliensek (Android TV, Android mobil, asztali alkalmazás, webes lejátszó) és a szolgáltatói panel között:
- egyetlen belépési pont — a kliensek egy kiforrott API-t használnak, nem közvetlenül a szolgáltatót;
- dúsított adatok — borítók, tartalomleírások, szereplők, korhatár, TMDB-azonosítók;
- EPG (műsorújság), rádió- és személy-katalógus;
- okos keresés és ajánlók — szemantikus és hangulat-alapú;
- és minden, ami a gyors, stabil élményhez kell: cache, újrapróbálkozás, hibakezelés.
A kliensek „vékonyak” maradnak: a tudás és a terhelés nagy része a szerveren él.
A nagy kép
Android TV / mobil / asztali app Webes lejátszó (stream.*) WordPress (pusztaplay.eu)
| | fiók, QR-belépés,
| HTTPS (API + média) | HTTPS profil-szinkron
v v |
+---------------------------------------------------------------------------------+
| nginx (TLS, CORS) |
+---------------------------------------------------------------------------------+
| | |
| /api/v1/ | web-player + token-kapu | statikus tartalom,
v v | letöltések, képek
+----------------+ +----------------+ |
| FastAPI (BFF) | | web-app | |
| 4 worker | | (token-kiadás, | |
+----------------+ | stream-feloldás) |
| | +----------------+ |
v v v
+---------+ +------------------+ +------------------+
| Redis | | PostgreSQL + | | szolgáltatói |
| session,| | pgvector | | panel + tárhely |
| cache | | tartalom, EPG, | | (külső, Xtream- |
+---------+ | személyek, vec. | | kompatibilis) |
+------------------+ +------------------+
A lényeg: minden kliens egy kapun (nginx) és egy API-n (FastAPI) keresztül érkezik; a szolgáltatói kapcsolatot, a cache-t és az adatbázist a backend kezeli.
A domének és a szerepük
| Domain | Szerep |
|---|---|
| pusztaplay.eu | WordPress: fiókkezelés, QR-belépés, profil-szinkron, nyilvános oldalak |
| live.pusztaplay.eu | az appok elsődleges API- és média-domainje |
| server.pusztaplay.eu | live. tükörképe — átlátható tartalék és tehermentesítés |
| stream.pusztaplay.eu | a webes lejátszó otthona + a böngészőbarát média-utak + a WP-be ágyazott lejátszó |
Miért három?
- az appoknak a szolgáltatói átirányítást adjuk tovább (a videóforgalom nem feltétlenül a mi szerverünkön folyik át — sávszélesség-kímélés);
- a böngésző viszont HTTPS-t és saját domaint kér (a szolgáltatói tárhely HTTP-n él) — ezért a
stream.*a böngészőnek átproxizza a médiát, így nincs „vegyes tartalom” hiba, és a lejátszó stabilan működik.
A tanúsítvány egyetlen SAN-tanúsítvány (Let's Encrypt, automatikus megújítással) mindhárom névre.
A rétegek
nginx — a kapu
TLS-kezelés, CORS, a HTML-oldalak és letöltések kiszolgálása, a kérések továbbítása. Emellett képátméretezés (a poszterek 7 napig cache-elve, ~10–25 KB), végpontonkénti rate limitek, és a letöltések kiszolgálása — mindig a legfrissebb és az előző verzió.
FastAPI (BFF) — az agy
„Backend for Frontend”: egy API minden kliensnek, négy párhuzamos workerrel. Session-kezelés, dúsított válaszok (borító, leírás, szereplők, korhatár, TMDB-azonosító), szemantikus keresés és ajánlók, EPG, valamint védett admin felület.
Redis — a gyorsítás
Session-tokenek és cache-ek „friss ablak + lejárt kiszolgálás” stratégiával: a felhasználó azonnal választ kap, a szerver a háttérben építi újra a cache-t. Itt élnek a rate-limit számlálók és a demó fiók melegen tartott cache-e is.
PostgreSQL + pgvector — az adat
Egy adatbázisban él a teljes katalógus: filmek, sorozatok, epizódok, EPG, rádióállomások, személyek és szerepek — valamint a szemantikus ajánlók vektorai. Egy mentés, egy karbantartás, nincs külön vektor-adatbázis.
web-app — a webes lejátszó kapuőre
A böngészős lejátszó kis szolgáltatása: tokeneket ad ki a WordPress felé (jelszó nélküli, aláírt azonosítás), és dinamikusan oldja fel a médiacímet, amikor a böngésző streamet kér.
docker-agent — izolált konténer-műveletek
A szerver konténereit kezelő műveletek (indítás, leállítás, naplók) külön, token mögé zárt szolgáltatáson mennek, szűkített jogosultságokkal — a fő alkalmazás sosem nyúl közvetlenül a Docker-hez.
WordPress — a fiókok otthona
A felhasználói fiókok, a QR-kódos belépés és a profil-szinkron (kedvencek, előzmények, folytatás) a WordPress-ben élnek. A backend innen kapja az előfizetés adatait, és ide szinkronizálja vissza a profilokat.
Adatfolyamok
Élő TV
A kliens belép → session-token → letölti a csatornalistát (kategóriákkal, logókkal, minőségváltozatokkal). Lejátszáskor az app a szolgáltatói átirányítást követi; a böngésző a stream.* biztonságos proxy-útját kapja.
Filmek és sorozatok
A /playlist végpontok a dúsított katalógust adják (borító, leírás, szereplők, korhatár, TMDB-azonosító); a sorozatoknál az évadok és epizódok is a backendről jönnek.
EPG
Minden éjjel automatikus import frissíti a műsorújságot; a kereső és a „most megy / következik” sáv ebből dolgozik.
Dúsítás
TMDB-azonosítók, kulcsszavak, életrajzok és tartalomleírások automatikus feldolgozással kerülnek a katalógusba; a leírások magyarul (szükség esetén fordítással).
Ajánlók
Két motor: (1) vektoros hasonlóság a pgvector-rel, (2) TMDB-alapú kulcsszavak és hangulatok. A kettő együtt adja a „Hasonló” és a hangulat-alapú ajánlásokat.
Képek
A poszterek és logók a saját domainünkről, átméretezve és cache-elve érkeznek — gyors listák, kis adatforgalom.
Automatizálás (ütemterv)
| Idő | Feladat |
|---|---|
| 02:00 | Katalógus-szinkron — filmek, sorozatok, TMDB-azonosítók pótlása, epizódok, kulcsszavak |
| 03:00 | EPG-import — a műsorújság éjszakai frissítése |
| 03:30 | Adatbázis-mentés |
| 10 percenként | Állapotellenőrzés — a szolgáltatói panel, az API és a demó fiók; hiba esetén e-mail riasztás (a napi összefoglaló reggel megy) |
| hetente | Személy-katalógus — életrajzok és szerepek frissítése |
Miért így? – a döntések röviden
- Miért BFF?
- Mert a szolgáltatói panel lassú és néha hibázik. A cache, az újrapróbálkozás és a hibakezelés egy helyen él — a kliensek egyszerűek maradnak, és ugyanazt a minőséget kapják.
- Miért Redis cache?
- Hogy a felhasználó soha ne várjon 8–9 másodpercet.
- Miért pgvector?
- Egy adatbázis, egy mentés, egy karbantartás — nincs külön vektor-szolgáltatás.
- Miért proxy a böngészőnek?
- A szolgáltatói tárhely HTTP-n él; a böngésző csak HTTPS-en hajlandó lejátszani. A stream.* ezt hidalja át.
- Miért WordPress a fiókoknak?
- Mert a fiókkezelés, a jogosultságok és a bejelentkezés egy kiforrott, jól ismert rendszerben él — a backend csak azt kapja, amire a lejátszáshoz szüksége van.
- Miért Docker?
- Kiszámítható, egységes környezet; egy szerveren elfér az egész rendszer, és később könnyen átköltözik.
Üzemeltetés és megbízhatóság
- Állapotellenőrzés: 10 percenként automatikus ellenőrzés (szolgáltatói panel, API, demó fiók), hiba esetén riasztás; a szolgáltatások saját healthcheckkel futnak.
- Mentés: napi adatbázis-mentés; a médiacsomagoknál mindig a legfrissebb és az előző verzió marad elérhetően.
- Biztonság: végig HTTPS, végpontonkénti rate limitek, a bejelentkezés session-alapú, a szolgáltatói kapcsolat elkülönítve; a szerveren fail2ban és automatikus biztonsági frissítések.
- Frissítés: fájlonkénti, ellenőrzött telepítés; az API frissítése forgó újraindítással (rolling restart) történik — a szolgáltatás közben végig él.
- Naplók: minden kérés és hiba naplózva, mérésekkel (válaszidők, cache-találatok).
Számok (2026. szeptember)
Érdekel a többi?
A gépház mögött egy alkalmazás is épül — nézd meg, mit tud, vagy merülj el a telepítési útmutatókban.
A PusztaPlayer egy lejátszó: műsorokat, csatornákat és filmeket nem tartalmaz és nem terjeszt — kizárólag a felhasználó saját előfizetésének tartalmát játssza le.
