Setup with my new Vero 4K+ was largely uneventful (save for a strange and inaccurate error message about the device being unable to find the internet during setup), and the advice I got here was spot on. The performance of the device is really wonderful, a true videophile solution for kodi. Bravo.
One small detail that has been a bit irritating during use: the menu/GUI often hitches during scrolling operations. The behavior is present with both the included RF remote and the Harmony Hub attached via bluetooth. Responsiveness to button presses is immediate with both devices, but once I start scrolling through a long list of titles it starts to hitch and lag. By comparison, my years-old Asus Chromebox was buttery smooth. The issue is present whether the UI is set to 720p or 1080p, 59.94 or 60hz.
Any advice on improving the performance of the interface in this scenario? Or is this normal?
I have quite a library on mine and the only “hitch”, if that’s what you want to call it, that I notice seems to be when the scrolling jumps to a different scroll speed.
If I press down on my remote and hold it, it goes down one title from the initial press and the realizes I’m still holding the button so it starts scrolling and what I’ll call speed step 1, then as it goes past 5 or so titles it “hitches” as it begins to go into a faster scroll speed that I will call speed step 2, and from there it just scrolls through my library all the way to the end without hesitation.
Care to upload a video of the scrolling from your ASUS Chromebox and a comparable one from the Vero?
I’m curious to see what your experiencing.
Unfortunately the Chromebox is already packed away (my apartment has limited space :). The difference is pronounced and easy to describe: almost as if scrolling on the Vero 4K+ has a lower apparently framerate, with intermittent hitches and lags. The Chromebox, by comparison scrolled smoothly with a very even, nearly imperceptible latency when moving between entries in a list.
It would help if you told us what skin you are using. And logs are also helpful.
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device
reproduce the issue
upload the log set either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
All my responses were using the default skin.
I probably shouldn’t have assumed but since you didn’t mention which skin you were using I assumed it was the default.
Tried that skin and had the same issue you had presumably.
It hitched at L and again at S.
A message box came up while I was scrolling with an error about an extended script and to check the log but disappeared before I could read it thoroughly.
Default OSMC skin performs better, but still starts lagging after a second or two of scrolling. This is definitely easier to live with than Aeon Nox, and it still looks great. I could live with this, but improvements would be welcome if they’re not burdensome.
It’s something I noticed, but when you’re running resource heavy skins then its to be expected when you consider the hardware specs.
It was mentioned elsewhere that there’s no hardware acceleration when in the menus…so this probably plays a big part in it.
I found turning off fanart backgrounds in the OSMC skin made it perform a bit better…but the problem really is people expecting HTPC performance from a 100 pound bit of kit.
Noted - I’m pretty OK with the OSMC skin now that it’s configured (which took some tweaking of the background color opacity etc). I have some questions about configuring it that I’ll create another topic for.
@fzinken - Keep Audio Device alive did make a difference. Scrolling speed increased perceptibly, but then interface sounds started to lag behind scrolling speed. Disabling Keep Audio Device alive slowed down scrolling speed a bit but brought the two back in sync. I’ll play around and see which I prefer.
Is there any practical downside to Keep Audio Device alive?