Struggling to Play 1080P files

I have two Kodi setups. One is a Asus Chromebox running LibreElec, and the other is a Vero 4K with OSMC. My media on network drives are all connected via Cat 6 and all devices on the network are gigabit capable so streaming local files has previously never been an issue in the past and none of these files are 4K or anything. I had wanted to incorporate a Jellyfin server which is running on a Linux Mac Mini, with the Kodi clients using the respective Jellyfin plugin in lieu of a Maria DB and that seemed to work well, but the Vero 4K is struggling to play back the larger non-Mpeg2 rips where the older Chromebox with LibreElec has no issues with playback of any files whatsoever. At first I thought it might be the Linux Mini and the drives connected to it and a bottleneck with Samba or network settings or something, but I just tried playing a file on the LibreElec Chromebox that was specifically not working well on the Vero 4K both through the plug-in and also through the file manager bypassing the server and both ways worked fine. There’s no issues with transcoding either and I verified that even when running through the server, it’s direct playing on the Vero 4K so whatever the issue is, it seems to be something client-side that’s different on the OSMC Vero 4K vs the LibreElec Chromebox, but I can’t find the obvious difference in any of the settings. What should I be looking for?

I’d suggest uploading some logs where you had rebooted twice, turned on debug logging, and then tried playing one of these problematic files. You might also narrow it down by playing the file from a thumb drive directly attached to the Vero to isolate between it being a network/Jellyfin issue or something else.

Which USB port is the 3.0 one for storage and which one is for peripherals?

They are both normal USB that can be used for either. There is a color difference as only one of them does USB OTG.

Ok, I think I did this correctly. Here’s the logs url. The file played from a thumb drive without needing to buffer. I still noticed the playback being a little choppy during fast movement if that makes any sense but never needing to stop. I rebooted the system and then tried to replay the file over the network, and it actually was able to play for quite a bit with similar performance. I switched episodes and got that one to get to a point where it locked up trying to buffer.

https://paste.osmctv/ asenuvehag

You did that logged into a kids profile and not the master user account correct? Can you try it using the master profile and turn on debug logging before you test playback and upload logs. When debug logging is enabled you should see a bunch of text in the top left of the screen to let you know its enabled. Our log uploader doesn’t try to parse the files from other profiles so I couldn’t actually see what Kodi settings you were using with that upload.

Ok I was wondering why I didn’t see anything. It’s a little confusing. There’s Admin/Adult/Kid profiles for the Jellyfin server but also for Kodi. I actually don’t remember what Kodi profile I used but I’ll double check later after I get home.

Hallo docsuess84,

I also had problems playing 1080p on my Vero 4K after the update in May: There was a visible slowdown after some time, followed by skips. I opened a ticket and finally Sam Nazarko told me, that a bug was found and to be fixed. In fact, for me the problem was gone after updating to the latest version of the kodi v21 test release. The procedure is simple and described here:
Maybe you want to try that, too.

Kind regards,


So I have another wrinkle in my set-up, and I’m not sure if my problem is OSMC-specific, but it might be related to the default configurations. I eliminated a bunch of factors to see what will reproduce my file transfer issues and what won’t. The files that struggle are always the ones stored on drives locally mounted on my host Lubuntu Mac Mini. The drives themselves are available on the network as Samba shares. And problematic playback wasn’t limited to the OSMC Vero 4K client. I also couldn’t play files very well on VLC on my iOS devices. Even after adjusting the latency settings to the max. That is, until I unchecked the box “Prefer Samba 1”. Now it’s working fine, but when I try to play the same files through the Swiftfin app, same issues as before. LibreElec on the other hand has no issues with any files on any device served from any drive. So whatever the underlying issue is, it seems to be related to the Samba protocol when it comes to files served from locally mounted drives on my Lubuntu Mac Mini and OSMC clients, and until just now, iOS clients as well. I don’t even know how to mess with the Samba configurations on the host side. Is there some kind of setting that would force the host or client devices to use Samba 1 in some instances but not in others?

I would try NFS as an alternative or parallel to Samba. In a plain setup, NFS offers only basic security features, but if you are the only user in your LAN, that should be no problem. For Lubuntu as file server and OSMC as client it’s a more natural choice than Samba anyway. And if the problem remains, another factor is eliminated.

Kind regards,

I got some feedback on the LE forum that confirmed what I thought. The default settings on LE are set to negotiate SMB v 2 and SMB v3 if available and won’t even try 1 unless you tell it to. I don’t know how OSMC works as far the default configurations. My original plan was actually do use NFS for sharing network files as well as for mounting network drives in the fstab file. I just didn’t know what I was doing and couldn’t find a decent guide that used NFS instead of Samba for mounting a network share in Linux. Now I I have a better idea.

If you go to the services section in Kodi’s settings you will find where you can set min/max SMB versions which will affect which protocols that are used when you add a source using a SMB path. If you wanted to configure a system mount using either SMB or NFS you will find guides in the howto section for both fstab based and autofs. Using either method to manually create a mount also allows you to specify the SMB version to use.

Ok. I updated the Samba settings to use 2 ad minimum and 3 as a max and I actually tried playing the same file in multiple drive locations as both a Samba and NFS share. The results were basically identical regardless of drive location or file sharing protocol. The only thing I didn’t do was move the Vero4K to a different location and try everything there. I did remember to enable debug logging though.

I see in that log you playing a few files that are streams from jellyfin, not direct paths from Kodi.

I verified Jellyfin isn’t the issue. It’s configured to direct play and the logs confirmed it is. I tried it multiple ways within Jellyfin and outside of it and nothing mattered. I did test it after moving locations and lo and behold, it played fine in my bedroom. There’s something about the network connection between the living room (literally one room away) where I had set up the Vero 4K and my bedroom where the Mac Mini host and all the hard drives are. I was using power line adapters so maybe mice chewed on the wires or something, but a wireless connection was slow and unable to keep up as well, and I thought my router was up to the task. I reversed the setup and moved the LibreElec client out to the living room and was able to reproduce the issue both wired and wireless, so it’s definitely a network thing not limited to the Vero 4K, I’m just not sure why exactly.

Powerline adapters tend to be highly variable in how well, and how fast, they work. They are affected by both the house wiring, and potentially by interference from other devices plugged in emiting electrical noise. If they used to be faster but have degraded you might try rebooting them (which probably just means to unplug and replug them in) which can sometimes get them to renegotiate with each other at a higher speed.

If you have an old router laying about you might also try configuring it as a wireless bridge (It would connect to your wifi and then other devices would connect via ethernet) and see if that gets you to your end goal.