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

no ja bych prave rekl ze u me je neprimy odkaz na soubor s tokenem,ale do TVh se i z toho externiho souboru stahne prave ten odkaz primo z toho souboru ktery se meni a pak se uz nezmeni

Tak super, uz mi to bezi, ALE....
V Kodi se to automaticky obnovilo, ale problem s klientem Smart IPTV. Ten se odkazuje na stary stream... je nejaka moznost mit vygenerovany playlist, ktery bude odkazovat na cislo programu a ne na primy odkaz na stream ??kdyz vim ze dany program ma cislo 4000 a druhy 4002( to se me doplnuje automaticky z network)

PS: vyreseno

http://login:pass@IPTV:9981//stream/channelnumber/4000

myslíš takto?
http://IP:9981/stream/channelnumber/4000

Ne, pokud jsem dal jedno lomitko za ipadresu a port tak to neslo, takze dve lomitka

PS: lze nejak generovat playlist podle tab channel ?? Aby se mi vyexportoval playlist na cisla kanalu ??

@Konycz Myslíš playlist kanálů z Tvheadnend serveru? Já myslím, že takový playlist k dispozicii není. Ale pokud si tam, kde playlist potřebuješ, zadáš jeho adresu v TVH http://<ip>:9981/playlist, tak je to jedno. Budeš mít vždy aktuální playlist, seřazený podle čísel kanálů. Interně sice bude odkazovat na id kanálů, ale to asi v daném případ použití nevadí. Tedy pokud si ten klient dokáže poradit s občas se měnícím obsahem playlistu.

Pak máš ještě jednu možnost, stáhnout si playlist z TVH serevru a zeditovat si jej na čísla kanálů, ale pak si jej musíš už udržovat sám, po každé změně editovat, atp. To je ale dost nepraktické.

Jinak, obecně by asi bylo vhodné parametrizaci TVH serveru koncipovat tak, aby se id kanálů (a tedy služby - změna id kanálu proběhne při novém namapování změněných služeb - služba se změní tak, že se starý zruší a nová vytvoří, což vede k vytvoření kanálu s novým id) pokud možno neměnily. Tzn. nepřímé odkazy z playlistu na měnící se streamy, jak už tady padlo několikrát.

---

Rozšířené parametry v playlistu Tvheadend - Sledovanitv.cz(sk)

Kdysi jsem tady popisoval možnosti rozšíření parametrů předávaných z playistu do Tvheadend. Nyní jsem přišel na jednu drobnost, která může někomu ušetřit pár minut laborování. Týká se použití playlistu ze Sledovanitv.cz (a asi i Sledovanitv.sk).

Playlist, který si můžete stáhnout z webu Sledovanitv.cz nemá v rádku #EXTINF:, tak jak je to obvyklé, v parametru délky přehrávání streamu uvedenu -1, tedy jeho typický řádek #EXTINF: vypadá následovně:

#EXTINF:,ČT1

Pokud playlist s takovými řádky #EXTINF: zadáte do Automatic Network Tvheadened serveru, bude to fungovat. Pokud se však rozhodnete do řádku vložit další parametry, jako např.

#EXTINF: tvh-tags="IPTV",ČT1

fungovat to nebude optimálně. Parser Tvheadned nenajde jméno porgramu a dosadí míst něj adresu streamu. Je tedy nutné, při editaci takového playlistu vrátit za #EXTINF: parametr -1, tedy

#EXTINF:-1 tvh-tags="IPTV",ČT1

@Konycz Tak mi to nedalo a zkoušel jsem něco najít a nepodařilo se mi to. Ono jo to web api Tvheadend zdokumentované hodně sporadicky. Ale pokud si stáhneš z Tvheadend jeho playlist dostaneš něco takového:

tak si s tím dej práci zedituj si to na něco takového:

BTW Profile samozřejmě zadávat nemusíš, použije se default (tedy pass), ale umožňuje to případně změnit ho na jiný, což může být někdy výhodné. 

Má to samozřejmě také háček, celkem pochopitelný. Pokud se ti změní čísla kanálů přestane to fungovat dobře. A pak také ještě jeden, ne zcela viditelný. Pokud máš v TVH i Radio kanály a máš je číslované stejnými čísly jako TV kanály, tak z playlistu se ti po zadání čísla kanálu přehraje ten, který je v seznamu Programů Tvheadend zařazen dříve. Možná, že lze do volání api nějak zadat typ zdroje (Radio nebo TV), ale zatím jsem nezjistil jak.

K čemu je pipe:// v parametrech muxu?

Založil jsem tento stream na základě výsledků snahy dostat do Tvheadend IPTV (či  správněji OTT) adresy streamů. Myslím, že problematika je celkem zřejmá a v tomto tématu fóra celkem dostatečně popsaná. Přesto stále dostávám dotazy, co to to pipe:// v parametru muxu (nebo v playlistu, z kterého se ale do parametru URL: v případě IPTV Automatic Network dostane) vlastně znamená a jak to tedy vlastně celé funguje.

Takže velmi stručně:

1. Pokud se v parametru URL: muxu objeví cokoli, co nezačíná pipe:// a má nějaký známý tvar adresy, Tvheadend to pokládá za adresu streamu, který se následně snaží přijímat a analyzovat (tomu se říká scan). Pokud ho vyhodnotí jako OK, tzn. že na smysluplné adrese rozpoznal zdroj streamu kterému rozumí, vytvoří pro něj službu a po namapování (ručním či automatickém - viz Bouquets) i program.
   
2. Pokud ale text v parametru URL: začíná pipe://, pracuje Tvheadend s tím co následuje jako s aplikací (např. ffmpeg), kterou se pokusí spustit a očekává, že mu tato aplikace začne přes její STDOUT předávat obsah streamu (proto pipe://).  A stejně jako v předchozím případě, pokud ho Tvheadend vyhodnotí jako OK, vytvoří službu a po namapování i program.
   

To samé, co je popsáno v předchozích dvou bodech, se pak děje i v okamžiku, když se spouští vytvořený program. Jedno zda z nějakého klienta nebo například pro potřeby nahrávání v samotném Tvheadend. Znamená to, kromě jiného, že se v případě ad. 2 pokaždé spustí nová instance aplikace následující za pipe://. Tedy i v případě, když přepínáte jeden program za druhým, se vždy při přepnutí znovu spustí nová instance aplikace (a stará ukončí). V případě spuštění některých aplikací, které v tomto případě přicházejí v úvahu (ffmpeg, wget, atp.), může mezi jejich spuštěním a chvílí, kdy začnou stream posílat na STDOUT, uplynout kratší či delší (třeba v případě ffmpeg) prodleva. Ale to je už jiná kapitola...

@Konycz Hledal jsem něco v předchozích postech tohoto vlákna a všiml si, že používáš klienta Smart IPTV k příjmu streamů z Tvheadend serveru. Docela by mě zajímalo proč? Proč nepoužiješ klienta Tvheadend?

v Kodi pouzivam TVHeadend a v TV samozrejme Smart IPTV

@Konycz Sorry, zkrat. Mně při čtení Smart IPTV naskočil Simple IPTV. Zapomeň na to...

Redukce zpoždění při použití ffmpeg: -loglevel

Při použití v řetězci zpracování stream používáme ffmpeg, dochází k jisté prodlevě při zahájení sledování daného kanálu. To je pochopitelné. Stejně jako je pochopitelné, že se každý snažíme toto zpoždění omezit na nezbytné minimum. Poprvé jsme na fóru toto téma otevřeli ve vlákně o příjmu internetových radií Tvheadend a internetová rádia, kde k tomu účinně přispěli @mobilemanic a @marhyz - viz jejich příspěvky na 1. stránce, které doporučuji si přečíst! Já jsem se teď k tomu vrátil a začal s těmi doporučeními laborovat. Při té příležitosti jsem se zajímal také o parametr -loglevel.

Obecně má člověk tendenci, pokud chce něco zrychlit, tak omezit počet parametrů pod mylným dojmem "méně parametrů - méně funkcí". V případě -loglevel je to ale přesně naopak, tento parametr totiž rozsah funkce ffmpeg redukuje. Vyjmutím parametru probíhá logování na default úrovni, což mimo jiné znamená, že se na výstupu, který je v tomto případě směrován na Tvheadend, před vlastním streamem objeví i známá sada pro tuto chvíli zcela nepodstatných informací. To Tvheadend určitě nějaký čas zabere.

Jednoduše řečeno, oproti původní představě, že parametr -loglevel fatal je lepší vynechat platí, že je minimálně lepší ho tam ponechat. Níže uvádím ukázku logu Tvheadend bez tohoto parametru a s tímto parametrem:

Log Tvheadend bez použití parametru -loglevel fatal - spuštění a zastavení jednoho programu:

a to samé s použitím -loglevel fatal:

Kdo chce jít ještě dál a může úroveň logování omezit ještě více, např. -loglevel panic, či dokonce až na úroveň nejnižší, tedy -loglevel quiet, ale to se samozřejmě v běžném provozu neprojeví. Úroveň fatal je tedy v tomto případě zcela na místě.

Někdo možná namítne, že jde o pouhé ms, v tomto případě je to 233 ms (ono to samozřejmě nemusí nutně znamenat, že těch 233 ms trvá právě jen zpracování výpisu ffmpeg), ale jedna ms k druhé a může to už začít být zajímavé.

A poznámka na závěr. To není samozřejmě všechno. O dalších redukcích se píše v příspěvcích o kterých píší výše (viz -probesize nebo -analyzeduration). Zkusím provést nějaké pokusy a měření případně se tady o tom také rozepíšu.

Přátelé, nesetkali jste se někdy s něčím podobným? Mám streamy od jistého "poskytovatele" - mpgets, což by mělo být pořádku. V IPTV Simple Client addon se mi přehrávají naprosto bez problémů, to samé ve VLC. No ale pak, po průchodu TVHeadendem se mi dějí velmi zvláštní věci. Kodi 18 HTPS klient -přehrávání není plynulé, nestíhá se plnit buffer - když kouknu do codec info, tak vidím, jak položky aq vq lítají mezi 99% a 0%, kdy na nule se přehrávání zastaví, naplní se buffer a tak stále dokola.

@Rene.hav Můžeš zkusit nastavi chache v Kodi na komunikaci i v interní LAN, ale nejsem si jistý, jestli se to na HTSP bude aplikovat. Nepíšeš, jakou máš verzi Tvhedand serveru? Zkus se případně podívat sem, myslím, že je to dost podobné.

A rychlý workaround? Sice drsně brutální, ale pokud tě to opravdu trápí, tak by to mohlo pomoci. Jak píše @J Smith, prohnat to přes ffmpeg.

A nebo zkus ještě jeden vůbec nejrychlejší a banální trik, který sice nic neřeší, ale pokud se chceš dívat v klidu a hned, tak by to (snad) pomoci mohlo. Timeshift. Po spuštění streamu dát na chvíli stop, stream se načte do timeshift bufferu a po play už to pojede plynule.  [url=https://tvheadend.org/boards/4/topics/29249][/url]

@JiRo: Cache nastavenou mám, ale tím to asi nebude, mám celkem rychlé připojení (150/Mbps download) a ten samý stream mi IPTV Simple Clinetovi běží bez problému.

ffmpeg nepomohl, je to sice stabilnější, ale stále se občas ukáže prázdný buffer a čekání na naplnění :/

Jasně, Timeshift to eliminuje a stačí i pár sekund, ale to je takový.. no prostě blbý :)

TVHeadend 4.2.6 mi běží na Synology NASu s Intel procesorem a 8Gb paměti, klienti jsou Nvidia Shield a iMac - vše ve stejné, gigabitové LAN.

@Rene.hav Doufám, že v tom ffmpeg nemáš parametr -re! Jinak ano, ffmpeg to většinou zlepší, nevyřeší ale úplně. Já má na některých streamech, které posílám do Tvheadend přes ffmpeg s parametrem -re buffer v Kodi kolem 20 %, bez parametru -re kolem 70 %. Taky je ještě možné u ffmpeg laborovat s -rtbufsize. Ten timeshift jsem uvedl pouze jako rychlé řešení, samozřejmě trvale je to víc než blbé řešení. 

JiRo: ten timeshift se provádí jak. Mě to funguje jen když dám nahrávání...Kklasicky při spuštění streamu a stop se vypne celý stream....

@JiRo: Samozřejmě, že jsem tam měl parametr -re, protože jsem jen tupě zkopíroval nějaký příklad použití ffmpeg, který jsi uvedl ty tady na fóru, aniž bych si zjistil, co jednotlivé parametry znamenají :)
Nicméně po odstranění -re to vypadá konečně dobře, buffer nepadá pod nějakých 30 %.

@Rene.hav Za to -re se omlouvám, nakonec se ukázalo, že je vhodnější ho nepoužívat. Zkusím ta místa, kde to bylo v minulosti uvedené, nalézt a okomentovat to tam.

---

@otava5 V klientovi dáš Pause, chvíli počkáš a pak Play. 

Ty se omlouváš? Doufám, že z toho jak jsem tu větu napsal jasně vyplynulo, že jsem to já, kdo udělal chybu.
Každopádně děkuju, moc jsi mi pomohl.

JiRo: nemám pause jen stop / rec.... zvláštní....