Closed tycoo closed 7 years ago
Thanks for that. Very useful. I'm having problems finding bad streams for the devs to test with. Have you come across any they can access in Germany or the Netherlands?
It must be possible to fix it because Jarvis worked perfectly. The whole VideoPlayer component is new in Krypton. I just can't understand why no-one spotted this during development. I see a lot of posts about blaming cheap chinese firmware but I get the problem on a Nvidia Shield and Windows and so do many others.
Yes, there are many streams for german tv: https://www.kodinerds.net/index.php/Thread/49562-So-richtig-legale-m3u/?postID=309082#post309082
My flatemate has he same delay prob on his linux machine + krypton and the simple pvr plugin. Yep, it's strange that nobody discovered the bug during development already. :/ And i don't think that this is a hardware issue. :/
I thought after some testing last night on rpi2 with iplayer WWW BBC DASH streams appearing to switch quicker (i.e. switch between BBC1 to BBC 2 channels) in Leia nightly compared with Limelight and Amakai streams, if true this also may tie up with issue being in how kodi interacts with ffmpeg on different host OS's?
Thanks you 2. @tycoo Are you in Germany? If you are can you see if any of those German channels seem to take a long time compared to Jarvis. 5 seconds + I suppose. They take a long time for me compared to Jarvis but I'm not local. ;)
yep, its the same. on jarvis the channels start immediately, below a second. my flatmate tested krypton and experienced a long delay, maybe 5 seconds or more.
Thanks. All we need to do now is convince FernetMenta that we're not hallucinating. ;)
Big thx for your efforts @primaeval and for figuring out the bugs reason. I've read the ticket discussion. Looks like all depends on the ffpmeg developers now, if they are going to take on the matter. Btw. did you build the kodi.exe for Win7 32bit?
Thanks. Yes 32bit. I hate this buck-passing. Jarvis was great. Progress doesn't always go forwards. I'm having a look at ffmpeg myself. I can't imagine this is going to get fixed by either team for a long long time.
Lets wait. As far as i can see, in the past the ffmpeg team took care and fixed issues relatively promptly.
That would be good. I'm still not convinced that it is really ffmpeg that should do the stream choosing. I can't believe someone put all the code in to test the sub-streams for no reason, but I have been known to code while drunk too. ;)
That's what i have found about the delay: http://stackoverflow.com/questions/15005436/errors-when-decode-h-264-frames-using-ffmpeg
Sounds reasonable, but if ffmpeg is the cause it might be hard to fix.
I am thinking about to test the Krypton DSPlayer fork, which is capable of using other decoders and see if this helps. https://github.com/aracnoz/xbmc
regards