2017-04-06, 10:34
Team-Kodi Members,
Any other idea to minimize channel switching time Kodi 17?
Please advice..
Any other idea to minimize channel switching time Kodi 17?
Please advice..
2017-04-17, 23:05
Some of my channels take over 30 seconds to start and in VLC player about 2 seconds, and sometimes channels failed to even start. This is totally frustrating, please help.
This is my log:
advancedsettings.xml:
I am testing this on Windows with Kodi 17.1.
This is my log:
Code:
22:49:08.953 T:5140 NOTICE: VideoPlayer: Opening: pvr://channels/tv/All channels/pvr.iptvsimple_442953456.pvr
22:49:08.953 T:5140 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
22:49:08.955 T:9432 NOTICE: Creating InputStream
22:49:44.772 T:9432 NOTICE: Creating Demuxer
22:49:44.783 T:9432 NOTICE: Opening stream: 0 source: 256
22:49:44.783 T:9432 NOTICE: Creating video codec with codec id: 2
22:49:44.783 T:9432 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: MPEG-2 video
22:49:44.783 T:9432 NOTICE: Creating video thread
22:49:44.784 T:9432 NOTICE: Opening stream: 1 source: 256
22:49:44.784 T:9432 NOTICE: Finding audio codec for: 86016
22:49:44.784 T:9432 NOTICE: Creating audio thread
22:49:44.784 T:9432 NOTICE: Opening stream: 3 source: 256
22:49:44.784 T:9432 NOTICE: waiting for teletext data thread to exit
22:49:44.785 T:9432 NOTICE: Creating teletext data thread
22:49:44.789 T:9432 NOTICE: Opening stream: 0 source: 256
22:49:44.789 T:9432 NOTICE: Creating video codec with codec id: 2
22:49:44.789 T:9432 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: MPEG-2 video
22:49:44.789 T:9432 NOTICE: Opening stream: 1 source: 256
22:49:44.789 T:9432 NOTICE: Opening stream: 3 source: 256
22:49:44.807 T:12124 NOTICE: running thread: video_thread
22:49:44.807 T:12124 NOTICE: CDVDVideoCodecFFmpeg::GetFormat - Creating DXVA(544x576)
22:49:44.808 T:11956 NOTICE: running thread: CVideoPlayerAudio::Process()
22:49:44.808 T:11956 NOTICE: Creating audio stream (codec id: 86016, channels: 2, sample rate: 48000, no pass-through)
22:49:44.813 T:5624 NOTICE: running thread: CDVDTeletextData
22:49:44.843 T:5140 NOTICE: D3D: rendering method forced to DXVA processor
22:49:44.843 T:5140 NOTICE: DXVA::CProcessorHD::InitProcessor: Supported deinterlace methods: Blend:yes, Bob:yes, Adaptive:yes, MoComp:yes.
22:49:44.875 T:5140 WARNING: CWinRenderer::UpdateVideoFilter - chosen scaling method 1 is not supported by renderer
22:49:45.381 T:12124 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
22:49:46.080 T:12124 WARNING: Previous line repeats 1 times.
22:49:46.081 T:12124 NOTICE: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 40000
22:49:47.332 T:5140 ERROR: Control 602 in window 12901 has been asked to focus, but it can't
22:49:48.141 T:5140 NOTICE: CVideoPlayer::CloseFile()
22:49:48.141 T:5140 NOTICE: VideoPlayer: waiting for threads to exit
22:49:48.147 T:9432 NOTICE: CVideoPlayer::OnExit()
22:49:48.147 T:9432 NOTICE: Closing stream player 1
22:49:48.147 T:9432 NOTICE: Waiting for audio thread to exit
22:49:48.154 T:11956 NOTICE: thread end: CVideoPlayerAudio::OnExit()
22:49:48.154 T:9432 NOTICE: Closing audio device
22:49:48.168 T:9432 NOTICE: Deleting audio codec
22:49:48.168 T:9432 NOTICE: Closing stream player 2
22:49:48.168 T:9432 NOTICE: waiting for video thread to exit
22:49:48.182 T:12124 NOTICE: thread end: video_thread
22:49:48.182 T:9432 NOTICE: deleting video codec
22:49:48.184 T:9432 NOTICE: DXVA::CDecoder::Close - closing decoder
22:49:48.184 T:9432 NOTICE: DXVA::Close - closing decoder context
22:49:48.184 T:9432 NOTICE: Closing stream player 4
22:49:48.184 T:9432 NOTICE: waiting for teletext data thread to exit
22:49:48.184 T:5624 ERROR: Got MSGQ_ABORT or MSGO_IS_ERROR return true (-1)
22:49:48.184 T:5624 NOTICE: thread end: data_thread
22:49:48.335 T:5140 NOTICE: VideoPlayer: finished waiting
22:49:48.387 T:5140 NOTICE: CVideoPlayer::CloseFile()
22:49:48.387 T:5140 NOTICE: VideoPlayer: waiting for threads to exit
22:49:48.387 T:5140 NOTICE: VideoPlayer: finished waiting
22:49:48.387 T:5140 NOTICE: CVideoPlayer::CloseFile()
22:49:48.387 T:5140 NOTICE: VideoPlayer: waiting for threads to exit
22:49:48.387 T:5140 NOTICE: VideoPlayer: finished waitingadvancedsettings.xml:
Code:
<!-- Created using Easy Advanced Settings addon -->
<advancedsettings>
<network>
<buffermode>2</buffermode>
<cachemembuffersize>377286400</cachemembuffersize>
<readbufferfactor>30</readbufferfactor>
</network>
<pvr>
<autoscaniconsuserset>false</autoscaniconsuserset>
<cacheindvdplayer>true</cacheindvdplayer>
<channeliconsautoscan>true</channeliconsautoscan>
<infotoggleinterval>3000</infotoggleinterval>
<minvideocachelevel>60</minvideocachelevel>
<numericchannelswitchtimeout>1000</numericchannelswitchtimeout>
</pvr>
</advancedsettings>I am testing this on Windows with Kodi 17.1.
2017-05-01, 15:00
Hello All,
I can confirm that that on 17.1 independently of the OS platform (I tested Windows 7 and OpenELEC) the zapping time / channel switching is now awfully slow in comparison with the 16.1 - there is too no difference if one uses TV streams or Radio streams both startup slow. And yes, I did a clean install on Windows with a profile data delete to verify that it is not caused by some leftovers during an upgrade.
To test I did do:
- change access with http proxy to no proxy
- played with the advancedsettings.xml and buffer setttings
I did not experience any difference.
Since the streams are starting correctly (after a long long time) and are running fine, so this is only a problem on switching on the stream.
I assume this has to do something either with 17.1 or the used ffmpeg library.
Any body here that can guide us through the process of fixing this?
Kind Regards
I can confirm that that on 17.1 independently of the OS platform (I tested Windows 7 and OpenELEC) the zapping time / channel switching is now awfully slow in comparison with the 16.1 - there is too no difference if one uses TV streams or Radio streams both startup slow. And yes, I did a clean install on Windows with a profile data delete to verify that it is not caused by some leftovers during an upgrade.
To test I did do:
- change access with http proxy to no proxy
- played with the advancedsettings.xml and buffer setttings
I did not experience any difference.
Since the streams are starting correctly (after a long long time) and are running fine, so this is only a problem on switching on the stream.
I assume this has to do something either with 17.1 or the used ffmpeg library.
Any body here that can guide us through the process of fixing this?
Kind Regards
2017-05-17, 09:02
Well this is going nowhere - so what other options do we have?
Downgrade to 16.1 which worked?
Is the other "PVR" options usable for this usage scenario? (steaming live channels using a playlist - ie not from a tv card)
Downgrade to 16.1 which worked?
Is the other "PVR" options usable for this usage scenario? (steaming live channels using a playlist - ie not from a tv card)
2018-11-12, 20:26
Hello,
after a long time... I - SOLVED - my slow channel switching problem in IP TV Simple Client.
Solution: it is a problem with streams that reference master.m3u8 streams. I switched that in my m3u file to fixed resolution streams, like this one: http://daserstehdde-lh.akamaihd.net/i/da...&rebase=on after that channel switching is as fast as expected. Looks like the parsing of all the different streams in a m3u8 results in a significant delay.
Kind Regards
after a long time... I - SOLVED - my slow channel switching problem in IP TV Simple Client.
Solution: it is a problem with streams that reference master.m3u8 streams. I switched that in my m3u file to fixed resolution streams, like this one: http://daserstehdde-lh.akamaihd.net/i/da...&rebase=on after that channel switching is as fast as expected. Looks like the parsing of all the different streams in a m3u8 results in a significant delay.
Kind Regards
2019-07-30, 10:24
(2018-11-12, 20:26)flinxy Wrote: Hello,hi, can you please explain how did you fix it? i can not do this.
after a long time... I - SOLVED - my slow channel switching problem in IP TV Simple Client.
Solution: it is a problem with streams that reference master.m3u8 streams. I switched that in my m3u file to fixed resolution streams, like this one: http://daserstehdde-lh.akamaihd.net/i/da...&rebase=on after that channel switching is as fast as expected. Looks like the parsing of all the different streams in a m3u8 results in a significant delay.
Kind Regards
best
