It's not possible to update the zone files without self-compiling an image. It's easier to update to a current LE13 nightly:
https://test.libreelec.tv/13.0/RPi/RPi4/
I've been running (own built) nightlies for the last 18-months and there's nothing unstable about them. The only reason we didn't already ship a K22 beta is me fighting unrelated Rockchip kernel patches.
Depends on what kind of bug report you are submitting. If you have triaged the issue and have a strong idea on the problem open a ticket on GitHub with all the information. Otherwise (and esp. if the issue was diagnosed with AI tools, start a thread in here first to avoid the noise.
That will happen, but it might not be for a bit as I am submerged in other things.
It still looks like it's playing something with a messed up mp4 container or H264 internal structure. If you copy the same file to local storage or play from an SMB share, does it play?
I don't speak English. If I create a ticket, I don't know how I'll be understood there, especially since people here don't understand me and misquote me.
Our advice for this forum is always to post in your native language, then copy/paste the Google translation underneath. The same works with support tickets. The flirc team is fairly small, but all nice people, don't be shy.
channel-map = front-left,front-center,front-right,rear-left,rear-right,lfeHave you tried something like that ^ in the config? (rearrange the text until things come out right)
Try default-channel-map as an alternative
I know little about pulse audio, but channel placement comes from ELD data which alsa derives from the EDID data on the HDMI connection. It might be worth ensuring (with Kodi stopped else it hogs the audio device) that alsa speaker-test can output 6ch audio correctly.
No idea as I don't run nightlies. I'm still working through PR11904 on RK3328 to solve some issues, then I might look.
Kodi has a native webOS app which seems to be a less ambitious or invasive approach 
the output of the signal is RGB 8-bit
DV is tunnelled (hidden) in RGB 8-bit frames, not 10-bit, so that's correct.
atirage21 I have better things to do than download and open random log files to guess what undescribed issue I might need to look at. You can stop posting them because I don't ever look at them.
maranzon I'd suggest updating to the latest firmware via the flirc config app; and if that doesn't change anything log a ticket with the flirc support team as they are the experts in their products. The first check on most support flows is "is the user running the latest firmware? - if no, update" so tell them you already did that in the ticket opening.
I'm describing the impact of 1080p desktop and 1080p+4K whitelist configuration. The TV panel is 4K native, but also accepts input in 720p and 1080p and will scale that (using its dedicated scaling hardware) to the native 4K resolution. If Kodi scales, it generates load on the LE device. If Kodi outputs 1080p and the TV scales, the TV takes the load. In almost all cases the TV will do a better job, so let it handle 1080p > 4K scaling and benefit from faster navigation and lower overall load. Scaling SD/720p to 1080p is trivial so Kodi can be used for that task.
Feel also free to just pick and rename the patches or do what you like with it.
I really would like to have this upstreamed.
HDR saturated colours was solved on all platforms months ago (before the summer). Go update to a current LE13 nightly.
The log looks like the device is continually trying to realign audio/video. That's either something from the Jellyfin server or perhaps the network, but my guess is this is about CPU load. It's not clear if you are running Jellyfin on the same RPi? (the Docker add-on is there but we don't list its containers anywhere) but I do notice that 1080p media is being played at (and thus scaled to) 4K.
Implement the whitelist and recommendations here: https://wiki.libreelec.tv/configuration/4k-hdr. This will result in a 1080p home screen and 1080p media playing at 1080p instead of being CPU scaled to 4K. This might not be cause, but as most skins are 720p or at most 1080p native GUI performance will be improved anyway, and it's good to rule this out.
There are two 'host' options in the file. One is IPv4, the other is IPv6.
Technically WireGuard has no concept of client and server since both ends are just network interfaces that route traffic. However as most users struggle with that, VPN providers and the wiki still abuse dial-up terminology; where the VPN provider operates a server and the LE device is the client. If your VPN provider only provides FQDN's for their host servers you will need to resolve them into an IP and use that, because ConnMan does not currently accept an FQDN as input.
