Hi there,
Long time lurker but finally signed up as I need advice.
I’m currently running OSMC on a pi3, with an 8.2TB LUN presented via ISCSI.
The network goes: pi3 → gigabit switch → router (gigabit ports) → NAS
When launching media from the NAS through Kodi I get fluctuating speeds between 300kbps to 8mbps, usually hovering around 2-4. This obviously causes issues when trying to read larger .mkv files.
To make things interesting I thought I’d try to run some network speed tests so I created an NFS share in OSMC, presenting a folder from the ISCSI LUN. I then loaded up nload on the pi via ssh to monitor inbound write speeds. From my wired connected laptop I maxed the 100mbit connection on the pi3 when writing to the NFS share, and I did the same when opening media from a different location.
To make matters even more interesting: when activating the WiFi connection on the pi, Kodi will use about 20mbits of bandwith constantly.
I’ve had a play around with the advancesettings.xml file to see if any buffering settings may impact this but so far I’ve only resulted in achieving really long wait times before any media plays.
I’d be inclined to say that it’s either down to the USB or microSD card, but both have been replaced to ensure they’re not the issue at hand.
OSMC forum members, please advice and help 
So iSCSI -> NFS?
Is NFS mounted via /etc/fstab?
What is Kodi actually accessing? An NFS share, or the iSCSI mounted directory directly? Remember Kodi has worse buffering (read-ahead) when using userland libs than the kernel mount counterparts.
Hi,
Thanks for getting back to me.
Yes for the testing purposes I added the iSCSI LUN to NFS export.
To add the media, I have added it both through “Browse for new share” and selected the visible mounted drive, as well through the root file system and going to /mnt/iscsi where it’s mounted through fstab. Both yield the same poor read speed result.
SCSI -> NFS is never going to be good for performance.
Why not use open-iscsi? apt-get install open-iscsi
I think we may have cross-communicated, apologies for not making myself clear.
The pi3 has open-iscsi installed, the iSCSI LUN is presented only to the pi3
I only installed and configured NFS because I wanted to do testing from another host.
I’m afraid I don’t really understand your question.
Ok, I’ll try again.
Kodi stutters and buffers consistently when playing media from iSCSI LUN (iSCSI LUN attached to pi3 with open-iscsi). Using ssh & nload I can see that the pi3 reads at between 300kbps-2mbits from iSCSI LUN when playing media. When I read/write files via OS, I get consistent 100mbits.
How can I make Kodi use the full bandwidth?
Probably easiest to change buffering in advancedsettings. But if you can, adjust the readahead size of iscsi. There may be a sysfs option for this. Don’t know a lot about iSCSI.
As originally mentioned, I have played around with buffer settings in advancedoptions without success.
Also: As mentioned, full bandwidth between pi3 & iSCSI LUN is used when transferring files to iSCSI LUN through OS. It’s just Kodi that doesn’t make use of the available bandwidth.
Not sure if this will help, but these are the last lines in kodi.log from when I’ve been playing a piece of media that has started to buffer
14:12:10 492408.531250 T:1471149040 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
14:12:11 492409.031250 T:1433400304 NOTICE: CDVDPlayerAudio::OutputPacket skipping a packets of duration 32
14:12:11 492409.156250 T:1471149040 NOTICE: Previous line repeats 10 times.
14:12:11 492409.156250 T:1471149040 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
14:12:12 492410.218750 T:1433400304 NOTICE: CDVDPlayerAudio::OutputPacket skipping a packets of duration 32
14:12:14 492412.187500 T:1471149040 NOTICE: Previous line repeats 28 times.
14:12:14 492412.187500 T:1471149040 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
Full logs (with debugging) is always more helpful.
Does buffermode=1 help?
What did you change? It will help to know what didn’t work
Here is an extract of my advancedsettings.xml
<advancedsettings>
<network>
<buffermode>1</buffermode> <!-- Comment: Default is 1 -->
<cachemembuffersize>209715200</cachemembuffersize> <!-- Comment: Default is 20971520 bytes or 20 MB -->
<readbufferfactor>20</readbufferfactor> <!-- Comment: Default is 1.0 -->
<disableipv6>true</disableipv6>
</network>
</advancedsettings>
#<advancedsettings>
#<network>
#<buffermode> 1 </buffermode>
#<readbufferfactor> 1.5 </readbufferfactor>
#<cachemembuffersize> 104857600 </cachemembuffersize>
#<cachemembuffersize> 209715200 </cachemembuffersize>
#</network>
#</advancedsettings>
I have tried to play around with the readbufferfactor to change network priority for the pi3, as well as the buffermode and cachemembuffersize. Changing buffermode has no real effect, changing cachemembuffersize only changes the time it takes for the media to start & how long I can play it for before it starts to buffer again.
Please let me know how to enable verbose logging, which logs to upload and where to find them and I’ll get them uploaded
You’ve probably got good reason, but why not just use SMB or NFS?
Makes sense to use something that’s already working, and as you’ve said it’s only Kodi that’s experiencing issues so don’t think it’s an OSMC issue.
Hi,
Thanks for your reply.
Yes, my NAS only supports iSCSI so that’s why I decided to install open-iscsi on the pi3, which also hosts Kodi.
I have used smb and nfs in the past but to be honest neither match the potential speed available when using iSCSI.
I understand you want maximum performance, the rpi3 is more than capable of maximising the 100Mbps port on it via SMB or NFS.
I’ve got some pretty large rips, and I’ve never found one that exceeds 50Mbps.
From what I understand you’ve already confirmed osmc can transfer at full speed via iscsi, it’s just Kodi that can’t. Personally I’d try an alternate distro first and if you can replicate the problem go to the Kodi forums.
Please understand I’m only a user, and this OS my opinion. The osmc team may help you further but I think they’ve got other things other than this particularly unique config that you’ve already confirmed toy can bypass using NFS.
Hi Martin,
Yep completely understand. I’ve been scratching my head over this for a while now and whilst I love the work that the osmc guys have done I may just have to go native deb and manually install Kodi.
If this is a configuration that isn’t (and don’t get me wrong, I can understand why) supported by the osmc team, maybe a block on the packages should be put in place?
Just because a user is suggesting one snowflake of a problem that has a confirmed work around be ignored by the devs, shouldn’t and won’t lead to a crippling of allowed packages.
That logic doesn’t follow. OSMC is beautiful in having the full debian repo available.
If you get the solution using your debian install let the forum know and I’m sure they’ll integrate the fix into the build. You never know, they may disagree with me and look into this for you.
We won’t disable any packages because so far we haven’t a confirmation that there is indeed a problem with the iSCSI packages.
Kodi should be able to access any path. Whether it is accessing an externally mounted filesystem or a file on an ext4 partition should not matter at all. I don’t think that installing Kodi on Debian will remedy this situation – but if it does I would look in to it further.
Your XML does not validate – so I would check that first. # is not an acceptable method to comment out a line in XML.
I haven’t used iSCSI for a number of years, but I would suspect you need to change the TCP buffer size, i.e. discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 on iSCSI
@martin_I I didn’t mean to cause offence, but I also can’t see a confirmed workaround in the posts above. If you wouldn’t mind pointing it out I’d appreciate it.
@sam_nazarko Ok I will revisit my xml and remove any items that are not required, thanks. Can I just ask: If the OS on the pi3 is able to access the iSCSI LUN fine and read/write with expected speeds, why should I be changing configuration on the LUN? Doesn’t the issue sit with Kodi?
I’d also like to say I don’t think there is a problem with open-iscsi, I think there is an issue with how Kodi reads the data on the presented drive.
Hi, just checked and the discovery.sendtargets.iscsi.MaxRecvDataSegmentLength is 32768 by default.