Posts by chewitt

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.

Thread renamed and moved to the Allwinner section. AFAIK we don't have support for H313 chipset yet, but I'll let others comment.

Argon cases have a bit of a reputation here, but forums inherently attract more people with problems than people without them, so I wouldn’t read too much into the comment.

The NAS device supports multiple users and access rights, so create a "kodi" user with read-only access to media and then relax and watch movies. In the rather unlikely event someone compromises your home network and obtains the insecure password; they can steal copies of your movies, but cannot do more. If that risk bothers you, disable Samba and SSH services and the insecure password cannot be accessed.

Quote from Dawcio232

What can i do?

Type "run" at the boot prompt to run from USB instead of installing LE to the internal drive.

I've not seen a specific success report, but LE12 runs great on RPi5 and since RPi5 uses the identical HAT spec as all Pi boards, it's not something I would expect issues from.