I’ll do what I can to provide a sample of a stream that causes issues on the Vero but works perfectly fine on the pi3.
The reason I was thinking it would be a good ideas to look at the logs of both machines is me thinking the pi3 could show what is working fine with all streams and the Vero logs could maybe show what isn’t.
The Vero logs are grabbed after two reboots, after Library and playlist import and only playing the troublesome stream.
The pi3 logs are grabbed in the same way, playing that same stream, only it’s working just fine.
Sure, the list is big, but like I said, working just fine for years on my bedroom pi3 running osmc.
I’ll tried switching adjust display refresh rate to always and it made no difference
I tried grabbing a recording on the Vero for a stream that was causing issues but notice that playing back the recording results in a smooth playback.
I then found and enabled timeshift on the IPTV simple client addon and that seems to solve the playback issues and all streams start and play fine using HW acceleration. Not sure if this counts as a solution though, I don’t have timeshift enabled on the rpi and I’m guessing continues recording to the flash drive will shred the drive a lot quicker on the Vero.
If timeshift is improving things then it may be a network issue.
How are both devices connected to the network?
Both devices are connected via cat6 ethernet cable to a 5 port gigabit switch going to the router. I have a 500/500 fiber connection to the home.
Streaming high bitrate files over LAN (nfs) and other streaming services (Discovery+) on the Vero work just fine, also, disabling HW-acceleration plays the troublesome IPTV streams with only minor issues (a stutter here and there), but I’m thinking those issues have to be related to the 100% CPU usage I’m seeing on all cores using SW-decoding, and not network related.
Also, I’m not seeing any drops in the buffer of the stream
Will check your logs later for anything obvious and report back.
1 Like
Thanks, I cleaned up the rpi log aswell, removed Old Kodi log and all the repetitive import rows from the addon: https://paste.osmc.tv/ayarexogoq.xml
If the time shift is happening on the playback device I’m guessing it is going to Kodi’s temp folder. If this is the case, and one wanted to use this feature while not introducing additional wear on their eMMC, then you could use an SD card or some form of USB storage storage device and path substitute the temp folder to that other device.
Thanks, will absolutely have to do this if the root problem with playback can’t be found or resolved.
I don’t see an indication that this is the issue, but It may be worth a try to make a file at ~/.kodi/userdata/advancedsettings.xml with the following content…
<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
<cache>
<buffermode/>
<memorysize/>
<readfactor/>
</cache>
</advancedsettings>
and restart Kodi. If that makes playback worse just delete the file.
Happy holidays everybody 
Thanks, tried this while having timeshift disabled and it unfortunately made no noticeable difference.
I have now removed it from the advancedsettings.xml.
Furthermore, I did go and add path substitutions for both temp and timeshift, posting my config here if anyones interested
<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
<pathsubstitution>
<substitute>
<from>/home/osmc/.kodi/temp/</from>
<to>/media/d1fd363a-5537-da01-00f9-363a5537da01/kodi/temp/</to>
</substitute>
<substitute>
<from>special://userdata/addon_data/inputstream.ffmpegdirect/timeshift</from>
<to>/media/d1fd363a-5537-da01-00f9-363a5537da01/kodi/temp/addon_data/</to>
</substitute>
</pathsubstitution>
</advancedsettings>
the cache size would need to be set to “0” (zero) so it saves the entire file to disk instead of caching just part of it to RAM combined with moving the temp file to a different location but I have sense found that you can’t currently path sub the temp location as Kodi needs it before it reads advancedsettings.xml (I thought you used to be able to do this but I’m not sure) so neither the full path or special://temp in a path sub is going to actually change the temp folder location. I had a quick go on just doing a symlink for the temp folder but that made Kodi very unhappy and it refused to boot. I’m not sure on how exactly one would go about moving the temp folder location at this moment.
Yeah, seems just part of the temp folder is moved when using path sub. I can only see the ‘scrapers’ folder on the sd-card but the original temp folder contains more than this folder.
The addon data, and the ffmpeg stream substitution is working however and I can see it writing to the sd card during playback and removing the recording when stream is stopped 
1 Like
Sorry, don’t wanna stress or anything just wondering if the dev team has had a chance to take a look at this?
Even if enabling timeshift with iptv simple client improves watching live TV, it’s still no where near the experience or stability I’m seeing with kodi on raspberry pi (3), android or even Xbox. Something has to be different on the Vero. Please let me know if there’s anything I can do to provide additional info or testing.
Didn’t hear anything for a while or see some logs so I assumed the matter was closed.
Can you provide some new logs showing the issue?
Oh, ok
We’ve must have misunderstood eachother I guess
The logs for the rpi (same stream, about same time)
https://paste.osmc.tv/ayarexogoq.xml
Logs from v4k+
https://paste.osmc.tv/fobebibexi.xml
@sam_nazarko just checking if you’ve had any success finding the issue?
As mentioned, this seems to be a vero specific issue. Not only is it working without issues with osmc om rpi, but also no issues with kodi for android, xbox or Windows.
Really breaks the experience needing to use other media players 
Have you tried updating? We’ve a number of playback improvements in the April update and you may find the issue is now resolved.
Just updated to the March update and everything seems good so far! Thanks, appreciate it! 
Great, thanks for confirming. I’m glad this is solved.