Posts by kurai

Well, that was an ... adventure

I recompiled an LE 9.02 image (Generic x86_64) with debug options on plus valgrind.

Unfortunately it results in a running state that's so slow it is pretty much unusable navigating GUI, let alone when trying to replicate regular usage behaviour by watching videos/streams etc.

Also ... valgrind stopped reporting errors after the first 1000 - which it reached before all the various Kodi startup operations & plugins had finished initialising. At that point (what would be about 30 seconds into a regular Kodi startup session) it had already generated a 6MB logfile.

Does anyone have any advice about a saner way to go about this and/or how to interpret the valgrind logfile to derive usable information ?

Yep - saw that but at the time I looked at it, it didn't seem a promising lead since it seemed to be specific to VAAPI, which is not a factor in my setup with VDPAU.

I was hoping there might be some more useful reporting tools tucked away in the release packaged build of LE, but I guess I'll have to construct a build/compile environment with the development toolchain & valgrind and see if I can muddle my way through to any meaningful result

Hi all.

TL;DR - How can I *properly* diagnose a persistent memory usage issue beyond the very basic info that normal debug.logs supply.

I've been having an annoying and persistent issue with RAM usage in LE9.x/Kodi18.x that's proving very hard to nail down.

(On a mini-HTPC with Intel CPU & Nvidia GPU, 4GB RAM)

After a day or two of uptime I can easily reach 3GB of used RAM, and if I let it get much further the machine will reliably crash, often trashing any open files such as guisettings.xml which means having to do tedious clean up/restore-from-backup work to recover from.

Use case: The mini-HTPC is attached to rear of TV on the VESA mount & controlled via IR remote, so I usually turn it off and on with suspend-to-ram rather than full poweroff/cold-boot, which would require reaching round the back of the TV to power it back on each time. This means that it's effective uptime can get very long, since it's really one long session with periodic STR interruptions, therefore any issues with poor memory handling over long sessions are more apparent as they don't get masked/hidden by frequent reboots.

About the only vague conclusions I have after much investigation & trial/error is that it's likely something to do with not properly clearing buffered video segments after they are no longer needed.

This is exaggerated with extensive use of Youtube & Twitch streams, and jumping around/seeking a lot, but is also apparent with locally stored content such as regular MP4/MKV video, or TS files from TVHeadend recordings, albeit to a lesser degree.

What technical tools & procedures can I use to give meaningful technical information & diagnoses to the coding team that go beyond "give us a debug.log" ... which doesn't contain enough information on the underlying processes to usefully investigate further. ?

Cheers,

--

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.