[JiRo]

Zrušeno...

[oldx]

Zdravím, předně chci říci že všechny Vaše příspevky jsou velmi zajímavé a přínosné. 

Ohledně toho o co se teď pokoušíte bych ale řekl že by to chtělo udělat nejdříve trochu rozbor zda není lépe použít nástrojů které tady máme sami o sobě v open sourcech a jsou na jednotlivé oblasti specializované a především aspoň nějakou komunitou průběžně testované a udržované. Jen je třeba je "jen" prodrátovat a občas i "jen" nakonfigurovat.

Co si myslím že duplikujete je
- databázový registr zdrojů což je ono sjednocení playlistů a zdrojů
- socket server vybírající nejlepší zdroj což mi přijde jako balancer případně ve slabší verzi jako health-check či probe
- možná že ve vysledku nechcete jít dále než za orchestraci a pak by stálo za to mrknout na takové jako Ansible a jemu podobné 
- nakonec i zda není lepší přidat skripty do nějakého open-source NMS, dostanete rovnou i GUI 

Přece jen těch skriptovacích projektů různě dodělávajících pro tvh všechno možné je dost a opuštěno jich bylo posléze taky hodně.

Díky!

[JiRo]

To jsou jistě správné myšlenky, ale já takové ambice, vytvářet nějaký diverzifikovaný projekt, nemám. Nejsem v oblasti programování profesionál, a s ohledem na věk se už nehodlám do této oblasti pouštět víc, než je pro splnění konkrétního účelu bezpodmínečně nutné. Nehledě na to, že kromě vyvoření popsaného cílového řešení, je pro mne zajímavá i cesta, která k tomu, a to zejména prostřednictví programování v python, vede.

V Tvheadend mám za sebou fungující příjem z více než dvou desítek zdrojů různého typu a popsaný princip failover-u je to, co mi pro velkou skupinu z nich chybí. Proč, to jsem už popsal. Vím přesně co potřebuji, projekt jsem si přesně ohraničil, a jeho realizace je v souhrnu záležitost jednotek až nízkých desítek hodin programování, které pro mne jsou a ještě budou příjemně strávenými chvilkami. Jen pro dokreslení, zatím jsem popisem toho řešení tady a fóru strávil zdaleka nejvíce času. A to už mi ten základní rámec klient - server dvojice a jeho použití v Tvheadend funguje v téměř finální podobě.

Když nic jiného, tak mé řešení berte jako ověření funkčního konceptu. Bude-li svými výsledky odpovídat očekávané představě, nebude jistě pro někoho problém ho vytvořit v podobě a způsobem jak navrhuje @oldx:. Každopádně díky mu za podnětné názory. Takhle se mi to na fóru líbí...

[martinchromy1985]

držím palce a hlásím se jako tester:-)

[JiRo]

Zrušeno...

[JiRo]

Asi dlužím řadě zdejších uživatelů vysvětlení, proč jsem tento projekt zařízl. Dostal jsem několik žádostí o poskytnutí aplikace na testování, a i když jsem z počátku potenciálně uvažoval o tom, že aplikaci zvěřejním - samozřejmě s prázdnou databází - nikdy k tomu nedošlo. Možná to @oldx: vystihl správně, ale dostat řešení do konečné podoby, na to už jsem neměl ani čas, ani chuť.

Aplikace funguje více než dobře, od listopadu loňského roku mi jede na 24/7 běžícím serveru, kde, kromě jiných,  provozuji i Tvheadnd a Webgrab++,  nepřetržitě. V databázi mám, kromě vstupů z různě získaných playlistů, skupin adres či jednotlivých adres, i celé OTT služby (Sledování TV, Oneplay, TV Magenta a další). OTT služby sice trvale neplatím, ale jsou připraveny pro případné použití (stačí jen zaplatit na další období) při situaci, kdy by ostatní vstupy zklamaly. Ale protože mám pro většinu většinu kanálů více zdrojů, OTT služby zatím nepotřebuji. Databáze v současné chvíli obsahuje necelých 2400 adres streamů pro celkem 370 kanálů, seskupených do 22 providerů. Kanály OTT služeb do toho nepočítám. Ne všechny steramy jsou funkční, u některých dochází ke kratším nebo delším výpadkům, u některých výpadek trvá už déle. Čas od času projdu statistiku a ty trvale vypadlé z databáze odstraním, ale není to nutné. V podstatě jsem to zatím udělal jen párkrát. Princip aplikace s tím, že některý zdroj vypadne, počítá a nahradí ho dalším, který je v dané chvíli funkční. Co ale v úpravě databáze provádím často, to je přidávání dalších zdrojů, jakmile se k nim dostanu. A to se, i v dnešní době, občas stává.

Co je klíčové, a proč s další vývojem zatím nepočítám, je to, že jsem zcela rezignoval na další práci na aplikaci. Když jsem aplikaci psal a ladil, tak jsem její databázi vytvářel a editoval ručně. Brzy ale těch změn bylo tolik, že jsem potřebval nějaký nástroj na to, abych jednak mohl zdrojová data nějak editovat a také, abych je mohl do formátu databáze (json) jednoduše převést. Abych si pomohl a nemusele se zabývat nějakým sofistikovaným řešením, použil jsem jednoduše dostupný nástroj, a to Excel. S ním jakákoliv úprava získaných souborů dat do konečné podoby tak, jak je definována v playlistu a v databází streamů, dostala zcela jiný rozměr. Jistě, není to nijak elegantní, ale vytvoření jednoduché relační databáze ze získaného playlistu nebo prostého souboru adres streamů je záležitostí pár kliků. A s pomocí nástrojů Excel k hromadnému editování dat, vytváření odpovídajících relací, překladů názvů a dalších podobných relačních tabulek a operací je jednoduché. Jistě, dalo by se to napsat i v python, ale těch zdrojů je velké množství a data, které k nim přicházejí, jsou tak rozdílná, že by to bylo zbytečně složité a navíc by tomu stále lchybělo nějaké smysluplná gui. Ano, v tom měl @oldx: pravdu. Ale ony ty zdroje zas nepřichází tak často a někdy je to jen pár adres, jindy ale zase poměrně velký soubor dat, ve kterých se ale většinou opakují stejné vzorce. Takže Excel je pro to ideální aplikace. Vložit pár řádků jde jendoduše, stejně jako je zatřídit. A stejně jednoduché je vložit celý soubor dat a pak příslušnýn způdobem editovat do požadovaného tvaru. Konečná generace dat je pak záležitostí odpovídajících maker, které se spustí, vytvoří dva klíčové výstupní soubory - jeden společný playlist pro Tvheadend a json soubor s databází streamů. Nemalým přínosem je pak i to, že přímo v Excel si mohu každý stream otestovat i spusti jeho přehrávání (pomocí VLC).

---

Pro ukázku záznamy logu, které osvětlí, jak je celé řešení koncipováno:
 
Spuštění aplikace. Běží jako service, spouští se tedy při startu serveru, případně po změně databáze nebo verze aplikace ručně systémovým systemctl restart ... Log aplikace je čten pomocí vhodně filtrovaného příkazu journalctl... ze systémového logu.
 

Kód:

12:31:04.600227 Server started
12:31:04.600227 Loaded providers: 22
12:31:04.600227 OTT providers initializing starts
12:31:06.144570 OTT provider Sledovani refreshed Session_id: ef99f1deea823e8497b8535df9ca0367
12:31:06.145051 OTT provider Sledovani initialized
12:31:06.145051 OTT provider Sledovani set refresh period 0:10:00
12:31:06.145983 Loaded 2353 streams for 370 services successfully
12:31:06.147757 Loaded history for 922 URLs
12:31:06.148005 OTT provider Sledovani refresh task initializing
12:31:06.148052 Daemon started on tmp/tvh_pipe.sock
12:31:06.148243 Admin TCP started on 0.0.0.0:9989

 
Jen na vysvětlení, OTT službu Sledování TV mám v aplikaci povolenou, i když ne zaplacenou. Je to proto, že nabízí i nějaké služby, které jsou dostupné bez zaplacení.

Jak to vypadá, když si v Kodi spustím nějaký kanál. Log aplikace:
 

Kód:

12:46:05.024529 Command <- @reserve starmaxfamily
12:46:05.122036 Tested http://...m3u8 -> OK in 0.09s (S:9 F:0)
12:46:05.123576 Saved last stream for starmaxfamily: {'url': 'http://...m3u8', 'provider': 'Xyz', 'profile': 'streampeg', 'preset': 'insecure', 'user_agent': 'VLC/3.0.21'}
12:46:05.123576 Selected stream for starmaxfamily: {'url': 'http://...m3u8', 'provider': 'Xyz', 'profile': 'streampeg', 'preset': 'insecure', 'user_agent': 'VLC/3.0.21'}
12:46:05.123673 Response -> OK {"reservation": "6282653f5fe8410cb5f7d74491de8959", "stream": {"url": "http://...m3u8", "provider": "Xyz", "profile": "streampeg", "preset": "insecure", "user_agent": "VLC/3.0.21"}}
12:46:16.281652 Command <- @release 6282653f5fe8410cb5f7d74491de8959
12:46:16.282052 Response -> OK

Jen na vysvětlení, záznam 12:46:05.024529 Command <- @reserve starmaxfamily znamená přijetí požadavku na stream pro službu starmaxfamily. Záznam 12:46:16.281652 Command <- @release 6282653f5fe8410cb5f7d74491de8959 pak zase přijetí požadavku o ukončení přehrávání streamu této služby.

Vlastní streamer, který je spouštěn pomocí konstrukce pipe://... v playlistu Tvheadend, má vlastní logování do souboru. V něm pak výše uvedné spuštění a zastavní přehrávání streamu vypadá takto:
 

Kód:

[2026-07-15 12:46:05.023] START with service: starmaxfamily
[2026-07-15 12:46:05.123] response: OK {"reservation": "6282653f5fe8410cb5f7d74491de8959", "stream": {"url": "http://...m3u8", "provider": "Xyz", "profile": "streampeg", "preset": "insecure", "user_agent": "VLC/3.0.21"}}
[2026-07-15 12:46:05.123] service_pipe(): reservation_id: 6282653f5fe8410cb5f7d74491de8959 service: starmaxfamily
[2026-07-15 12:46:05.123] service_pipe_streampeg() - service: starmaxfamily provider: Xyz
[2026-07-15 12:46:05.123] service_pipe_streampeg - preset_name: insecure preset: {'options': ['--http-no-ssl-verify'], 'stream': ['--default-stream', 'best', '--hls-live-edge', '3'], 'in': ['-fflags', '+genpts'], 'out': ['-c', 'copy', '-f', 'mpegts', '-mpegts_flags', '+resend_headers', '-mpegts_service_type', 'digital_tv']}
[2026-07-15 12:46:05.124] service_pipe_streampeg - streamlink args: ['/home/kodi/.local/bin/streamlink', '--stdout', '--loglevel', 'info', '--http-no-ssl-verify', '--url', 'http://...m3u8', '--default-stream', 'best', '--hls-live-edge', '3', '--http-header', 'User-Agent=VLC/3.0.21']
[2026-07-15 12:46:05.126] service_pipe_streampeg - ffmpeg args: ['/usr/bin/ffmpeg', '-hide_banner', '-loglevel', 'verbose', '-fflags', '+genpts', '-i', 'pipe:0', '-c', 'copy', '-f', 'mpegts', '-mpegts_flags', '+resend_headers', '-mpegts_service_type', 'digital_tv', '-metadata', 'service_provider=Xyz', '-metadata', 'service_name=starmaxfamily', 'pipe:1']
[2026-07-15 12:46:05.129] service_pipe_streampeg - waiting for ffmpeg
[2026-07-15 12:46:16.280] service_pipe_streampeg - SIGTERM received
[2026-07-15 12:46:16.280] service_pipe_streampeg - cleanup

Porovnání logů aplikace a streamer-u je vidět, jak vypadá celé časování, a také to, že zpoždění tím, že dochází k výběru a testování streamů, nijak zásadně dobu spuštění/přepnutí kanálu nijak neovlivní. Vlastní testování dostupnosti streamu, jehož výsledek je vidět v řádku 12:46:05.122036 Tested http://...m3u8 -> OK in 0.09s (S:9 F:0), zabralo pouze 0,09 vteřin.

---

Tak doufám, že jsem nějak srozumitelně vysvětlil, proč tohle řešení není vhodné k distribuci. Docela přesně si dokáži představit, co by se dělo v okamžiku, kdybych ho tu nasdílel. A na to už čas, chuť ani náladu nemám. Tak snad se někdo mladší, aktivnější a schopnější nechá inspirovat...