@delfin-chikago Ano, to mě napadlo také a je dost pravděpodobné, že to tak je. A bylo by to ze strany WS celkem pochopitelné. Tedy to, že ten tok omezí na hodnotu, která je jen o něco vyšší, než průměrný bitrate titulu. Aby to ale fungovalo, měli by mít nějaké info o tom, jaký ten bitrate je. Možná by k tomuhle mohli něco říci pánové z SCC teamu. Ale nebudu do toho šťourat. Pokud to omezování postačí k přehrávání, tak proč ne.
Trochu jiná věc je ale to, co ve svém prvním příspěvku popisuji jako první. Tedy ten případ, kdy se po jistém čase ten datový tok úplně zastaví. Jak jsem dnes dodatečně zjistil, je to na straně Kodi spojené s hláškami, které jsme uvedl v už předchozím příspěvku:
Otázkou je, jestli je to způsobeno tím, že WS přestane na nějakou dobu dodávat data. Ty hlášky tomu nasvědčují. Takže i když jsem si původně myslel, že za to může Kodi, možná to tak není ani v tomto případě, a ten prvotní impuls k tomu, že se se cache přestane plnit úplně, jde také od WS. Kodi v tomto případě pak čeká, až proběhne nějaký timeout, kdy nedostává data (přehrávání to nevadí, protože v cache je dat stále dost) a pak se pokusí o reconnect (CCurlFile::FillBuffer - Reconnect, (re)try 1). Trochu záhadou je, proč se od této chvíle plní cache na nižší hodnotu, než před tím. Za tohle WS určitě nemůže, to je už záležitost čistě Kodi.
No, zatím si tedy, i s přispěním názoru od @delfin-chikago, vytvářím konspirační terorii, že na straně WS běží algoritmus který, pokud zjistí velký datový tok u souboru, který je videem (to asi problém není, WS moc dobře ví, kdo ty request-y zprostředkoval) a buď zná nebo si dokáže zjistit jeho průměrný bitrate, tak ten tok prostě omezí na nějakou mírně vyšší hodnotu. V případě, že tohle nedokáže/nezjistí, tak ten tok, při nějaké vyšší než limitní hodnotě, po nějakou nastavenou dobu na chvíli zařízne... No, berte mě z rezervou. Jak funguje taková služba jakou je WS netuším. A jak píši, je to jen teorie. Konspirační!
Trochu jiná věc je ale to, co ve svém prvním příspěvku popisuji jako první. Tedy ten případ, kdy se po jistém čase ten datový tok úplně zastaví. Jak jsem dnes dodatečně zjistil, je to na straně Kodi spojené s hláškami, které jsme uvedl v už předchozím příspěvku:
Kód:
2022-07-03 08:59:17.597 T:4339 WARNING <general>: CFileCache::Process - <http://11.dl.wsfiles.cz/7011/X8qGZL89Op/524288000/eJw1jktrwzAQhP_LHnIStqyXJUHoMYcG+1QaiqHI1poaktiVHwWX_vduCr3NDDs73zcE8GBEJpTOnMqEBAYDeM5gAV8YXXIurXMMNrIMVvC60AzmPzeBX9KKDO70JPCCupEUD85EzqOyhTLCKIvG8RaFsDKaUqLWfWf6tnuc0wpsQ8TxfV4ShhtliaIvbOePkDDr9ibvhys2+cV+nt7O1tVTkz9hSmM6vlTPVf1aHcYj1Zb0TzPv4CVhCsJX6ucXgOk9pQ/548eecc175b612a28501cd5c3ad574e139ae7977/a01> source read returned 0! Will retry
2022-07-03 08:59:19.597 T:4339 WARNING <general>: CCurlFile::FillBuffer - Reconnect, (re)try 1 No, zatím si tedy, i s přispěním názoru od @delfin-chikago, vytvářím konspirační terorii, že na straně WS běží algoritmus který, pokud zjistí velký datový tok u souboru, který je videem (to asi problém není, WS moc dobře ví, kdo ty request-y zprostředkoval) a buď zná nebo si dokáže zjistit jeho průměrný bitrate, tak ten tok prostě omezí na nějakou mírně vyšší hodnotu. V případě, že tohle nedokáže/nezjistí, tak ten tok, při nějaké vyšší než limitní hodnotě, po nějakou nastavenou dobu na chvíli zařízne... No, berte mě z rezervou. Jak funguje taková služba jakou je WS netuším. A jak píši, je to jen teorie. Konspirační!