Posts by kurai

In my old LE 8.x setup I used a modified "boot once to other OS" script packaged into a Kodi addon to enable me to run the addon from GUI and select which OS to run on next boot.

The relevant core of it was thus e.g.:

#!/bin/bash

mount -o rw,remount /flash
extlinux -o "windows" /flash
reboot

... which would use the extlinux -o option to set a one-time flag to select a different boot entry from extlnux.conf (either Windows on another partition or PartitionMagic from a live squashFS) for next restart, then revert to default (LibreELEC) on subsequent restart.

In LE 9.0 this just generates a `not found` error since there isn't an extlinux binary anywhere in the search path.

So ... my questions are:-

1. Has the sylinux/extlinux implementation changed from LE8.x to 9.x and I'm just too dim to find it in GitHub commits ?
2. Or ... did I do something myself to install an extlinux executable some time back in the distant past that I've simply forgotten about, which I need to do again for the current LE build ?

If it's option 1, is there some slightly different way this desired "change boot option one time" functionality can work with the present syslinux executable ?

or

If it's option 2 then I'll leave you in peace and wander off to try and recreate whatever the hell it was I did in the past

Quote from h0m3b0y

- One button on my Harmony Ultimate remote started to act funny. It is the "Guide" button, which used to open context menu up until last update. After update it displayed an error about not having PVR backend. Keymap editor add-on solved this one.

I noticed this one myself when I briefly tried the Beta 2 to see if my hardware all worked properly.

The Guide button now opens...the Live TV guide page no matter where you are in Kodi.

Probably not a huge surprise, maybe even the more logical behaviour desired by most, since previously the button acted, as you note, as a context menu and a global Live TV Guide button had to be mapped manually in keymap.xml

Good to know that it's easily remedied in keymap as I want to keep the old context menu behaviour rather than spend forever messing around in the damned awkward Harmony software

For what it's worth the old issue of the `current` Nvidia driver in Generic build hanging the machine when entering suspend is also present in Leia v8.95.2 Beta (the workaround of forcing the ancient legacy driver still functions)

Issue thread here: - v8.0.0: Device crashes when entering suspended mode (nVidia driver issue)

From the sound of things it's an Nvidia binaries problem rather than any LibreELEC derived issue, but fingers crossed someone will take a look and see if there's any progress on the Nvidia end before the v9 goes final ?

For what it's worth - this is still an ongoing problem with the Nvidia driver included in the Leia v8.95.2 Beta build.

Quote from ApexDE

So, LibreElec 8.2.5 with new nvidia drivers is out. Anyone tested if freeze upon suspend is still happening?

The new Version has 390.42 drivers.

The LE8.25 update with Nvidia 390.42 continues to have the sleep/suspend hang issue.

The Legacy driver (bumped to v. 340.106 in the LE update) still does the sleep/resume operation properly.

Confirming that the suspend problem still exists with the Nvidia 384.90 driver contained in LibreELEC 8.2.0, on a machine with GeForce GT640.

Reverting to legacy 340.104

Aha ! Got it sorted.

The links you provided helped ... indirectly

A mention elsewhere reminded me that lsusb had a -t flag for "tree view", which gave a much more useable interpretation of the info, so I looked at that and saw that the host port for bus3-port2 *did* have a driver-provided wakeup setting.

Set wakeup disabled in that, and things are behaving as I wanted. (I lose the ability to wakeup via the wireless keyboard on that same "spur" as well, but that's not super critical, just nice to have. The IR remote is the important one)

Thanks for getting my brain moving in the right direction

Sure.

# lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 003: ID 8087:07dc Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver
Bus 003 Device 003: ID 2040:0265 Hauppauge 
Bus 003 Device 008: ID 046d:c150 Logitech, Inc. 
Bus 003 Device 009: ID 046d:0a1f Logitech, Inc. G930
Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 005: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver is the one I *definitely* need to keep available for wakeup.

Bus 003 Device 008: ID 046d:c150 Logitech, Inc. is another USB receiver for a wireless keyboard, different device from the G930 dongle below it.

Unfortunately that targets the entire USB hub, rather than a specific device.
I have a USB IR remote receiver that I *do* want to be able to resume with, so blanket turning off the USB hub doesn't really help

(Unless you are trying to tell me a way specifically target a sub-device, and I'm missing the point. If so, please clarify with enough detail that I can wrap my confused brain around it)

Hi all.

I'm running into trouble trying to disable wakeup from suspend when a particular USB device is plugged/unplugged.

I have a Logitech G930 wireless headset & I swap the USB transmitter dongle between my desktop PC & my LibreELEC HTPC as needed.
I'm trying to configure the power/wakeup settings on the LE HTPC so that (if it's in suspend mode) the system doesn't wakeup if the dongle is plugged in or removed.

I've read through many versions of people setting wakeup flags (mostly for IR remotes) via a number of different shell scripts via ./config/autostart.sh and/or shutdown.sh but I'm geting horribly lost trying to echo a "disabled" flag to the device's /power/wakeup register.
There seem to be multiple access paths to the dongle via /proc/acpi/wakeup, /sys/class & /sys/bus etc. & I'm having trouble knowing which is the more "correct" path to use and which will accept a write to ./power/wakeup

For reference, the details of the dongle device I'm trying to target:-

# lsusb |grep G930
Bus 003 Device 009: ID 046d:0a1f Logitech, Inc. G930




# grep 0a1f /sys/bus/usb/devices/*/idProduct
/sys/bus/usb/devices/3-2.2/idProduct:0a1f


# dmesg |grep G930
input: Logitech Logitech G930 Headset as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.2/3-2.2:1.3/0003:046D:0A1F.000C/input/input34
hid-generic 0003:046D:0A1F.000C: input,hiddev0,hidraw3: USB HID v1.01 Device [Logitech Logitech G930 Headset] on usb-0000:00:14.0-2.2/input3

So ... now I have the port & location of the device identified a couple of ways but there's no "wakeup" in the ./power dir of the various acesses routes, and I can't seem to find a way to create/write to it.

Can someone please help me out with what exactly I need to be doing ?

Cheers,
--
kurai

You aren't deleting the driver itself, just the instruction that tells LibreELEC to use the older ones instead of the newest.

i.e. Both drivers are installed in the system already - you don't need to touch them. Just add file 96-nvidia.rules which forces use of the legacy version. If the rule is not there LibreELEC goes back to uses the newer driver as usual.

Once there's an upgrade available that sorts the issue out install it, then simply delete file /storage/.config/udev.rules.d/96-nvidia.rules

When you reboot LibreELEC will then use the standard Nvidia driver that came with the upgrade.

Just wanted to drop in and give you guys a big thank you for getting this device working fully. (for my scenario, at least)

I'm using the LibreELEC-Generic.x86_64-8.0.0 build on a Zotac mini HTPC - ZBOX ID45 with Intel cpu/Nvidia gpu.

Previously I had a crappy old Afatech AF9013 based device - SD single DVB-T tuner.
Just replaced it with this device and its HD dual DVB-T2 tuners - rebooted HTPC, half a dozen clicks or so in TVHeadend web UI to enable the new tuners and remap channels and hey presto - everything is working fantastically.

Gotta love it when stuff like this Just Works™ first time - I was expecting *hours* of futzing around to get everything to behave, but the hours of work already put in by the LE code team made it all completely painless.

Sorry I haven't got any useful input to give you RPi guys - hope you get your solution sorted out soon

Quote from schrackin

Hey,

i have a different problem, but it is samba related too.
I would like to mount a samba share permanently, but i couldn't make it happen automatically at system startup.

I made a config file in "/storage/.config/system.d/", with the following content:
file name: cifs-nas.mount

<...>

Than i set to it with the following command:
systemctl enable cifs-nas.mount

But unfortunately the pi doesn't mount it at startup. It works with the manula mount:
mount -t cifs -o username=xxx,password=xxx //192.168.1.5/video/TV_Recordings /storage/recordings/nas

Could you please help me out, what can be the problem?

Display More

Inside the "/storage/.config/system.d/" dir make a sub-directory called "multi-user.target.wants"

Copy "cifs-nas.mount" into "./multi-user.target.wants" (or make a symlink to the main one in "./system.d/")
i.e. So it matches the [Install] WantedBy= section

The mount should now happen automatically.

Note: I set my system up similarly on OpenELEC ages ago, and it still works fine after migration to LibreELEC. Unfortunately I did it so long ago I can't really remember *why* the [Install] section and sub-dir were required, just that it "Automagically Worked[tm]" doing it that way. Frankly the whole systemd shennanigans just makes my head hurt whenever I try and fiddle with stuff like this