v21 Playback is substantially delayed when starting a video with external audio files
#1
Hi,

The issue occurs both on an Android 12 SmartTV with 1GB RAM (220MB free as reported from Kodi 21) and an Android 12 smartphone with 6GB RAM (3GB free as reported from AIDA64). Thus not insufficient RAM related as could be thought initially.
The issue resolves once the separate audio files get deleted and video is started with the inbuilt audio tracks.

So when the video is started, the spinning wheels animation keeps ongoing virtually endlessly. From the log it is visible I waited for four minutes before canceling the playback. And the last entries before canceling playback show the three threads got autodeleted. I assume those threads were related to the separate audio tracks since there were in total three separate audio files related to the video.
Due to curiosity, I checked that the same issue occurs in VLC and is resolved in the same way. Though VLC got unfrozen on a smartphone in 2 minutes I believe. Yet, if you try to jump to a different time spot, the playback gets frozen again. Made me wonder if Kodi is based on VLC code, partly may be.

I also checked if the bandwidth is sufficient since read somewhere on forum SMB has poor performance over WiFi. My PC connects to the router at 433Mbps, smartphone at 866Mbps, 5GHz band, all in the same room. Pulled the files from a Windows 10 SMB1 server to a smartphone via File Manager. And for a comparison, pulled the same files from a HTTP server set up from a PC folder to the smartphone via Chrome. Tested in the evening and at night. In my case, the SMB delivered quite sufficient performance. Practically, got the half the bandwidth of the slowest link in the chain (in Mbps):
            | SMB1 | HTTP|
Evening | 149   | 189   |
Night    | 160   | 200   |

Could this be fixed in the future or is this considered not an issue? And does anyone have idea what could be the reason for the issue? Also, did I understand correctly from the log that Kodi allocates 20MB of RAM cache for video stream, then 20MB for each of the three separate audio streams? For a total of 80MB of RAM to play a video?

Thanks.

The log: waqubulade.kodi (paste)
Reply
#2
For SMB1 your chunksize is wrong. It only supports 64 KByte, please reduce accordingly.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#3
(2025-01-09, 22:12)tolerance1 Wrote: Pulled the files from a Windows 10 SMB1 server

Yes, it is known that SMB1 has poor performance. SMBv2 is better, SMBv2.1 even better with "Large MTU" support and SMBv3 is the best.

Kodi supports SMBv3.
Reply
#4
(2025-01-09, 22:35)fritsch Wrote: For SMB1 your chunksize is wrong. It only supports 64 KByte, please reduce accordingly.
Hi,

Thanks for the hint. Changed the chunksize to 64KB both in SMB Client and Caching sections - it did not fix the issue - Kodi spinning wheels animation keeps ongoing. The thing is as soon as the separate audio files get removed from the video folder, video is started almost instantly and search is working almost instantly, with the default 128KB chunksizes, and irrespective of the video size in GB. The issue (possibly bug) only occurs when separate audio tracks are accompanying a video. For me it looks like a separate instance of Kodi is started for the main video file and for each of the audio tracks, as if four Kodi instances are run at once, overloading the weak SoC in the SmartTV.

I was not very precise in the starting post, I have conducted the tests again, the issue occurs both on SmartTV and a smartphone. But on SmartTV it has a drastic effect - the video playback is delayed virtually indefinitely. This time I waited for 11 minutes straight looking at the spinning wheels animation before canceling the playback. On a smartphone, the spinning wheels animation lasts for 2-3 minutes, after which the playback does start. Also, the phone perceptibly heats up, to a similar extent when running a resourceful game (e.g. Asphalt Unite). Yet, the Snapdragon 720G SoC can crunch the load the Kodi creates, unlike SmartTV HiSilicon weak SoC.

From subjective observation, what helped cut the playback delay time on smartphone in half, is setting the chunksize to 1MB both in SMB Client and Caching sections, despite SMB1 chunksize limitation. But on TV the 1MB chunksize did not help, possibly due the TV connection bandwidth with the router of 20-30Mbps that does allow to populate Kodi caches quickly enough.

I also realised I have put the thread title incorrectly, since the Kodi does not freeze, since the player reacts to the Back button on the TV remote. Just the video playback fails (or infinitely delayed) on TV. But I can neither edit the original title nor the post body. Could an admin edit the title to a more proper "The playback is indefinitely delayed when starting a video that has separate audio files" ?

Thanks.
Reply
#5
Quote:From subjective observation, what helped cut the playback delay time on smartphone in half, is setting the chunksize to 1MB both in SMB Client and Caching sections, despite SMB1 chunksize limitation. But on TV the 1MB chunksize did not help, possibly due the TV connection bandwidth with the router of 20-30Mbps that does allow to populate Kodi caches quickly enough.

Wondering about the 1 MB, as your SMB should not support it. I mean - if you are really unlucky, the second "connection" to SMB (reading the external audio file) in parallel to the video kills it :-(.
Could you post another debug log with Component logging SMB and (maybe it hits something) CURL being enabled?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#6
Maybe a stupid question, but why stick to SMBv1? Windows 10 supports SMBv2 and v3, so no reason to keep using the old (and insecure) v1:

https://learn.microsoft.com/en-us/window...abs=server
Reply
#7
(2025-01-11, 03:57)fritsch Wrote: Could you post another debug log with Component logging SMB and (maybe it hits something) CURL being enabled?

Here is Debug, SMB and CURL log from the smartphone, since the video does start there: imoxidogub.kodi (paste)

As to why the 1MB chunksize is working - I followed the link from MrMagic, tested for SMB server version as per guide, and got the "True" value for EnableSMB2Protocol, and no value for EnableSMB1Protocol.

It could be helpful if I describe all the steps after installing Kodi firstly on TV:
  1. The video folder was shared passwordless for Everyone in home network.
  2. The SMB3 server was enabled on PC by default ("SMB Direct" option), and SMB1 disabled by default.
  3. Kodi saw the shared folder but could not read it giving the Invalid Argument error.
  4. I disabled the SMB3 server and enabled SMB1 server only (not Client) from Windows Features.
  5. Kodi successfully read the shared folder.
  6. Then decided to try with SMB3 server - disabled SMB1 and enabled SMB3, created a dummy user on PC to log with.
  7. Successfully logged with a dummy user to the shared folder from Kodi.
  8. Then disabled the SMB3 server, enabled SMB1 again and deleted the dummy user.
Reply
#8
(2025-01-11, 10:49)MrMagic Wrote: but why stick to SMBv1

For my use-case SMB1 was sufficient - I wanted passwordless access for everyone in the home network initially. To my surprise, after following your link, it became clear that the server was actually SMB2 - thanks. In regard that SMB1 is insecure, I would think it matters the most for the public networks. For home use that should not be a concern.
Reply
#9
I had expected worse - actually - I think - if I did not overlook something for your file: "farting in public" ;-) three alternative audio files (ac3) format are found and parsed when the mkv is loaded.
Do you see anything suspicious?

And what do you mean with "indefinitely"?

As you see:
Quote:2025-01-11 19:03:30.456 T:5909    debug <general>: CFileCache:Tonguerocess - <smb://192.168.1.200/Home-videos/Mastering.the.art.of.silently.farting.in.public/Mastering.the.art.of.silently.farting.in.public.MVO.FR.ac3> source read hit eof
2025-01-11 19:03:30.505 T:5907    debug <general>: smb:   --> 914432
2025-01-11 19:03:30.505 T:5908    debug <general>: smb: smbc_read(0xb400007e51032100, 1048576)
2025-01-11 19:03:30.505 T:5907    debug <general>: CFileCache:Tonguerocess - <smb://192.168.1.200/Home-videos/Mastering.the.art.of.silently.farting.in.public/Mastering.the.art.of.silently.farting.in.public.MVO.UA.ac3> source read hit eof
2025-01-11 19:03:30.563 T:5908    debug <general>: smb:   --> 1048576
2025-01-11 19:03:30.564 T:5908    debug <general>: smb: smbc_read(0xb400007e51032100, 1048576)
2025-01-11 19:03:30.617 T:5908    debug <general>: smb:   --> 1048576
2025-01-11 19:03:30.618 T:5908    debug <general>: smb: smbc_read(0xb400007e51032100, 916224)
2025-01-11 19:03:30.667 T:5908    debug <general>: smb:   --> 916224
is read in parallel. So with 1MB chunks that works fastest - as you see from the read calls, there is quite some stuff to be read.

From my POV I'd say: Keep it on 1 MB - as you see from your "throughput" in general and keep the amount of cache, you configured + the additional ac3 audio files in mind I'd say stream start gets as fast as it can. Also when your SMB disk is currently shutdown - it will most likely add some more seconds on top - but that is not what you described as issue.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#10
Hi,

Thanks for the answer.
 
Quote:And what do you mean with "indefinitely"?

I meant that it takes undefined amount of time to start the playback, as I waited as much as 11 minutes on TV to see no playback start. And the issue was pronounced on the TV solely. I'll ask to rename the thread title again.

I suddenly realised the yesterday's evening from the log that the delayed playback was the intended behaviour of the player, caused by the slow connection throughput between TV and the SMB server. The player needs to build search maps for the external audio files for fast navigation on the video timeline, and does so by reading every file until the end of file via WiFi, one by one. As I had three external audio files 474MB each, a total of 1422MB had to be read. On a TV-to-server ~20Mbps throughput, it should have taken 9.5 minutes (but waited 11 minutes to no avail); on a smartphone-to-server ~140Mbps throughput, it should have taken 1 min 21 sec (which it did with 1MB chunksizes). As far as I understand, the internal audio tracks search maps are created by a video conversion software - that's why a standalone video file is played almost instantly (provided the video+audio bitrate is less than WiFi throughput), not requiring additional overhead. This also serves as explanation to why VLC behaved in the same manner as Kodi.

Thus, the solution to the issue is to delete all the external audio files (when aren't needed).

I also learned that SMB3 server can be had with passwordless access to a shared folder with Guest Logon enabled via Windows 10 Group Policy, thus disabled SMB1 altogether. Checked in Kodi - access to the folder works. Leaving the link for the how-to: https://learn.microsoft.com/en-us/window...oup-policy

Thanks everyone for the input 🤝.
Reply
#11
If the AC3 file would really be read _entirely_ this was a sever implementation bug ... currently no time to check that, though.

Funny :-). As a workaround: use mkmerge and just add it as additional audio stream.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#12
Hi,

I cleared Kodi cache on TV to start anew. This time the mentioned video with three external audio files did start to play after 9 minutes 18 seconds, as anticipated for a ~20Mbps throughput, with 1MB chunksizes. Measured the time with a smartphone stopwatch app. Also Windows 10 Task Manager WiFi “Send” value showed a continuous 20±3 Mbps throughput during the wait time – i.e. everything coincided nicely.
 
Quote:If the AC3 file would really be read _entirely_ this was a sever implementation bug

Judging from the time it took to start a playback and considering the total size of eternal audio files and Windows 10 Task Manager WiFi “Send” activity and the smartphone debug log, the issue would qualify as a bug. But you meant Windows 10 SMB Server bug or a Kodi one? In either case, if someone decides to fix the issue in the future, you already have my two tests from TV and smartphone for reference. But as long as the issue has not been submitted as a bug, it won’t be going to be fixed.

Thanks.
Reply

Logout Mark Read Team Forum Stats Members Help
Playback is substantially delayed when starting a video with external audio files0