The addon version in the Kodi repos hangs for a second when switching presets

[x2k13]

Hardware is Firestick 4K with latest updates and Kodi 19.2 Android armeabi-v7a.

Whenever I set any preset packs other then projectM or stock in visualisation settings, the random preset change always hangs 1 to 2 seconds, audio stopping. Big turnoff while listening to music as you might agree. I suspect a mix of item count in the folders and speed of the randomizer being the culprit.

The setting Tryptonaut is the worst, and it contains - don't know exactly - thousands of .milk presets.

Could the randomizer script/code/function maybe improved speedwise? As far as I can tell the freeze/stop/lag seems to just occur when swapping presets in random mode. If set to just a single preset, no lag, just fun. No matter if the render settings are on max or not. This is for both scenarios. The rendering settings have no effect on the performance of the preset swapper in random/shuffle mode.

Would be nice if that could be addressed and improved because I believe that this isn't a hardware performance issue with a stick that can flawlessly render 4K/UHD Blueray movies with full bitstream and HDR10

[kblaschke]

Could you please check if there are tons of textures/images in the preset directories?

Some preset packs come with screenshots for each preset, which is fine with Milkdrop, but projectM will currently load all these images as textures and sends them into the GPU no matter if they are used in a preset or not.

If this is the case, try deleting the preview images.

If this is not the case and you just have thousands of presets, then the Kodi plug-in might re-scan your directories on each preset switch, which would be strange, but might be the culprit here - then please open a report in the respective Kodi add-on repository. Preset switches themselves are normally quick as projectM only reads a single preset and displays it. The preset list size isn't really an issue once loaded.

[x2k13]

Hey @kblaschke thanks for answering. My custom preset directory contains 2169 .milk preset files (all I could find across the net). No images or any other type of file except .milk presets. Opened another issue over at the addon repo, thanks for pointing me there!

[kblaschke]

I'll leave this issue open for now as it might well be an issue in the library itself - probably requires some additional testing to see where is happens. If we can rule out a re-scan of the presets on each change, the next best guess I can come up with is loading the preset, including shader compilation or some issue with GLES.

[angomania]

Same issue with my Firestick 4K and latest Kodi/Addons update.

[kblaschke]

Android builds also use GLES. Will have a look at it once we've got the new API stable for the 4.0 release, then adapt the add-on to use the new version/API. With a bit of luck, some fixes since the last release have improved the situation, but if not, it's certainly something we could at least debug and see if there's room for improvement. I've got no FireTV stick, but it should behave similar on any Android phone, of which I have several I can use for testing.

Also note that even the latest Kodi add-on still uses the official projectM 3.12 release from last year.

[x2k13]

Android builds also use GLES. Will have a look at it once we've got the new API stable for the 4.0 release, then adapt the add-on to use the new version/API. With a bit of luck, some fixes since the last release have improved the situation, but if not, it's certainly something we could at least debug and see if there's room for improvement. I've got no FireTV stick, but it should behave similar on any Android phone, of which I have several I can use for testing.

Also note that even the latest Kodi add-on still uses the official projectM 3.12 release from last year.

One thing I noticed is, almost every 1.x preset seems to run pretty good, whereas the 2.x presets often stutter and sometimes the screen turns black (apparently because these presets can't be rendered at all).

That being reproducible, narrows it down to the 2.x presets relying on something that the (awkward) implementation of eGLS of the heavily modded Amazon Android might be missing something.

Just a wild guess because I still haven't found out a way to pull logs from Fire TV to be sure.

Edit: I forgot to mention that I ran a search for and deleted all 2.x presets via console (Linux) and copied all remaining 1.x presets with a 5.0000 rating to a new directory, then tested those. The fact that there still are way over 20k presets (found a lot more on GitHub since), makes the switching even more laggy - but at least they render okay.

Maybe it's a combination of 2 things: Preset version (2.x) and/or too many presets in a directory.

Anyway, I'm looking forward to the new release. 🙂

[kblaschke]

Might well be the case, or just the GPU in the stick being optimized for video decoding. The same hangs can be experienced if projectM runs with emscripten/WebGL, but that's mainly because JS has no multi-threading support. I bet main reason in both cases is shader translation and compilation.

[ABerguerand]

Using an Nvidia Shield 2019, same issue.
After some experimenting, the issue is simple to reproduce : presets using shaders trigger the one second stutter when switching, while other presets switch smoothly.
The issue must be in the part that initializes shaders.

[kblaschke]

Reason is that basically the whole preset loading code, including the shader compilation, runs in the rendering thread. This includes all the stuff that happens on preset loading - reading the file, parsing equations, loading textures and transpiling the HLSL shaders.

Ideally, this should be done in a separate asnychronous thread, with the actual preset switch happening the next frame after the preset loading has finished. While this would introduce some potential lag to the "on-beat transition" AKA hard cut, which probably no one even knows about, it should not impact rendering performance that much (except the device is already at its limits, which would cause a slight FPS drop, but no complete hang).

Since we now have switched to C++14, we could make use of the STL threading library, which works equally well on all platforms. But to make preset loading asynchronous, some internal code refactoring is required as the loading process is currently split over several involved classes and not easy to change.

We'll first get the next major release ready. which is mostly focused on a new build system and a C-based API for easier integration. After that is done, alongside other improvements, we can start tackling this long-running problem.

Any help with implementing that is always highly appreciated.

[Drakonas]

Do we have any status updates for everything mentioned in the last post? It's been nearly a year. Just checking in because this is still an issue with the latest Kodi 19 for Nvidia shield and I'm not sure if this team fixed it at the source yet.

[kblaschke]

There were numerous fixes to the codebase in the meantime, but the Kodi plug-in (not maintained by the projectM team) wasn't updated since 2020. So even if there are changes which make it behave better, it's still the same in Kodi as it uses the old 3.12 release.

Besides that, if the shader compilation is the culprit, there's not much we can do on our side with OpenGL. Since everything done in OpenGL must take place in a single thread, it's completely up to the drivers to asynchronously compile shaders.

There's probably some room for improvements when switching presets, e.g. doing less stuff multiple times. We'll get to this after the 4.0 release, which mainly focused on the external API.

[kblaschke]

As this issue is open for a long time, and libprojectM was mostly rewritten in the meantime, I'll close this issue.

The Kodi plug-in is still using an old 3.1 version of libprojectM. They'll have to update the plug-in to use libprojectM 4 and ideally build against the soon-to-be-released 4.1 update, which will most existing issues and also provide way better visuals due to the vastly improved Milkdrop 2 compatibility.