Posts by chewitt

    My assumption is: The wyse needs some special shutdown no one knows about :D So there is no machine-specific shutdown procedure in LibreElec's kernel. I also assume that it's safe, but yet annoying, to power it down manually when the "Power Down" message appears.

    I found a couple of other references, but no solution:

    201965 – Power off / Shutdown hangs after echoing "Reboot: Power down" on DELL / WYSE Thin Client - AMD G-T56N

    GitHub - sanrab/Dell-Wyse-Thin-Client-Dx0D-5010: Linux install on Dell Wyse Thin Client Dx0D/5010
    Linux install on Dell Wyse Thin Client Dx0D/5010. Contribute to sanrab/Dell-Wyse-Thin-Client-Dx0D-5010 development by creating an account on GitHub.
    github.com

    I'd start with ensuring the device has the latest/last available BIOS/firmware update installed, and seeing what if-anything can be configured in the BIOS for the device with respect to power states.

    These devices do claim to support SUSE Linux (SLES 12) so any attempt to triage the process might require comparisons with that OS to see what state certain registers or things are being set to (or not) and upstream linux. How to diagnose power-state issues are way beyond my sphere of knowledge though. I did attempt to Google ACPI and references to Wyse but drew blanks. NB: Userspace shutdown scripts are not the problem or solution here. The issue (and any resolution) will be in lower-level code.

    If you see that message on-screen (which is generated by our kernel init script) the system booted. It may have some issue with video drivers or similar that prevents further output on-screen, but the rest of the OS is probably running in the background and if you force SSH on in boot params (add "ssh" to them) you should be able to login and poke around to share logs etc. so we have some into to work with. In the absence of any further info the only real answer is /shrug

    Windows share browsing has been broken since Windows 95 but in 99% of cases the ability to browse the network and mount a share has nothing to do with your ability to manually mount a share. TL/DR; the sooner you master the basic skill of manual mounting, the sooner you stop searching for a solution to something Microsoft has failed to make work for 25+ years.

    According to this https://github.com/xbmc/xbmc/pull/18741 it won't be fixed until Omega 21.0 Alpha 1, if I understand correctly.

    There isn't a nice way to (re)add the feature, so that PR is more of a hack to generate discussion than a serious proposal for code merge. As such it's not been merged and it's been moved K20 to K21, and at some future point it'll probably be punted down the road to Kodi 'M' too.

    Shouldn't an S905 handle HEVC completely in HW, I've finally finished setting up my Odroid C2 with the profiles and libraries and now when I went to test playback some stuff played perfectly with seeking and everything, some didn't play at all and some were stuttery. As far as I know my Odroid should handle HEVC at 4K/30 HW, at least that's what it says on the manual, so why am I getting these issues?

    The point being made was that MPEG2 media can be (or could be, if we disabled the broken MPEG2 hardware decoder) be decoded in SW.

    S905 does indeed have hardware HEVC decoding capabilities, but with some bugs (seeking is one of them) that remain unresolved pending the attentions of someone with coding skills taking an interest in fixing them (so not me). The H264 hardware decoder is generally in a much better state, and everything else (apart from MPEG1/2) .. e.g. MPEG4 is software decoded.

    The vendor kernel still runs best on Amlogic hardware, but that's outside the scope of this thread or upstream kernel images.

    I've been trying since last week to reboot my odroid but it always just shuts down, tho I should mention that the LE logo does appear and looks like its trying to start when it shuts off. No matter what method I use whether it's from SSH (reboot or kodi-send --action="restart") or the gui it's always the same. And to turn my device back on i have to unplug and replug it, sometimes several times which is starting to worry me.

    When the board boots (u-boot first, then kernel, then userspace) the kernel init script loads the LE boot splash. When Kodi starts, it renders to a full screen 'Window' and this overwrites/obscures the splash. If you manually stop Kodi the Window goes away to reveal the underlying layer with the splash again. If a shutdown is slow enough you'll see the same; Kodi stops and the splash is revealed again. If the screen then goes black, e.g. TV loses the HDMI signal and then you see the splash again; it suggests the board has rebooted. If you don't see the black loss of signal and the LE splash remains on-screen it suggests the board is never shutting down. If you only see the black/lost-signal it suggests the board shuts down and either never reboots; or it reboots and hangs before the kernel init runs.

    I haven't boot tested a C2 for a while, but it was working fine last time I did, and nothing has really changed. For kicks you can try this on a clean SD card: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz (removing all add-ons and such from scope is never a bad thing). If you see the same and have an old shitty SD card (no fancy fast speeds) lying around that's also worth testing to rule out issues with voltage changes not happening (not resetting the card to a state where it can be seen on boot). Testing a clean card also proves it's not just an old/bad/dying card (they don't last forever) - the same applies to emmc modules.

    The best way to really understand what's happening is connecting a UART cable as this will clearly show the early stages of boot (u-boot and kernel) and where things get stuck or not.

    And (as has already been said) whatever the issue is, it is guaranteed to have nothing to do with CONFIG_MESON_DRM in the kernel.