Posts by chewitt

It's historically very rare to see CEC capabilities on x86_64 hardware so the feature has long been intentionally omitted on Generic derived images (while enabled on ARM SoC devices which almost all have CEC capabilities). As such you can't claim it to be a bug. If there is now a trend of hardware being available; we might need to revise the build confguration. However it's not obvious that this is true, so I would focus on showing/sharing technical evidence of a need.

Quote

How do I install the TBS5230 driver that I have built into LE12.0.2?

Even if you align the kernel version magic and manage to build the module on a different distro, it won't be usable on LE unless the LE kernel's module and symbol maps are updated to reference it (else the kernel doesn't know the module exists). The driver .ko and related map files need to be inside the KERNEL file which is decompressed on boot (and is thus read-only and not accessible from inside the OS, the SYSTEM file is the same). The normal and long-term sustainable way to patch drivers into the LE kernel is to compile a custom LE image with the driver changes provided to the buildsystem as diff patches, which are applied to the kernel source before the buildsystem compiles the kernel. The compiled kernel and all required structures are then rolled up into KERNEL which is part of the LE .img.gz or .tar file format we use for updates.

NB: LE used to package Crazycat sources as a driver add-on, but we stopped including them because the Crazycat sources need to be aligned with the LE source version and there were regular periods of months before that happened, which held LE back from making needed kernel bumps. We got fed-up with that and now tell people to vote with their wallet and buy cards supported upstream, but the ability to build the driver add-ons has not been removed from the buildsystem. The kernel versions appear to be aligned right now, so you could also build your custom image with the driver add-on re-enabled and the Crazycat package.mk updated to use the latest version (githash) available. It's still a pile of jumping through hoops in our buildsystem, but might be marginally easier for a novice builder to figure out than extracting driver code from the TBS repo and generating diff patch files to use with our buildsystem.

In case it's not obvious, I'm not volunteering myself to spoon-feed instructions for either option. If you're curious enough there's enough hints above to figure it out, and the LE wiki has basic instructions for self-building images.

NB: These days I think TBS is a reference for "The BS" that customers need to go through to have a card work. Our general advice is to shift the DVB card and e.g. Tvheadend server to a box that runs a conventional distro where you can (re)compile modules for each kernel bump you choose to make (hint: you don't need to do it too often) using whatever instructions or garbage kernel the card vendor dictates: as long as it "works" you don't care. Then use an RPi5 to run pvr.hts as a simple/dumb client-only playback device elsewhere in the network.

Quote from Krize

the GUI is quite usable but the videos, when played, are very "skinny" and have large black bars on eithe side

This is from one of the RPi devs:

"If using dpi, there will only be a single resolution/refresh rate reported. They are configuring the display as 704x240 which will look to Kodi like a wide/short display (2.93:1), so when displaying 16:9 (1.77:1) video on it, you'll have black bars on the sides."

elim_garak I'm normally loathe to suggest it, but have you tried overclocking the board?

Quote from Krize

I can't change or adjust the resolution to get 480i.

Kodi only supports progressive output.

I have a moderately large media collection; around 2/3 the size of yours. I see occasional 'blank items' due to art being retrieved from the internet, but this is only when the install is relatively fresh. I regularly rotate the main family device among a pool of ARM boards for testing. The configuratin of Kodi and media content doesn't change but the Kodi install is effectively new and it takes a while for caches to populate again. After a week of use there are few 'blank items' and I don't notice caching.

Do you have media on a NAS in the network and a WiFi connection, or is it Ethernet to the NAS, or content is local?. It would be useful to see a Kodi debug log to see timings of actvities and what Kodi is actually doing under-the-hood (what scrapers are being used, etc.). and what errors are reported if any.

The Estuary skin is designed for a minimum 720p screen resolution. You might get further with other skins?

There is also a video calibration function in Kodi settings that you can use to adjust the edges of the screen.

Scraping content into the library creates online references to artwork in the DB, but Kodi does not download and cache the artwork from the online source until you start scrolling around in the UI triggering background downloads of original size art that must be resized and cached/stored, which is a CPU and I/O intensive task. You might have a fast internet connection, but the bottleneck for the Library views on older hardware is always I/O and CPU performance. You'll also see I/O as the bottleneck when scrolling around a large library as Kodi has to retrieve a large amount of art for display. The only way to improve this, esp. with a large library, is some kind of script/tool that walks the library and triggers all the downloads in advance (leave it running overnight, etc.) combined with an SSD to boost the I/O performance, and a skin that uses smaller artwork sizes to reduce the amount of data being moved around. If you want to run fancy skins; run fancy(er) hardware with more CPU grunt.

Option #3: https://www.amazon.ae/Cable-Compatib…/dp/B0D8M2KXZ6/ .. allows you to do things in a single step without non-standard configuration.

Option #1 .. Get an HDMI to VGA convertor cable, then VGA > Scart > Component > TV

Option #2 .. Get an HDMI to Component convertor > TV

The more physical and format conversions you use, the higher the risk of things not working right. So the desire to recycle some old connectors you have lying around in a drawer is strong, but option 2 is the better idea.

Something like this should work: https://www.amazon.ae/PARUIEN-Compon…e/dp/B0B7R5C172 and can be paired with a normal RPi micro-HDMI to HDMI cable on the input side, and you have Component RGB + 2ch audio on the output side.

If you leave music playing does it restart, or remain on a black screen?

cron doesn't run in the root user environment so $PATH is different and you should always use the /full/path/to/binary with any commands you run instead of assuming binaries are available in path.

I'm still using an Amazon essentials cable that RPi devs shipped out with the original alpha release RPi4 boards because nobody had them at the time. It works, so no need to replace it with anything fancier.

That's interesting, although from a release management perspective I would not consider switching Generic to OpenGL for LE13 for two reasons:

a) It's getting close to the likely release schedule for K22 and this is slightly exotic and thus needs proper testing on a wide range of GPU hardware (and Generic users often have older hardware).

b) It's a breaking change for Kodi binary add-ons and I'd like a release without breaking changes. In the last two releases we did Python2>3 and arm>aarch64. This time around it's stable, but we'll get enough whinging from dropping nVidia 340.108 support.

There's no issue to add another build option earlier though.

LE's installed base is roughly 80% RPi boards, 10% x86_64 hardware, and 10% other ARM boards. The x86_64 devices break down as 70% Intel, 20% AMD, 10% nVidia; most of the nVidia cards are older ones requiring VDPAU and legacy drivers, not newer ones with NVDEC. LE users mostly run Kodi to watch videos, so features like HDR playback trump shader support for games. The legacy image exists to service a handful of nVidia users and those who require a browser to access certain streams. I'm not aware that you can build mesa with OpenGL without X11, which means no HDR, and the long term goal is to bin X11 and only support GBM, and with either a GBM 'browser' or worst-case Wayland, which supports HDR, but doesn't currently support refresh rate switching which is a must-have feature for Kodi movie viewers. So right now all roads point in the direction of ```GBM/OpenGLES, not OpenGL. If it's now possible to run a GBM/OpenGL environment that would be interesting, but we'll look into that direction once there's a complelling reason; e.g. Kodi finally has Retroplayer OpenGL capabilities. It doesn't make sense for us to switch from a known/good formula unless there's demand. If you've already built Generic/OpenGL/GBM images that work? we'd have no issue with the changes being submitted to make development easier; similar to how we have options for Generic/Wayland although we don't currently build it. There's also no issue to add changes in LE that reduce downstream technical debt in Lakka, if that's at-all a related objective.

There used to be a "Plex Embedded" fork of LE run by some plex staff. Not sure it's still going though.

Quote from hbbs

Is anyone else seeing this?

Everyone running an LE13 image since https://github.com/xbmc/xbmc/pull/24899 was merged (10 months ago) sees the same. The timezone is now configured in the LE settings add-on. LE is/was kind of the 'odd one out' among Kodi platforms as the sole UI for the OS is Kodi itself. For e.g. Android, Windows macOS, and desktop Linux timezone is already configured separately in the OS.

docker run --name homepage \
  -e PUID=1000 \
  -e PGID=1000 \
  -p 3000:3000 \
  -v /storage/homepage/config:/app/config \   <= DEFINE WHERE /app/config SHOULD BE
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --restart unless-stopped \
  ghcr.io/gethomepage/homepage:latest

Assuming I guessed the container right? (https://github.com/gethomepage/homepage) the docker run command ^ needs to define where the config location resides and this needs to be somewhere under /storage not /docker/homepage/path/to/config which doesn't exist and can't be created since almost all of the root filesystem is read-only.

NB: config.txt file is an RPi thing, but it's used for setting boot-time hardware parameters so wouldn't be of any use for this task.