Posts by kurai

    heh - I decided to live dangerously and do an in-place 9.2->10 upgrade, just to see what would happen (after a full disk-image backup, natch ;) )


    I won't say it was ... painless ... but I've managed to get pretty much everything working as I like.

    Fixing/replacing the addons/plugins that were broken in the Python 2->3 transition was the longest part, but it was more a case of step repetition than anything mind bendingly difficult, once I got rid of the defunct dependency packages and updated some repos to their Matrix versions.


    The most "technical" parts were probably tracking down why some of my remote button customisations were broken - turns out that Kodi has finally gotten rid of the XBMC. prefix from the various ActivateWindow() functions (A quick search/replace operation in keymap.xml and all was good again.) and tweaking my favourite skin (Ronie's Transparency) to work as it hasn't been updated for Matrix.


    Really the only thing that doesn't work as I'd like is the TV-NextAired plugin - the Python 3 version works very differently than it's Python 2 predecessor and has a very different UI layout.


    To be honest I'm rather surprised that most of my years worth of endless tweaks and modifications and customisations to OS/Kodi/Skin/addons/settings carried over as well as they did. 8)


    I'm an old school user since XBMC on original XBox and have a pretty good idea of how things work under the hood, so your mileage may vary.

    I *certainly* wouldn't recommend doing this unless you are like me and just want to experiment - if in ANY DOUBT whatsoever follow chewitt and the rest of the LE team's advice, and do a clean install :*

    Have you already applied the setting to force the use of the older "legacy" Nvidia drivers, instead of "latest" ?

    (The later ones cause hangs and crashes upon sleep/resume cycle with older Nvidia video hardware)


    Both sets of Nvidia drivers are included in the LibreELEC install - the udev rule simply activates the legacy ones in preference to latest.

    Having a htpc with a GT520 myself, going into suspend freezes my machine.


    Try enforcing the legacy Nvidia video driver

    Code
    wget http://chewitt.libreelec.tv/96-nvidia.rules -O /storage/.config/udev.rules.d/96-nvidia.rules


    It has solved the suspend problem on my machine, and so far I haven't noticed any video performance problems. The actual problem is hard to tackle so far.

    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. :(

    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? /shrug

    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.)

    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.

    Code
    journalctl |grep ssh

    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. /shrug

    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. 8)


    (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)