Posts by kurai

I have a ... kind of ... similar issue that I have had to work around - but with video as well as audio.

My setup is an Odroid H2 (Gemini Lake J4105 micro x86 system-on-a-board thing) connected to a Yamaha RX-V485 receiver connected to a Samsung RU7400 TV.

When I use my Logitech Harmony remote to power on all three devices at once the TV doesn't register any input from the Odroid.

The Odroid *is* up and running - I can SSH into it and see all the relevant Kodi processes and the kodi.log shows errors relating to no display device connected.

If I manually turn on TV/receiver *first* then the Odroid initialises video and audio fine.

The problem seems to be that the Intel HDMI signal only tries to negotiate an EDID handshake *once*, early, during it's boot or resume process and if the receiver and/or TV isn't yet ready it doesn't retry and stalls video/audio over HDMI until sleep/resumed or rebooted once more.

So ... as Da Flex says - it seems to be a timing issue.

The quick and dirty workaround I have set up is to either

• add a 1 second delay to the Odroid's startup trigger in the Harmony remote software, to give the receiver time to bring up it's passthrough signalling and the TV to enable it's HDMI inputs fully.
• or start a different video source device group first (e.g. FireTV Stick or MS Remote Display Adapter which are also plugged into receiver HDMIs) then use the Harmony remote to switch to the Kodi/Odroid "activity" - i.e. Harmony knows that the receiver/TV are already on, so just switches receiver inputs and starts the Odroid.

I don't know enough about the low level video output process chain to say whether its an integral problem with the Intel chipset hardware, or if its something that could be addressed in software via the Linux Intel video drivers or LibreELEC tools/processes.

Quote from trogggy

I can't see any advantage in having the LE boot partition on a windows pc - maybe it boots 10 seconds quicker is all.

It would certainly be a simpler solution - that or run Kodi as a native Windows application (Win32 or UWP flavour)

On the other hand Kamal may have a very particular reason for wanting LibreELEC dual boot and/or may not want to dig out and plug in a USB device every time he wants to use Kodi, or tie up a laptop USB port by leaving it permanently plugged in. Or some entirely different reason... Speed isn't always the primary motivation. Who knows?

Quote from Kamal

I don't know where the problem lies but i am pretty sure Linux/Unix OSes are pretty flexible to be multi booted with Win OSes.

To save you going down several of the many rabbit holes that get generated by the other "dual boot" threads ...

You have two main issues to contend with

1. Windows 10 installer is much more "grabby", in terms of the disk control it demands, than previous Windows versions so a lot of the older XP/Win7/Win8 info is now defunct.
2. The LibreELEC installer, from the "USB-SD Creator" tool, sidesteps the issues of the squillion different disk layouts and filesystems it might encounter by ignoring them all and demanding the whole target disk. (This is really the only sane approach - trying to make an installer simple enough for the vast majority of use cases *and* cope with the vast number of weirder edge cases would be a never ending struggle.)

So ... to work around these behaviours :-

1. As you did previously, run the LibreELEC installer to create the flash & storage partitions
2. In gparted resize storage to whatever you need then move both partitions to the end of the disk.
3. Still in gparted, create an NTFS partition in the free space at the front of the disk.
4. Execute/write the gparted changes to the HDD then shutdown.
5. Now run the Windows 10 installer. Instead of finding an unfamiliar disk layout and trying to re-partition it to suit its own preferences it should discover the premade NTFS partition and allow you to use that instead.

There you have a choice to make, depending what you want to have as your default behaviour when the laptop starts up ...

You may have to fiddle with a tool like BCDedit in Windows to add LibreELEC to the list of available options in the Windows boot menu, if you keep that as your primary bootloader.

You will need to add Windows to the extlinux.conf in /flash if you wish to keep *that* as your primary bootloader.

If you choose the latter (syslinux) option as primary then you will run into a problem every time there's a Windows Update major patch. The update will seem like its installing but then fail and roll it back after it reboots to complete the update - the Windows Update process ignores your existing bootloader setup and always assumes *it* has full control of the disk. In this case run gparted before starting the update and use the partition's flags setting to mark the Windows partition as boot, instead of the LibreELEC partition. Then start Windows, let the update install and reboot itself back to Windows. Once complete you can then run gparted once more to reset your LibreELEC partition flag back to boot as normal.

( N.B. You *can* mess around in the bowels of both Windows & LE installer configurations to alter the default disk management behaviours but you'll have to extract/edit/rebuild a bunch of large monolithic disk-image/filesystem files and its a huge pain in the fundament - on the whole its a lot more trouble than its worth for just a single install.)

Umm ... that depends. Did you reboot 3 hours ago ?

LibreELEC uses systemd which has a centralised journal for logging, rather than the traditional older /var/log/syslog method.

Query the journal with journalctl .

e.g.

journalctl |grep ssh

Quote from vpeter

Would not be easier to restart Kodi at 3AM every night? It is not a fix but still

Probably so, but where's the fun in that?

I now have a kind of morbid curiosity to see just how much kodi.bin can grow the heap before it all collapses.

Yeah - I've done similar ... cannibalized a 2nd 4GB RAM module from an old laptop that I almost never use, plus enabled an 8GB swapfile too.

It's totally not addressing the real problem, but until someone solves the issue at least there's 16GB of total space for the system to thrash around in. Should take it a fair while longer before it reaches the Out Of Memory crash-and-burn phase ... hopefully enough so that I have a reasonable chance of noticing when it's getting towards the danger zone and rebooting before it all goes flop.

Thanks for responding, but we're already quite a long way past that kind of thing.

I'm really looking for advice on how to extract information useful to the coders from a specially compiled debug build with special analysis tools, rather than the general options that are available with the standard release build.

A bit too basic to be useful, I'm afraid.

That only tells us that it's kodi.bin that's holding on to all the memory - not which subsection/component is at fault.

Running pmap against the process is not much more useful - it just shows all the missing RAM as being assigned to the general heap, not what put it there.

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 ?