Posts by chewitt

If you run avahi-browse --all on the Linux box (assuming avahi is installed, it probably is) it will show all the mDNS services that are being advertised on the subnet. Is the LE box visible there? .. e.g.

ROCK5B:~ # avahi-browse --all | grep RPi5
+   eth0 IPv4 RPi5                                          _ssh._tcp            local
+   eth0 IPv4 RPi5                                          _sftp-ssh._tcp       local
+   eth0 IPv4 root@RPi5                                     _pulse-server._tcp   local
+   eth0 IPv4 root@RPi5: Null Output                        _pulse-sink._tcp     local
+   eth0 IPv4 RPi5 eventserver                              _xbmc-events._udp    local
+   eth0 IPv4 RPi5 jsonrpc-tcp                              _xbmc-jsonrpc._tcp   local
+   eth0 IPv4 B827EBB5E9A2@RPi5                             _raop._tcp           local
+   eth0 IPv4 Librespot@RPi5                                _spotify-connect._tcp local

LE13 nightlies now allow the Retroarch flatpak to be installed from the LE repo. No idea if that helps or makes things easier?

If the laptop and iPhone can connect the LibreELEC side of things is working fine. That means the issue is either Android (possible but IMHO unlikely) or the network (my guess).

Auto-discovery features normally use mDNS broadcast on the network (and LE supports this) but if you have multiple switches in a daisy-chain or bad config in a managed switch the broadcast traffic might not be forwarded. Another common mistake is having a wireless router plugged into a switch and not configured as a wireless bridge; meaning a NAT firewall runs between LAN and WLAN segments and the firewall blocks the traffic.

Describe the layout/devices of the network.

I'm in the UK for a few days so I packed a WeTek Play2 box on the off-chance I'd be able to test the DVB-T driver that me/Claude came up with recently. The above screen grab is from VLC on a MacBook (as there's no TV to use Kodi with) streaming BBC1 from Tvheadend installed from the LE repo, and running on the box. I'm genuinely surprised it works

NB: Reworking the current driver code into an upstreamable driver is an entirely different challenge!

taki  rozpruwacz

At the moment HDMI (and things like audio which are related) and 4K/HDR/decoding patches that were originally created back in 2019-2022 need to be reworked against current kernels which have moved forwards in a few areas. Some of that work has started, but I need it to get a little further along before I can pick and integrate patches into the already huge kernel patchset (of things now being actively upstreamed) that's used with newer Rockchip boards like RK3588. Until that happens, I'm aware that current (older) patches have some breakage. Whether that's the root cause of your audio problems or it's something else is unknown, but until we can get older boards using the same kernel as new boards (with updated patches) I'm also not too interested to investigate; audio is not my area of expertise and trying to get developers (some ours, some upstream) interested in known-outdated and downstream patches will be frustrating. You are welcome to try nightlies, but as the same patches are used there currently, I won't guarantee anything is better. No harm in trying though.

The USB keyboard should have worked. Historically there was a bug that caused the USB hub to not reset and detect things but that claims to have been fixed in the upstream kernel some time (a couple of years) ago.

HDMI-CEC should also work, although this is something I never normally test because I have too many CEC capable devices attached to the same AVR and it causes problems; so I disable/block it on the AVR.

If you add ssh to the boot params in exlinux.conf the SSH daemon is forced to start on boot, and then you can SSH in to the device and use kodi-remote to navigate the screen same as a remote control. The Odroid remote is also supported OOB if you have one.

I've pushed a clean rebuilt Generic image to https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz - I think the issue above is the result of an unclean build after we switched the Generic image from OpenGL > OpenGLES last week.

Please try again.

Clean boot with Kodi in debug mode and then share a log URL using "pastekodi" .. else we have nothing to investigate.

Over time people wanting to use Kodi in a Kiosk use-case wrote their own scripts to manipulate Kodi .. but .. THERE IS NO SUCH THING AS KIOSK MODE. Feel free to prove me wrong with a screenshot from the Kodi GUI - anywhere it says Kiosk.

Quote from Da Flex

There is a chance that kiosk mode uses more RAM

That's a load of BS because there is no special 'kiosk' mode in Kodi, only 'normal' Kodi being used with a repeating playlist in a kiosk scenario. Ergo there is no difference and thus no magical increase in RAM use.

Go test this image https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz and report back. Note that this image is LE13 and we switched Generic from OpenGL back to OpenGLES so if you have screensaver and visualisation add-on installed those will need to be removed, the cache in /storage/.kodi/addons/cache deleted, and then the add-on needs to be reinstalled else things will crash. Just leave settings present and it's no big deal.

NB: I'm not answering the Q's above as there are known rendering bugs solved and notable changes to rendering in this image; and the combination means triaging anything on LE12.2 isn't a productive use of time (there are no plans for a 12.3 release).

Honestly no idea. Try other hardware. Try fixing the media. Try current nightlies. Experiment and observe and report back.

It's all documented in the kernel source, both as technical documentation on the UAPI's, and in the resulting codec driver code for each SoC/silicon specific implementation. I'm going to stop at this point because vague questions require long and time-consuming answers. If you're truly curious, it's all open-source, go read or ask a decent AI tool to summarise for you.

error <general>: CVideoPlayerVideo::OpenStream - Invalid framerate 300, using forced 25fps and just trust timestamps

I doubt this ^ is enough to cause problems, but it's a simple task to run the file through "handbrake" and fix the file. You can also bump to a current LE13 nightly and see if that magically solves anything? - otherwise I don't see anything unusual in the log (no obvious freeze, no crashes).

SMB connections to the local Samba server (incoming) = Settings > LibreELEC > Services > Samba

SMB connections to another SMB/Samba server (outgoing) = Settings > Services > SMB Client

To make Kodi connect to an older SMBv1 share you need to set min/max = SMBv1. If you set it for min = SMBv1, max = SMBv3 it will default to connecting at SMBv2 and will never attempt SMBv1.

The kernel UAPI's for DRM/KMS/V4L2 are maintained and regularly evolve. If they were not they would be deprecated as dead code and removed from the kernel. There is documentation in the kernel source and since this is a fundamental and core part of the Linux kernel, there is extensive prior-art in kernel code.

Kodi uses mesa for 2D capabilities GLES/GL and opening the EGL context that video/gui are rendered into. Kodi is largely a big fancy wrapper around libavcodec (FFMpeg) which for an RPi4/5 uses the uses the v4l2_request (stateless) UAPI for HEVC and on RPi4 (but not RPi5) the v4l2_m2m (stateful) UAPI for H264 support. FFMpeg also supports fallback to software decoding, e.g. how H264/VP9/AV1 etc. are handled on RPi5. If implementing changes you'd also need to consider VAAPI too, and in the near future NVDEC.

I'm not sure what thoughts you're having, but IMHO anyone who needs to ask where documentation is and how it's done will not be successful in coming up with meaningful changes themselves. Even working with Claude Opus and similar AI tools requires a baseline level of domain knowledge to generate prompts that achieve anything.

Quote from Quiffy

Any thoughts based on your experience?

Quote from Quiffy

Offtopic: is there any specific SSD brand / model /series that you can recommend from your experience in terms of a) reliability and b) low power consumption?

I've never considered power consumption with SSD's in LE installs as the hardware it runs on has far more impact than the choice of drive and because LE runs in RAM on anything with more than 1GB so there's negligible read/write on the drive.

I've always picked name branded SSD's on the debatable assumption they won't use low-bin chips. Thus the only drives I've ever had die (not a frequent occurence) were name-brand ones. I pull things apart, move things around, and reinstall the OS on a much higher frequency than any normal user though.