Přihlásit se na XBMC-Kodi.cz

@Rene.hav Asi nějak takto:


Obecně vzato je struktura ffmpeg parametrů asi takováto:
Pro TVH je výstup definován tím pipe:1, což znamená stdout.

Ad TVH & Synology. Nevím, jestli si kompiluješ TVH sám nebo používáš Synology aktualizaci. Většinou ty jejich aktualizace nebývají úplně ty nejnovější.

@JiRo: přesně takovéto nakopnutí jsem potřeboval, děkuji!

Používám instalaci ze synology "App Storu" - kompilovat si aplikaci sám.. na to vůbec nemám ambice(=dovednosti) :)

Zdá se, že pomohlo doplnit User-agent: foo do vlastních HTTP hlaviček, nemám šajn, co to má dělat a ani se mi to zatím nedaří dohledat, ale po dni testování (což není moc) to vypadá jako fungující řešení.

Tak ne, nepomohlo. Objevila se v logu hláška, kterou následuje zářez: service instance is bad, reason: No input detected - pro mě nic neříkající. Asi to pro mě znamená konec s TVH. Patrně na to můj zdroj streamů prostě není stavěný.

Hlásím se po delší době, a konečně s dobrou zprávou. Pokud bude mít někdo problémy stejné jako já a to tedy: streamy skrz TVH honím pomocí ffmpegu, ale bojoval jsem s tím, že jsem při přehrávání stremů v Kodi dostával od HTSP klienta hlášku "No Signal" - stream se zastavil a přerušil se Timeshift. Ovšem po zapnutí funkce "Use packet backlog" se vše, jako mávnutím kouzelného proutku spravilo. Vše jede naprosto bez potíží. Nejsem schopen poskytnout vysvětlení, protože ho sám neznám a po všem tom dlouhém a bolestném bádání teď nemách chuť se po něm pídit. Důležitý je pro mne teď výsledek, kterým je bezvadně fungující TVHeadend server.

@Rene.hav Výborně. Přinesl jsi další zajímavý poznatek. Díky.

Zní to logicky. Chápu to tak, že když to zapneš, tak se TVH při porušení kontinuity na to nevykašle a session neuzavře, dělá jakoby nic a nechá na klientovi, aby si s tím poradil. Ne každý klient to zvládne se ctí, ale Tvheadend HTSP Client ve spolupráci s Playerem a bufferem v Kodi ano.

Zajímavé by bylo si ten OTT/IPTV zdroj pustit, zobrazit si vedle sebe log a Stav > Stream TVH, log Kodi a jeho Ctrl+Shift+O. Hodně by to o tom, co se v celém řetězci zpracování streamu děje, povědělo. Na druhou stranu, chodí ti to, tak zas není tolik nutné se v tom šťourat. Jak jsi hezky a správně napsal, důležitý je výsledek.

@JiRo: Chápeš to správně. Já vlastně pořád v logu TVH nacházím hlášku "service instance is bad, reason: No input detected" ale stream se nezastaví, Kodi a jeho buffer to ustojí a přehrává se dál. V Stav > Stream TVH vidím, že input je v tu chvilku na nule, pak následuje nula na outputu a v ten moment to jede z bufferu Kodi a jeho Playeru. Celé se to stane třeba ve 3 sekundách, možná ani ne. Pak zas naskočí data na inputu a během dalších 1-2 sekund se srovná množství dat input/output a jede se dál. Kodi buffer v tu chvíli přijde třeba o 30% dat, která si ale po tomhle procesu doplní.

Co je ale důležité, uživatel u klienta o ničem z toho neví :)

Je to celé zvláštní, protože pokud ten samý stream hodím do IPTV Simple Clienta, můžu ho sledovat hodiny, možná celé dny s plným bufferem bez škobrtnutí.

Budu se po tom pídit, když už jsem se do toho takhle položil, tak to jen tak nenechám, ale asi jako všichni v tomto ročním období, volného času mám pomálu. :)

@Rene.hav Ta situace u IPTV Simple Clienta je mnohem jednodušší. On vlastně nic nedělá, jen předhazuje adresu (přes funkci Live TV) streamu Playeru v Kodi, takže celé to řízení toku dat se děje pouze na jednom místě a je tam v cestě jen jeden buffer. V případě, pokud to jde přes Tvheadend, tak jsou to místa tři (ffmpeg, Tvheadend a Player) a každý má svůj menší či větší buffer a zpoždění a také má každý svou strategii řízení toku dat, které spolu nemusí "ladit" a ty jednotlivé strategie mohou působit proti sobě. To co popisuješ, ta návaly dat, pak zase žádný přenos, kdy si klient bere pouze data z bufferu, to je přesně ono. BTW Zkusil jsi tam dát to -re? A mělo to nějaký vliv? Tady by asi chtělo vyzkoušet si to stream po streamu (tedy pokud je máš z různých zdrojů), protože pro některé zdroje streamů tam to -re může působit negativně, pro jiné zase naopak pozitivně. Ale máš pravdu, pokud to teď chodí, tak si šetři čas na příjemnější věci. 

@JiRo: Ano, -re jsem zkoušel, ale nepomohlo mi, naopak při jeho využití se buffer Kodi plnil jen do asi 35% a přineslo mi to víc potíží. Když mám zapnutou tu funkci Use packet backlog, tak parametr -re nevadí, zároveň mi ale nepřináší nic užitečného, takže nepoužívám. Pak jsem zkoušel i parametry -reconnect... a ty se mi za žádnou cenu nepovedlo do příkazu zařadit tak, aby to fungovalo.

@Rene.hav OK. Díky za info.

@Rene.hav: Máš velmi zvláštní zdroj, ale tak dobře, že se to dalo nějak vyřešit. Kde je ta funkce pro buffer v TVH, nikdy jsem to tam neviděl, zřejmě nějaká novinka z poslední doby v aktuálním buildu..

@mobilemanic Configuration > Base

Ahojte,

potreboval by som poradiť s  nasledovným problémom.
Ako mediacenter mám starší notebook na ktorom mi beží LUBUNTU 18.04 s tým že bootuje priamo do KODI. K NB mám pripojený DVBT USB kľúč a dalšie kanály mám cez IPTV, používam aj TVHEADENT aj IPTV SIMPLE CLIENT, takto mi to vyhovuje mám tak vyriešené nakomplet EPG.

IPTV používam z viacerých zdrojov. Čo ma trápi je to že som sa dostal k streamu určitých CZ kanálov, ktoré sú blokované na CZ IP. Na LUBUNTU mám nastavené dostatočne rýchle VPN s CZ IP adresou. Je nejaká možnosť prideliť týmto kanálom aby sa prehrávali cez VPN pripojenie a ostatná časť systému vrátane stream cinema šli klasicky bez VPN?
SC používame aj na tablete a nerád by som prišiel o konto z dôvodu súčasného používania na viacerých IP. A taktiež cez CZ VPN mi zase nejdú niektoré SK kanály.

Vopred ďakujem

@petulko11 Tak nejprve se zeptám, proč používáš současně Tvheadend a IPTV simple Clienta. Když už tam ten Tvheadend máš, tak přes něj pouštěj všechno, ne?

Nevím, jaké VPN používáš, ale klasické VPN by ti mělo vytvořit vytváří virtuální interface, a na ten bys měl v příslušných muxech v Tvheadend změnit obsah parameteru Interface (Interfejs).

@Client to som objavil aj ja ale práveže v interfaces VPN nemám len sieťovku

VPN som nastavil importom súboru ovpn cez network-manager. Tam aj normálne vidím VPN ako samostatné pripojenia.
Je ešte iné VPN?

&Client: malý dotaz. Včera jsem měl naplánováno nahrávání z irádia... Nahrávalo jenže vypadl internet na pár minut a ono už se to nedonahrálo....Zůstal záznam jen po tu dobu do výpadku internetu.
Jak kde co nastavit aby se mi to i při výpadku nepřerušilo lépe řečeno donáhralo ....
Udělal jsem test spustil nahrávání dal restart routeru a konec...
Děkuji za radu ....

---

V nastavení nahrávání:

Klonovat naplánovaný záznam při chybě: zaškrtnuto
Zaznamenat znovu, pokud je počet chyb vyšší než (0=vypnout): nastaveno 0

@otava5 To jsem nikdy neřešil, a ani nevím, jak by to mělo správně fungovat. Nejsem si jistý, co to "klonovat" a "zaznamenat znovu" vlastně znamená. Spíše bych to viděl tak, že při "klonovat" se automaticky pokusí vytvoří další záznam (hledá v EPG ještě jednou to samé, ne?). Nebo ty si myslíš, že by to mělo spustit znova nahrávání? Zkusím pohledat a případně i vyzkoušet. Nastavil jsem si hodnotu parametru "zaznamenat znovu" na 1 a pustil pár nahrávání. Uvidím, co se stane po chybě.

---

Zkusil jsem nastavit "zaznamenat znovu" na hodnotu 1, u všech ukončených záznamů s "fajfkou" a u všech nezdařených záznamů se objevilo "+". Podle všeho by se tato nahrávání měla spustit znova, ale je co a jak to nahrávání nastaví, to mi není jasné. No, nechám to chvíli tak nastavené a uvidím, jak se teď Tvheadend a nahrávání bude chovat.

otava5: Hledáš to na špatném místě, v nastavení "Profilu streamu" musíš mít nastaveno "Restart on error" nebo tak nějak... Jsou tam i další škrtátka, která to ovlivňují, ale tohle je nejdůležitější...

Ty v nastavení "Profilu nahrávání" opravdu už řeší jen jaké má být chování poté, co to vážně selhalo..

@mobilemanic, @otava5 Mám na to trochu jiný názor (zdůrazňuji to názor, protože nevycházím z ověřených faktů, ale pouze z toho, jak si myslím, že to je). Profily streamů se týkají výstupních streamů Tvheadend. Pokud je něco, čím se dá ovlivnit zpracování vstupního streamu do Tvheadend při chybách, tak snad "Maximální čas odezvy (sekund):" v parametrech Sítě. Ještě to ale případně komplikuje vložený ffmpeg, který má také vlastní chování při chybě, takže dopátrat se toho, co a jaký má vliv a zda se s tím dá něco dělat bude asi krapet složitější.

Čeho, jsme si při krátkém testu všiml, tak pokud se zastaví tok ze zdroje OTA/IPTV (vytáhnu konektor z routeru), tak se ffmepg vůči Tvheadend chová "jakoby nic", obraz v Kodi zamrzne a visí tam, když se tok streamu ze zdroje obnoví, tak to pokračuje dál od aktuální pozice vysílání. U nahrávání to je stejné, prostě tam ta část chybí, ale po zastrčení konektoru nahrávání pokračuje dál. Mimochodem, ty dva zmiňované parametry DVR profilu na to nemají vliv.

Když to shrnu, pro mne ta záležitost není nijak důležitá. To, že by se mi něco nenahrálo je sice nepříjemné, ale jednak se mi to ještě nestalo (náhoda) a jednak to není nic životně důležitého. Navíc, když by vypadl internet a něco se mi po dobu výpadku nenahrálo, tak ta neúplná nahrávka pro mne stejně nemá cenu. Asi tak...

---

Tak jsme se dopátral výsledku při nastavení hodnoty > 0 u parametru Zaznamenat znovu, pokud je počet chyb vyšší než v profilu nahrávání. Skutečně, pokud se v nahrávce objeví více jak nastavené množství chyb, tak se nahrávka naplánuje znova. V záložce Budoucí/současné záznamy se u ní ve sloupci Komentáře objeví text Re-recording. Ty chyby se ale mohou objevit i v případě, že nahrávka je celá a pouze jsou v ní nějaké větší problémy v diskontinuitě, dropoutech, apod. Takže ani to není úplně nejšťastnější řešení.

děkuji Vám oběma.... ale mě při znovupřipojení internetu dál nepokračuje....to je ten důvod proč to řeším....