2016-01-08, 00:23
Occasionally I get video stuttering/buffering issues on my 2 systems when streaming using Kodi.
So I did some experiments to try and understand and this is a report on the results and conclusion for my case.
(1) The 2 systems I have are
a) HW: Mac Pro Desktop early 2009 (4,1)with 2 Quad-core CPU's clocked at 2.66Mhz.
Each core can run 2 threads so maxed out at 16 simultaneous threads. 6GB RAM + 2TB HD
SW: OS X 10.10.5. Kodi Isengaard 15.2 as the only added application.
b) HW:RPi2 BCM2709 4 x ARMv7 Processor rev 5 (v7l) 900Mhz, 16GB class 10 microSD
SW: Raspbian Jessie and Kodi Isengaard 15.1 (15,2 not available in repository)
(2) On my LAN both systems have a wired connection to the SmartRG 505n router.
The WAN port is cat5e copper to the FTTN in our building telephone room and thence
connected to my ISP with a 15mbps down and 10mbps up service.
(3) I did a series of speed tests using the app at Broadband .com (as well as a couple of others.).
Both systems are getting around 14.9mbps down and 9.8mbps up.
(4) I selected a video and used 2 different streams for the tests; one was HD/HQ the other was MQ/SD
(5) I used the same source on each system for each of the tests.
(6) I streamed the video with both the default buffers and with the advanced settings set this way:
<advancedsettings>
<network>
<buffermode> 1 </buffermode>
<readbufferfactor> 1.5 </readbufferfactor>
<cachemembuffersize> 26214400 </cachemembuffersize> # 25MB = 25x1024x1024
</network>
</advancedsettings>
So the streams were like this:
Mac System RPi2 System
HD Default Buffer HD stream Default Buffer
HD 25MB etc Buffer HD 25MB etc Buffer
SD Default Buffer SD stream Default Buffer
SD 25MB etc Buffer SD 25MB etc Buffer
As soon as I started the stream I pressed the 'o' key to display the codecinfo.
Using my Android phone I took videos and snapshots of the codec info.
Conclusion: The dominant factor in my case was the quality of the stream.
SD worked flawlessly with default settings (i.e. DISABLED)
SD worked flawlessly with the 25MB buffer etc.
So the buffer settings made no difference for SD. Default was good
What happened is once the stream started the 'forward' value would increase
up to some point where the %age became 100% and would then hover around that.
I interpreted that to mean that the buffering was sufficient to keep ahead of the display.
On both systems HD would fill the buffers until the appearance of the information message:
"Cache Full: Cache filled before reaching required amount for continuous playback"
Then the stream would start playing and exhaust the buffer.
This was the case for both buffer settings on both systems.
However what was problematic was that buffering never resumed properly to the point where the
stream played correctly.
Also the CPU on the Mac ramped up to as high as 111% (multiple cores?)
On the RPi2 the processors also hit 100%.(not all at once; usually processor 0 but also sometimes the others)
Comments?
respect
Peter
So I did some experiments to try and understand and this is a report on the results and conclusion for my case.
(1) The 2 systems I have are
a) HW: Mac Pro Desktop early 2009 (4,1)with 2 Quad-core CPU's clocked at 2.66Mhz.
Each core can run 2 threads so maxed out at 16 simultaneous threads. 6GB RAM + 2TB HD
SW: OS X 10.10.5. Kodi Isengaard 15.2 as the only added application.
b) HW:RPi2 BCM2709 4 x ARMv7 Processor rev 5 (v7l) 900Mhz, 16GB class 10 microSD
SW: Raspbian Jessie and Kodi Isengaard 15.1 (15,2 not available in repository)
(2) On my LAN both systems have a wired connection to the SmartRG 505n router.
The WAN port is cat5e copper to the FTTN in our building telephone room and thence
connected to my ISP with a 15mbps down and 10mbps up service.
(3) I did a series of speed tests using the app at Broadband .com (as well as a couple of others.).
Both systems are getting around 14.9mbps down and 9.8mbps up.
(4) I selected a video and used 2 different streams for the tests; one was HD/HQ the other was MQ/SD
(5) I used the same source on each system for each of the tests.
(6) I streamed the video with both the default buffers and with the advanced settings set this way:
<advancedsettings>
<network>
<buffermode> 1 </buffermode>
<readbufferfactor> 1.5 </readbufferfactor>
<cachemembuffersize> 26214400 </cachemembuffersize> # 25MB = 25x1024x1024
</network>
</advancedsettings>
So the streams were like this:
Mac System RPi2 System
HD Default Buffer HD stream Default Buffer
HD 25MB etc Buffer HD 25MB etc Buffer
SD Default Buffer SD stream Default Buffer
SD 25MB etc Buffer SD 25MB etc Buffer
As soon as I started the stream I pressed the 'o' key to display the codecinfo.
Using my Android phone I took videos and snapshots of the codec info.
Conclusion: The dominant factor in my case was the quality of the stream.
SD worked flawlessly with default settings (i.e. DISABLED)
SD worked flawlessly with the 25MB buffer etc.
So the buffer settings made no difference for SD. Default was good
What happened is once the stream started the 'forward' value would increase
up to some point where the %age became 100% and would then hover around that.
I interpreted that to mean that the buffering was sufficient to keep ahead of the display.
On both systems HD would fill the buffers until the appearance of the information message:
"Cache Full: Cache filled before reaching required amount for continuous playback"
Then the stream would start playing and exhaust the buffer.
This was the case for both buffer settings on both systems.
However what was problematic was that buffering never resumed properly to the point where the
stream played correctly.
Also the CPU on the Mac ramped up to as high as 111% (multiple cores?)
On the RPi2 the processors also hit 100%.(not all at once; usually processor 0 but also sometimes the others)
Comments?
respect
Peter
