Posts by kurai

For what it's worth I'm adding my report to this issue. I haven't yet found a definitive root cause/effect, despite it being an apparent issue since upgrading to Leia.

I first noticed it when Kodi crashed out hard, mangling various .xml config files that were being accessed at the time, giving rise to all sorts of weirdness upon reboot. Ended up having to do a restore of kodi settings from backup.

Subsequent investigation showed an ever increasing amount of memory use over time that never gets freed up. My usage pattern of sleep/resume to activate/deactivate the machine as required, instead of doing a hard power-down/cold-boot, means I'm effectively running one very long Kodi uptime session just split up over many `powered-on` time periods so the ongoing memory leak behaviour becomes very apparent.

I've been poking around here and Kodi main forum off and on again fairly regularly looking for things that might be relevant, but no silver bullets yet.

I can reproduce the issue quickly by hammering on the Youtube & Twitch.tv plugins - skipping around constantly and causing chunks of streamed video data to be loaded/reloaded into memory in an erratic pattern and seemingly never cleaned up once no longer required. It's not a 1:1 relationship between bytesize of video download and memory consumed, so I'm not sure exactly what data it is that's kept hanging around in RAM.

The common denominator between the two plugins is inputstream.adaptive so I thought I'd found a smoking gun, but sadly not since the problem also happens with `regular` video viewing ... just at a slower rate of memory leakage.

Under the hood the `web streaming` plugins operate by effectively playing lots of small individual downloaded chunks of, say, mp4 video consecutively to give the appearance of playing one large monolithic local mp4 file. e.g one "1GB total" stream stream really consists of 250 4MB videos strung together.

However - you can also provoke memory leakage by stopping and starting lots of locally stored video - tested by scripting the stop/start playing/jumping/seeking of a several hundred single mp4/mkv/ts files from my local hard disk and NAS sources. Lo and behold the memory leak exhibited itself again, albeit at a much slower rate of accumulation.

Unfortunately I'm pretty stuck now, because this kind of behind the scenes memory allocation/garbage-cleanup doesn't show up in Kod logs (even at debug level) - you'd need to attach the processes to a proper debugger environment to diagnose effectively, which is way beyond my level of competence

Hardware: Zotac MiniPC with Intel Core i3-3227U CPU, Nvidia GT640 GPU, 4GB RAM.

Software: LibreELEC 9.0.1 / Kodi 18.1 (Leia)

Yeah - that must have been what I did before, back in the dim and distant past.

Maybe I had stored the extlinux binary somewhere that got replaced/wiped by the LE9.0 upgrade. *shrug*

Anyway - it's all working now and problem solved after I installed the extlinux binary I extracted from a Debian package.

(There was a bit of puzzlement when I couldn't get the binary from the official Syslinux Project download hosted at kernel.org to run ... till I realised that binary was built against 32bit libraries - hence the trip to Debian to grab their pre-compiled 64bit .deb version)

The syslinux executable uses the -o option for a different purpose.

Quote

5. EXTLINUX has "boot-once" support. The boot-once information is stored in an on-disk datastructure, part of ldlinux.sys, called the "Auxillary Data Vector". The Auxilliary Data Vector is also available to c32 modules that want to store small amounts of information.

To set the boot-once information:

Code

extlinux -o 'command' /boot/extlinux

where "command" is any command you could enter at the Syslinux command line, preferably a label. The boot-once information will be executed on the next boot and then erased.

Quote

2. SYSLINUX

For older versions (deprecated):

-o	Specify the byte offset of the filesystem image in the target "device". The offset option is applicable only when the target device is a disk image file.

There *is* a "--once=... Execute a command once upon boot" flag for syslinux but I can't seem to work out the syntax of how to utilise it to achieve the same result

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