Posts by chewitt

Crash logs are normally in /storage/.kodi/temp/ .. upload a zip somewhere (but ideally not here) if needed.

Have you read https://wiki.libreelec.tv/configuration/4k-hdr?

RPi4 and RPi5 do not support 4K@60 4:2:0 output, and some TV's (or specific HDMI ports on the TV) only support 4K60 4:2:0 input, so when the RPi outputs e.g. 4K@60 in 4:2:2 the TV cannot display that format. On some TV's the solution is to enable "Deep Colour" or some kind of special/extended/enhanced modes on that port (there is no standard terminology so vendors invent their own weird namings) or to move the RPi connection to another HDMI port that supports 4:2:2.

Are you using adjust-refresh + whitelist to play [email protected] content at [email protected], or is it being forced to 4K@60?

NB: RPi4/5 have identical HDR capabilities. DRMPRIME must be enabled with the Direct-to-Plane settings (not EGL). Also ensure that on the RPi side the HDMI cable is connected to port 0 nearest the PSU connector.

These are "nodes" in Kodi terminology. Have a look at the Node Editor add-on in the Kodi repo.

It looks like the /storage partition was not expanded to 100% after the initial writing of the image, although when that fails we would normally see a 32MB partition not 160MB (as the 512MB image has a 32MB /storage partition). I would boot from an SD card so the internal storage is not the boot device, then unmount any auto-mounted /dev/mmcblk1p* partitions. Now you can use 'parted' to resize the partition and 'resize2fs' to grow the filesystem.

tomybyte The current working theory among Pi devs is that something related to error validation fails under 16K pages and thus when the filesystem ends up in an 'unclean' state (which happens sometimes in normal use) the driver cannot self-fix the issue. Booting the 4K kernel allows validation to complete resulting in a 'clean' filesystem state again. Once it's clean you should be able to run 16K page kernels; until the filesystem ends up unclean again.

Store a copy of the image I've shared somewhere (as I will likely overwrite it with a 16K kernel version) and switch to an LE13 nightly which has the default 16K kernel. First proove that you can boot fine with it (we expect this to succeed). Then we wait for NTFS to end up in a dirty state again. Then you can use the 4K image to test the "one 4K boot fixes" theory.

If the server-side of the PVR add-on supports recording Kodi will expose recording controls. However normal add-ons and IPTV sources do not support server-side recording; thus those controls are not shown. Kodi intentionally does not provide a universal "record stream to disk" function as that would result in mass piracy of online streaming sources.

NB: Discussion on how to configure recording from pirate IPTV sources is not welcome in this forum. I'm making the assumption it's a pirate IPTV source because I have no recollection of ever seeing someone show up with a legal/non-pirate one.

From fuzzy memory .. You edit the addon.xml and change the skin id from skin.estuary to skin.custom and then either restart Kodi or reboot. You can then browse local add-ons to enable skin.custom (as the add-on should/will be disabled) and then you should be able to select it as the active skin in Kodi settings.

[Unit]                                                                                    
Description=Kodi user autostart script                                                    
Before=kodi.service                                                                       
After=network-online.target graphical.target                                                                                      
...                                                                                                                 
[Install]                                                                                 
WantedBy=kodi.service

^ that explains when autostart.sh is run; after the network is online but before Kodi starts. It used to be at the start of userspace boot (much earlier) but users were always trying to schedule things that depended on the network so it was changed.

The contents of /run are (re)created at boot time based on scripts embedded in the read-only SYSTEM file (which expands on boot to create userspace) so all changes made there are intentionally lost on shutdown. The resolv.conf file is also managed by ConnMan so any changes to it can/will be overwritten when ConnMan feels like it, and since everything in the OS including ConnMan runs as root changing file perms to prevent changes to the file probably won't achieve much as you cannot restrict change from root.

The correct way to effect change to resolve.conf is making changes through ConnMan, using connmanctl. If you need to e.g. reorder services to ensure the tunnel has priority, you may need to execute a sequence of reorder commands to move things around into the correct sequence. Such things are a bit clunky, but ConnMan was originally created for phone devices where such wizardry isn't needed, so it's not blessed with highly scriptable controls.

In terms of boot timing: /run/libreelec/resolv.conf is created by the connman-setup script which is executed by connman.service. If you want to understand more about OS plumbing and boot scripts the easiest method (as I have just done myself) is to "git clone" our sources and then use "git grep" in the sources folder to find mentions of binaries and paths.

The "dev" in question here is Sam from OSMC (so he's no stranger to his own patches). Sam would like 3D to work on RPi hardware again, but that development is something for RPi devs to handle. It's already a task in their to-do list. The challenge is that it's a very low priority in the list, the list is a long one, and there's a continuous drip-feed of higher priority items being added to it.

Thanks for the report. The device-tree files will be submitted to master (LE13) for wider use/testing and if that goes well I will think about backporting the same changes to LE12.

Quote from dmladenov

All are played in software with decoder ff-vp9-drm_prime(SW). No blank screens or crashes.

Thanks for confirming that. I picked up a cheap box but it hasn't succumbed to booting LE yet

Quote from HarryH

the AMLGX image works for RPi5 too?

No .. too much finger memory with Amlogic images. Link updated.

For kicks, this image (LE13/master, so backup /storage/.kodi first so you can revert to LE12 after) is compiled with 4K pages:

https://chewitt.libreelec.tv/testing/LibreELEC-RPi5.aarch64-12.80.0.tar

Go experiment and see if that resolves anything?

EDIT: now linking the right image

Time starts from the libc compile datetime (not last boot) and then jumps forward to current time when NTP kicks in.

Just "rpi-eeprom-config --edit" .. drop the -E

dmladenov I'm interested to see if the latest image: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar will handle VP9 media correctly. I added some patches to handle GXLX hardware so it should software decode (badly) instead of showing a blank screen or crashing or some other form of failing to hardware decode the content (as the silicon doesn't support VP9).

Quote from Goood

"sudo -E rpi-eeprom-config --edit" no work in Lebreelec

You are the root user so "sudo" is not required.