Buffer not filled when using SMB on kodi 17.4
#1
Since I installed LibreELEC 8.1 / Kodi 17.4 I have had problem playing files from my Samba share. At first I thought it was something connected to the SMB versions. But now I have done some more investigation and I think it is related to the buffer not being filled correctly. The files play fine over https, but when playing the same file over samba I have a lot of buffering issues. On the older Kodi versions I solved this by increasing the buffer size by placing the following in the advanced settings:

Code:
       <cache>
               <memorysize>52428800</memorysize>
               <buffermode>1</buffermode>
               <readfactor>10</readfactor>
       </cache>
       <samba>
               <statfiles>true</statfiles>
       </samba>
</advancedsettings>

When I open up the information overlay "playerdebug" I see the cache stuck at "0B 100%" with 100% decreasing when playing over SMB. If I play the file over http the cache fills properly up to 25.00 MB 100%.

Does anyone recognize this issue?
Reply
#2
Start providing a debug log (wiki) file, so we get some more general info.

Samba should never be a problem, unless you are using a crappy wifi connection.
Whenever possible, use a cabled network.
Reply
#3
(2017-10-17, 23:09)Klojum Wrote: Start providing a debug log (wiki) file, so we get some more general info.

Samba should never be a problem, unless you are using a crappy wifi connection.
Whenever possible, use a cabled network.

Unfortunately I am using a crappy Wi-Fi connection Sad But it worked before Smile


When trying to reproduce the issue now I placed the same file in the root (shorter navigation), and that one worked successfully. Might be something related to the library feature, since the new files weren't added there. (same goes for my https to the same files that I tried)

The files played at


Code:
23:37:46.900 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/test.mkv

and

Code:
23:38:09.686 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/filmer/folder/test2.mkv



works correctly. But the third file played at

Code:
23:38:21.145 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/filmer/folder/movie.mkv


has the issue.



I only played this file a few seconds, not long enough for the buffer to be completely empty, but long enough to see a completely different behavior in the overlay compared to the first 2 files. The full kodi.log is here: https://dflund.se/~glyph/stuff/kodi/smb%20buffer2.log

Anothoner thing I noticed now is that the first 2 files starts to play in about 1 second, the third file takes about 5-10 seconds.

When I did the first test (unfortunately without the debug logging turned on) I also had this if it can be of any help


Code:
23:26:26.197 T:1428935584 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer


full log file https://dflund.se/~glyph/stuff/kodi/smb%20buffer1.log


EDIT: To clarify: All these 3 are the same file on the server, the first 2 test.mkv entries are symlinks pointing to movie.mkv

EDIT2: Might also be something related to the subtitle, at least the long initial start time, there is a long delay between the 2 rows

23:25:35.955 T:1717564320  NOTICE: Creating InputStream
23:25:44.242 T:1717564320  NOTICE: Creating Demuxer


in the buffer1.log file, and looking in the buffer2.log files it appears being work related to the subtitles. But then I would suspect the same to happen over http....
Reply
#4
You could try forcing SMB1 in Kodi Settings > Services > SMB Client > Maximum protocol version, as SMB1 is what you would have been using prior to LibreELEC 8.1.

By default in LibreELEC 8.1 you may now be using SMB2 or SMB3 (the specific protocol will depend on what your Samba server supports), and these newer and more secure protocols should in theory perform better than SMB1 - but maybe not with your server, or with a crap/high latency WiFi.

Naturally if SMB1 is disabled on your server (as it should be, for security reasons) then you'll need to decide if you want to accept the risk of re-enabling it, or alternatively invest in a pair of 1200-AV Homeplugs and replace your WiFi.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#5
I did some more test today. It appears to be linked to the external subtitles. The external subtitles isn't loaded over HTTPS, there I can only see the ones embedded in the MKV-file.

I tried renaming the file so it doesn't find the "Subs" folder, then it works over SMB. It is only when I have external subtitles that I encounter the delay when starting to play the file and the no buffer issue.

The subtitle files is of the IDX format, can it be related to how it is loaded into the video player?



(2017-10-18, 18:14)Milhouse Wrote: You could try forcing SMB1 in Kodi Settings > Services > SMB Client > Maximum protocol version, as SMB1 is what you would have been using prior to LibreELEC 8.1.

By default in LibreELEC 8.1 you may now be using SMB2 or SMB3 (the specific protocol will depend on what your Samba server supports), and these newer and more secure protocols should in theory perform better than SMB1 - but maybe not with your server, or with a crap/high latency WiFi.

Naturally if SMB1 is disabled on your server (as it should be, for security reasons) then you'll need to decide if you want to accept the risk of re-enabling it, or alternatively invest in a pair of 1200-AV Homeplugs and replace your WiFi.

I have tried both SMB1, SMB2, SMB3 and "none", no difference.

I am aware of the update to SMB3 in LibreELEC 8.1 at first it didn't work at all, so I had to do a slight modification to my SMB server (FreeBSD), updating the min protocol and max protocol version in it's configuration file.
Reply
#6
I had hoped that the following fix in

Quote:Fix playback of DVD file over network on Linux

in the release notes for 17.5 would solve this. But it didn't :-(

I still see the same problem as above, caused by the external subtitles.
Reply
#7
I have the same problem as Glyphs is describing.
Playing files with external subs doesn't always work as intended. Some files with external subs works fine if I play them,
but playing a 1080p film with external subs usually doesn't work. What happens is that it buffers, starts playing and then it runs out of buffer and has to pause the film
to buffer again. This happens lots of times throughout the movie and not just once or twice. Pressing ctrl+shift+o I can see that when the film starts playing the buffer is at 100% but then reaches zero. 
I am hosting my files on a local server with 1gbit connection and my laptop is using wifi (speedtest estimate my speeds to be 74mbit down, 28mbit up using the wifi on the laptop).
I've tried to access the files by mounting the files on my laptop using sshfs and then adding that folder to kodi and I've also tried to add the remote folder using ssh/sshfs in kodi.
Both of the options gives me the same problem.

Playing a remote film in 1080p DTS 5.1 without external subs works fine, but the external subs gives me the problems.
Reply
#8
I suspect also a buffering issue on Kodi 17.5 and earlier for the Raspberrry Pi 3. Not only for SMB shares, it seems to be a more general issue. However, if you observe the package updates in Raspbian/Debian, almost always the samba packages are updated. There seem to be many issues with SAMBA. For example, some time ago, the Samba shares of a Linux SAMBA server disappeared from the Windows network in very spooky ways. Recently, this problem seems to have improved. You should file your observation as BUG- . I have also filed a BUG- thread related to your issue...
Reply
#9
(2017-10-17, 23:49)Glyphs Wrote:
(2017-10-17, 23:09)Klojum Wrote: Start providing a debug log (wiki) file, so we get some more general info.

Samba should never be a problem, unless you are using a crappy wifi connection.
Whenever possible, use a cabled network.

Unfortunately I am using a crappy Wi-Fi connection Sad But it worked before Smile


When trying to reproduce the issue now I placed the same file in the root (shorter navigation), and that one worked successfully. Might be something related to the library feature, since the new files weren't added there. (same goes for my https to the same files that I tried)

The files played at
 
Code:
23:37:46.900 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/test.mkv

and
Code:
23:38:09.686 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/filmer/folder/test2.mkv



works correctly. But the third file played at
Code:
23:38:21.145 T:1944963536  NOTICE: VideoPlayer: Opening: smb://AURORA/public/filmer/folder/movie.mkv


has the issue.



I only played this file a few seconds, not long enough for the buffer to be completely empty, but long enough to see a completely different behavior in the overlay compared to the first 2 files. The full kodi.log is here: https://dflund.se/~glyph/stuff/kodi/smb%20buffer2.log

Anothoner thing I noticed now is that the first 2 files starts to play in about 1 second, the third file takes about 5-10 seconds.

When I did the first test (unfortunately without the debug logging turned on) I also had this if it can be of any help
 
Code:
23:26:26.197 T:1428935584 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer


full log file https://dflund.se/~glyph/stuff/kodi/smb%20buffer1.log


EDIT: To clarify: All these 3 are the same file on the server, the first 2 test.mkv entries are symlinks pointing to movie.mkv

EDIT2: Might also be something related to the subtitle, at least the long initial start time, there is a long delay between the 2 rows

23:25:35.955 T:1717564320  NOTICE: Creating InputStream
23:25:44.242 T:1717564320  NOTICE: Creating Demuxer


in the buffer1.log file, and looking in the buffer2.log files it appears being work related to the subtitles. But then I would suspect the same to happen over http.... 
 some time ago, with the RaspBerry Pi 2 there used to be a lot of performance issues even with the recommended USB WiFi dongles. Since I own RaspBerry Pi 3 WiFi provides at least the predicted transfer speeds of 20 MBit/s (which you get from the theoretical speeds of up to 70 MBit/s for Wifi 802.11n in short distances like a two-room flat). In case your wall are too thick for achieving theoretical maximum WiFi speeds try with powerline high-speed interfaces from room to room and inside the single rooms use WiFi or Ethernet. The SAMBA Linux server had also issues, but your buffering problem is more general.
Reply
#10
I'm using Kodi 17.6 now, so the issue is not specific to 17.5 and earlier.

I know that wifi isn't optimal but the distance between the router and my Raspberry Pi 3 is pretty short, only a few meters and no thick walls.

To me this appears to be a bug related to the external subtitles. Which might affect the performance more since I am using SMB and WiFi, but that isn't the root cause.
Reply

Logout Mark Read Team Forum Stats Members Help
Buffer not filled when using SMB on kodi 17.40