Posts by chewitt

Clock slew has no impact on startup other than the clock being slightly wrong. The journal on a Raspberry Pi (with no RTC) will show you a system that starts happily on 1st Jan 1970 until the network comes up and NTP drags the clock forwards 36 years.

The first delay of 15 seconds occurs because /dev/random is locked due to a lack of entropy. This usually stems from using simple HTPC hardware with no external peripherals or mechanical media which are the OS's main sources of entropy. LE7.0+ does some workarounds for storing and then recovering entropy on next boot that normally reduce the delay, but there's not much to do about that.

The second much larger delay looks to be related to /dev/sdb. I'd make an educated guess that this is a larger capacity (and/or slow speed) USB stick and the OS + hardware shutdown process is leaving the stick into an unclean state which triggers fsck on restart; the scan takes time to complete so you see a boot delay and because you already fsck'd the partitions a manual check after boot shows nothing as the issues caused were already resolved.

Install to a proper HDD/SSD and the longer delay issue probably goes away.

LE8.0 builds use the 340.xx nvidia driver whereas LE7.0 will be using the older 304.xx driver for that card - we see occasional reports of cards that work "better" (in non-specific terms) with the older driver. If you have some Linux skills or confidence it's possible to self-build LE8.0 with the older driver and test things. If the older driver works better it's not really a bug in LE, it's just that some older nvidia cards are quirky.

S3 mode works fine when the BIOS/hardware combination supports it (without bugs) and the user configured the BIOS correctly. Most issues are seen when the BIOS is buggy and when the "translated badly from Chinese" BIOS GUI confuses the user (PEBKAC) but we also see cases where hardware doesn't send/keep power to the special USB port during suspend properly (even when the BIOS is configured right) which ensures the receiver never sees the IR wake signals. So no idea what problem you have .. but that's a summary of where things normally break.

Ahh.. my bad, it's nvidia-xconfig that we include not nvidia-settings. The nvidia-settings code requires Qt and a load of other not-otherwise-needed stuff to run so it could be packaged up as an add-on, but this probably needs to be a user-community effort as I'm not sure any of the core devs will be too interested in the task. It might be worth seeing how nvidia-settings actually implements the LED status changes as it's probably just code wrapping to simplify setting of things via other means.

nvidia-led/nvidia-led.sh at master · Madh93/nvidia-led · GitHub

it's a shell script that sends commands to nvidia-settings. Just modify the path in line 4 (styles=) and it should run on LE without changes.

It's a very niche requirement so will not be something added into core images, but it could be done/packaged as an add-on.

mount -o remount,rw /flash
nano /flash/config.txt
<make changes and save the file>
mount -o remount,ro /flash

like that

Apart from historic experience with shitty firmware, PRAM (BIOS) batteries, and passing the observation that a 2009 machine is now ~7 years old and in the zone where things just randomly pack up with no explanation .. I've no idea. Perhaps try using rEFInd as the boot manager?

ProFTPd was added to the add-on repo for 7.90.009+ users last night.

make sure "play next video automatically" is disabled

Refresh the LE add-on repo and make sure the updated 8.1.xxx version of the client is installed as the 8.0.xxx version will not work on 009 due to SSL changes.

Mac hardware with firmware before ~2011 is normally a pain in the arse with Linux. Make sure the internal SSD is "blessed" correctly for boot and check dmesg for media/mounting issues with the internal drive.

You need to cross-compile the image (we don't call them ROM's) from sources with the driver module included. You might be able to copy things from another image if the source is using *exactly* the same kernel as you. Usually that's not the case.

If you want to run lots of extra services via containers you'll see delays in shutdown. If you want to avoid that, it's best to get a NAS and run them somewhere else. Make sense?

No difference.

script.moonlight was waiting on an upstream fix since the recent major repo and libCEC changes. It's in the repo now.

You're looking at a virtual read-only filesystem that is uncompressed from /flash/SYSTEM on boot. It cannot be changed. If you need to add something either self-compile an LE image with changes or Google and learn how to bind-mount things.

There are now two repo's; one for v7.90.001-008 and v7.90.009 onwards. If you refresh the add-on repo Kodi will pull down a newer version of the add-on that's compiled against the newer SSL version.