Settings/System/Input - Official Kodi Wiki
I forget whether it's under peripherals or driver settings, but one has the CEC settings .. just diable CEC support and the messages will stop.
Settings/System/Input - Official Kodi Wiki
I forget whether it's under peripherals or driver settings, but one has the CEC settings .. just diable CEC support and the messages will stop.
Note that the LE settings add-on backup will NOT backup existing recordings and such, only the addons/config etc. - but after you've got a working system again you can put the old SD card in a USB card reader, connect to the RPi, and transfer the files locally.
Creating /storage/.please_resize_me will result in the current partition being removed and a new one being created on the next boot. This is a destructive action that will nuke the current contents of /storage, so you probably don't want to do that.
Instead, take a backup using the LE settings add-on, move it somewhere safe, then clean install the same LE version you're currently running to the new SD card (which will use the full space of the card) then use the settings add-on to restore the backup onto the new card.
Doing a backup/restore is normally a lot faster than card cloning methods because the amount of data 'on the card' is normally only a fraction of the large capacity of the card; whereas cloning requires you to bit-for-bit copy the card including all the unused space.
Power Off is simple to handle because there's a functioning OS that can be (re)programmed to deal with whatever IR or RF keyboard codes the remote sends to run a shutdown. Power On requires something to always be powered and listening/waiting for a specific IR code; that wakes the internal power circuits to (re)start the device. And yes, about 95%+ of all hardware used for LE (all RPis, all NUCs, etc.) do not have that little extra circuit that remains powered to switch things on again. RPi devices can be modified with an add-on board that hosts an IR receiver and a small power circuit that's always-on and provides board power via the GPIO pins. There are IR/remote add-on "lids" for some NUC devices too; but rather expensive.
TL/DR; If the Beelink box has an IR wake function? you might be able to get a programmable IR remote and configure it to wake the box. I'm quite sure the Minix remote is not programmable though, so even if it does have one you're not going to make that combo work.
It's probably in /storage/.kodi/userdata/guisettings.xml ? (not guaranteed - Just a hunch)
No, it is old, the one I already had on my PC: Release 0.73.
Please update it to something current and try again..
Is the Minix remote (re)programmable? (to send a specific wake code) .. and does the Beelink box have a power-on/wake IR code?
Recent version of PuTTY?
so i tried the latest "LibreELEC-Generic.x86_64-11.0-devel-20220807005106-45816fd.img" build....
what am i missing?
Well, for starters the "latest" image you're using is from August, so I'd start with using an actual latest nightly, e.g. (from yesterday):
Amazon: https://github.com/Sandmann79/xbmc/releases/tag/Repository
Netflix: https://github.com/CastagnaIT/rep…gnait/tree/kodi
Install the repo add-ons, then install the respective add-ons from their repos. This way you'll receive updates when the authors publish them.
I use an Apple Airport Express WiFi basestation in Wireless Bridge mode for development as it means I can just connect an Ethernet cable and whatever board I'm playing with gets an IP address without having to muck about with WiFi drivers or configuring a connection. The last one I purchased (admittedly a couple of years ago) was about $20. It's not a blistering fast wireless connection, but it's "fast enough" for streaming moderate bitrate content for LE box/board testing and means I don't need to run a cable through three walls.
TL/DR; any bridge device, or any router that can be configured as a bridge, is what you need.
An S905 can almost handle 1080p HEVC in software so MPEG2 at 720p/1080i should be do-able. It would still be nicer to have proper hardware decoding.. but that needs someone to take an interest in the vdec code. MPEG2 isn't a complex driver, and it's likely broken due to a few small changes due to general V4L2 evolution since it was first written, but we're approaching three years since someone last seriously looked at the code and it appears nobody (who can code) cares enough to look.
If you're using the Slice remote, turn CEC off in Kodi settings (CEC is what will be waking the TV)
Is there progress on regression in MPEG2 hardware acceleration (S912 SoC's) ? Or perhaps, can you add separate switch for turning MPEG2 acceleration ON/OFF ?
One of the HK forum regulars started to look at the MEPG2 code, but then stopped, and that was a year ago. It's probably easiest to just drop support for MPEG1/2 in the driver. This will force FFMpeg to decode in software. As MPEG1/2 media is almost always SD it's not challenging to handle in software - as much as it would be nice to use hardware decoding.
The problem I suspect appears when in uenv.ini you force ssh.
Random suggestion .. use Notepad++ to edit the file, not Notepad or Wordpad - if you're a Windows user?
So far no change on the intention to support VNC, right?
We'd like to support it, but it requires some non-trivial coding to be done by someone other than us. I wouldn't expect to see anything in the near to mid-term future.
Dec 08 22:01:19.029867 LibreELEC systemd-tmpfiles[372]: Failed to create directory or subvolume "/root", ignoring: Read-only file system
Dec 08 22:01:19.030097 LibreELEC systemd-tmpfiles[372]: Failed to open path '/root', ignoring: No such file or directory
Dec 08 22:01:19.042294 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.042863 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.043498 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.045806 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.046319 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.047311 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
Dec 08 22:01:19.048826 LibreELEC systemd-tmpfiles[372]: Detected unsafe path transition /storage (owned by 1023) → /storage/.cache (owned by root) during canonicalization of /storage/.cache.
ekerose ^ this makes me wonder if examining the SD card in another OS has borked ownership of /storage. I have a hunch sshd is preventing the creation of keys belonging to root (user 0) in folders owned by another user (1023, who doesn't exist in LE).