At /usr/share/kodi/system/setting/settings.xml the GUI definitions and default values are stored. They are read-only by concept.
Unfortunately <maximum> is part of the GUI definitions, and not editable by overwriting it at /storage/.kodi/userdata/guisettings.xml.
PS: It should be possible to write a slideshow as a Python script. Then you can set the pause as long as you want.
Read here about using composite A/V.
I uploaded the logs via the suggested options in that mode here: http://ix.io/1xhr
You are using LE 9.0.2 on RPi. This combo is known to run very stable.
2019-10-05 20:35:11.438 T:1936855056 ERROR: CProfileManager: error loading special://masterprofile/profiles.xml, Line 0
Failed to open file
2019-10-05 20:35:11.438 T:1936855056 NOTICE: special://profile/ is mapped to: special://masterprofile/
2019-10-05 20:35:11.438 T:1936855056 FATAL: unable to load profileMy bet is a broken microSD card. Follow my above advice to check or repair the card.
Nice to hear you made it!
Interesting for me is that no i2c configuration was necessary, because both devices are using that bus.
Have you been soldered the the RTC module on top of the DAC board?
ERROR: ffmpeg[E2E2C380]: [AVBSFContext] Channel mapping 2 is only specified for channel counts which can be written as (n + 1)^2 or (n + 1)^2 + 2 for nonnegative integer n
Changing the amount of audio channels at the LE audio settings doesn't help?
Since the latest libwidevine update yesterday, the buffering issue is gone. I can't tell whether ISA or libwidevine has been the cause of the issue, because both are needed to decode the DAZN streams.
Have a look at "Settings -> System -> Input -> Enable mouse and touch screen support". Maybe you have to disable this option to set a resource free for your project.
It works on Armbian, so Kodi itself could be the cause for some low data priority, which eventually leads to data loss.
Especially there could be a tricky tr@de-off when input and output device is the same. I stay with my theory, leaving USB can make it safer.
PS: I found a censored word again: tr@de. 
Hey JeffR , what's up? 
If you want to read more about LE touchscreen experience, click the last link of vpeter 's signature.
Interesting note about USB reliability vs. GPIO. Unfortunately I have 22 of these type of cheap touchpanels, and I can't change at this point. (This is for interactive displays at a charity haunted house)
Maybe you can reverse-engineer those panels, and use the connectivity before the USB controller.
Really? Can you clarify more? Any links maybe?
This guy wanted to make RS232 work over USB, but it only worked sometimes:
CH340/CH341 USB to RS232 not working
Of course, if you use standard hardware like a memory stick, then USB works fine.
If you use non-standard hardware with unusual protocols, then stay away from USB, and use a GPIO protocol.
PS: I'm not a kernel hacker, but I think we have to split USB in two levels: USB transmission standard, and the protocols, which are using it. At the protocol level, it seems like some protocols have low priority, so data can get lost, even if the kernel driver is present.
Using USB connection is unsafe. Find a touchscreen, which uses a GPIO protocol, like i2c. The RPi has the same issue, that's why I know.
Use hifiberry-dacplus.dtbo and i2c-rtc.dtbo. According to this both modules have no GPIO conflict.
Sorry, this is utter nonsense. The serial_ir driver will load whenever there's an UART present. And as the OP already wrote in his first post that he's not getting any output chances are very high there's nothing attached there.
What kind of output do you expect from a serial port device at boot time?
Sigh. If you had paid more attention then you'd noticed that this was the serial_ir module the OP had loaded and as the SOC has a built-in UART the module load succeeded. This doesn't mean that there's an IR receiver attached to the serial port.
We know the IR receiver is attached, and the serial_ir driver has been loaded. That's enough for me to trust the /dev/lirc0 output.
The Android-x86 Linux (yes, I'm sure it's Linux) can handle it, which makes it very likely to work with LE, too.
Sorry, but this is nonsense. LIRC needs an IR device/driver where it gets it's signals from and this is missing with the box. Running LIRC won't help.
If you have a look at the start posting (ir-keytable output), you can see that the LIRC device is ready to go.
No, i don't use usb IR dongle, my box has a built-in IR receiver. This IR receiver works fine under android, but it refuses to work under Linux.
Android-x86 OS'es are usually based on Linux kernels. At this point, my conclusion is that your built-in IR receiver is made for LIRC, and does not support most of the IR protocols LE is offering. Your Android-x86 OS probably has LIRC enabled, and that's why it's working. Under LE you have to enable / configure it as mentioned.
Many LE users prefer CEC, because it uses the TV remote control without the need of dealing with IR signals.
