problems with TS-8 / KODI 15 4k replay over long latency links

[mister_C]

Hi;
I am unable to get good replay of 30Mbps average / peak 63Mbps 4k video streams over a test network that has been verified to deliver ~90Mbps, with no packet loss and RTT of approx 20msecs.
Server and player have been checked with direct ethernet connection (limited to 100Mbps by the DROIDBox network interface, but obviously sub-msec RTT).

QUESTIONS:

1. why does the KODI Player report 'cache memory full before amount required for continuous play' irrespective of cachebuffermem setting ?

2. how is the required amount of buffer memory calculated by the KODI client ?

3. Does the client take into account variations in RTT to the server ? eg increase in RTT from the initial value observed when the link is idle to the steady state value under load ?

4. why does the 'readbufferfactor' (in advancesettings.xml) not affect the speed at which data is initially transferred from server to client ? (KODI 15.1 on W7 server; 15.2 rc1 on DROIDbox client and 15.1 on a separate W7 client).

5. how does the server determine the average rate at which a video stream should be sent ?

6. why does the server send an HD stream that is an average 9.3Mbps initially (for approx 5 secs) at 31.7Mbps, irrespective of the readbufferfactor setting ?

7. why does the server send 4k streams at a constant rate (ie no initial fast burst to fill the cache) ?

8. why does KODI 15 running on DROIDbox (Android 4.4.2; kernel 3.10.33) send SACKs at regular intervals triggering server re-transmits AND causing the server send rate to reduce ? (probably a by-product of the TCP congestion control algorithm) ?
this phenomena is observed when a Windows KODI player is receiving video from the same server over the same transmission path, at a higher data rate, at the same time; but no SACKs / re-transmits are observed in the traffic stream to the W7 player.

9. playing HD files on the same system (average bit rate ~12.5Mbps, buffer fill initially at ~30Mbps with readbufferfactor set to 3) shows the 'expected' behaviour; once the play starts, buffer fill continues at approx same speed as buffer drain...(so the server and player seem to be configured correctly

BUT, when cachemembuffer has 'plenty' of data in it, why is occasional blocking seen on HD images ?

I have conducted some quick trials with Openelec /KODI 14.1; behaviour appears to be similar..

same questions sent in to the support email; but the web chat person advised me to post in the forums (will post in KODI as well, but I think a lot of the above are dependent on exactly what has been implemented in the TS-8).

thanks in advance for any info...

 

[ChrisM]

Thanks for your detailed post. I think this level of tracing and familiarity may require the specialists over at the Kodi forums ( http://forum.kodi.tv/showthread.php?tid=234749 ). I've passed on the results to the whole team here at DroidBOX so they're aware, one thing that might be worth investigating is whether you get the same results on your device using the different builds linked to at https://droidbox.co.uk/blog/kodi-xbmc-download/ . Hopefully the next build created will either be using a different (updated) source, or a fix/workaround will be in place.

If you don't have the time or desire to look at those APKs (in terms of manually downloading and installing) it might also be worth checking whether another SPMC based build (other than the DBMC one at the blog link) results in the same results. A pure SPMC build is available from the Play Store - https://play.google.com/store/apps/details?id=com.semperpax.spmc&hl=en_GB

 

[mister_C]

thanks for the update Silently.

Meanwhile, I have some more test results and a much more precise 'problem definition' with respect to the replay of high rate video over 'long latency' links.

IFF you over-ride the DefaultSend/ReceiveWindow parameters on both W7 server and W7 player, then the system behaves as I expect; with an appropriate readbufferfactor setting, the server sends an initial block of data at full line rate to the player, until the player cachemembuffer is half full; then server data send rate follows client player consume rate until there is no more data to send.

BUT, when I replace the W7 player with DROIDBox (with either version of KODI mentioned originally), the maximum rate at which the server sends is the same as before changing the server DefaultSendWindow paramter; meaning (IMHO) the network stack config parameters in the DROIDBox are not sufficient to enable 70Mbps content replay over long latency links (if I remove the long latency link, replay is fine).

SO... the question is... how to change DefaultSend/ReceiveWindow parameters for DROIDBox KODI player ??

thanks...