Posts by kurai

    Great news CvH

    The ticker was usually the way I heard about significant updates/developments first, since I would often miss inbuilt updater notifications and I am otherwise not checking the site/forums all that often ... unless I encounter an issue or just randomly remember to check in, once in a while.


    I am very much of the "if it Just Works[tm]" ... leave it alone until it doesn't ... mindset :P


    There are downsides to this - I recently made a query in the Bug Report section about something and it turned out the root cause was me leaving in an old advancedsettings.xml entry that hasn't been relevant/useful for *at least* 3 hardware platform updates that I've gone through :blush:

    Aaaaah - looks like I had a brain-lock. I was making the assumption the windowing init was happening at a point before any addons were loaded, so they wouldn't be relevant at that stage of startup.


    Turns out that's completely wrong as the clean/vanilla instance chewitt suggests does indeed work properly.

    Looks like it's time for me to go on a cruft-hunt to find out what part of the years worth of accumulated tinkering has misbehaved :)

    I've been using using nightlies since I got this new hardware in October as, at the time, the kernel in the mainline releases didn't support Intel Jasper Lake fully.

    I've been updating the nightly version to latest every week or two since then - never been able to get the GBM versions to init.


    As someone else has confirmed it *should* work, I'll go ahead and collect debug logs etc when I get home.

    Hi all.

    Before I waste everyone's time asking you to comb through debug logfiles & shell outputs, am I correct in thinking that the title hardware *should* work just fine with the standard Generic GBM nightly build ?


    For some reason it always stops at the "critical <general>: CApplication::CreateGUI - unable to init windowing system" entry and I have to use the Generic-Legacy nightly builds with X11 instead, which is a pain since I want to try out HDR.


    I've trawled through a great many of the existing posts and nearly all the potential pitfalls & issues have either already been fixed/integrated into later Nightly builds or don't apply to my specific hardware.

    Am I just being dim, and not finding something already known and/or obvious that prevents GBM working with my shiny new Odroid H3+ ?

    Resurrecting this old thread because I noticed it's still an issue while I was testing a Nightly build install.


    To be clear - it's not an issue with the build itself - it's a problem with this website and how it has implemented it's RSS feed and/or a quirk of the way the Kodi RSSReader deals with it.


    For whatever reason the inbuilt Kodi RSSReader ticker cannot parse this particular feed, even though it checks out fine on the W3C validator.

    Feed Validator Results: https://libreelec.tv/feed.xml


    I copied the XML to my local webserver and chopped out all the article entries, in case it was a parsing issue with one post, but even with just the barebones XML feed structure it still failed to parse it.

    Feed display appears to be b0rked again.

    It fetches and seems to look properly formatted in a web browser, but won't display in LE/Kodi RSS ticker.

    (For both https://libreelec.tv/feed and https://libreelec.tv/feed.xml)

    Other feeds work, and I've changed nothing related on my end, so it looks to be a libreelec.tv issue

    Code
    DEBUG <general>: Thread RSSReader start, auto delete: false
    DEBUG <general>: CurlFile::Open(0x7efdeb34e900) https://libreelec.tv/feed.xml
    DEBUG <general>: easy_acquire - Created session to https://libreelec.tv
    DEBUG <general>: Got rss feed: https://libreelec.tv/feed.xml
    DEBUG <general>: RSS feed encoding: UTF-8
    DEBUG <general>: Thread RSSReader 139629037942336 terminating

    A successful feed has the following DEBUG entry after the encoding line:-

    Code
    DEBUG <general>: Parsed rss feed: https://kodi.tv/rss.xml

    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