Posts by myxal

    Cheers, I'm using LE 9.2.6 on Raspberry Pi 3.

    A recent rollout of IPv6 had me shuffle a few network settings:

    • Pi and other devices are still pointed to a local dnsmasq instance running on v4 (via DHCPv4) and v6 (via DHCPv6)
    • Upstream DNS was swapped to nextdns for filtering and analytics - this is where I noticed the issue.
    • Devices get self assigned GUA and ULA - the prefixes advertised have lifetimes I got from ISP router's defaults 10800/14400 and 3600/7200, respectively. The expected addresses are seen assigned on the pi (via SSH -> ip -6 addr sh, I couldn't find v6 info in Kodi/LE GUI)

    After noticing the huge amount of queries to I checked my local resolver's logs and saw that LE on the Pi is querying this every 3 minutes (all the time, since the pi isn't turned off) - and it checks both via IPv4, and IPv6 (the ULA) simultaneously.

    I checked connman logs (journalctl - u connman.service) and kodi logs (.../temp/kodi.log) and didn't see anything that would match the periodicity or occurrences.

    Any idea where else to look?

    Edit: Hmm, I enabled CONNMAN_WEB_DEBUG for the service and the loaded URL, is returning HTTP 502 Bad Gateway on IPv4, and is completely silent on IPv6. I guess that's the problem.

    It was the only error message in the kodi log. Is there another way to get more useful logs? Perhaps the v4l2 test utility from the bootlin guys?

    almost no manufacturer implements the software changes needed to play such files.

    What does that mean? By "software", do you mean the default media player? (No loss there..)

    You can run Android from a micro-sd card or removable emmc storage, I'm also trying to make Android/LibreELEC boot from USB & NVME storage on the RockPi 4.

    Suppose I'd like to dual-boot Android TV and (legacy) LibreELEC images. Is running both off of 1 storage device possible/viable? The Radxa wiki provides an example image (ubuntu+android), for an older SBC that had onboard NAND. but I don't see any info how to prepare it, or if the process is applicable to the Rock Pi4, and it's quite old at this point.

    mo123 Thanks. Totally forgot Android TV was an option for the SBCs as well. Will probably go for the Rock Pi, the Edge is nearly double the price here, and has lower specs.

    ^ 10-bit H264 is not an official standard so although it's widely used by anime fans there is no hardware decode support for it on any ARM device that I have come accross. Most anime fans gravitate towards an Intel NUC with a CPU capable of decoding the content in software.

    Thanks for the tip, though I'll take my chances. User reports suggest that it is indeed working, at least on the Rockchip kernel. Just took a look at the current scene, and it seems most have migrated to H265, so that might become a strong requirement after all.

    Hi all. Seeing as my shelved A10-based TV box will probably be of little use due to the low specs, I'm wondering if getting a TV box or SBC with a Rockchip SoC (specifically, the RK3399) would make sense now that mainline support is landing, and the recent announcement of new SoCs should be a signal for incoming sales of current/old stock.

    • How usable are the boards now/ what's missing (compared to, say, an x86 PC with well-suported hardware components)? (Rockchip's status matrix hasn't beed updated in 8 months... Is anyone tracking the mainline development of Rockchip as well as the sunxi community is tracking theirs?)
    • Does any tick all "boxes" listed below? If so, which would you recommend?

    My expected use of the box/SBC:

    • used as a TV box - controllable using a remote (if not shipped with a decent one, then preferably usable with generic IR (nec encoding), and audio through HDMI

    • Playing movies stored on NAS (SMB v2+, Wired Ethernet, preferably gigabit)

    • content:

    • "typical" H264 (up to 1080p BD quality; alternatively 1080p60 from youtube and the like) ~50%
    • mpeg4 (xvid,divx) ~10%
    • "Hi10P H264" ~35%
    • various sw-decodable SD-or-lower content (flv) ~5%
    • H265 - Don't see myself caring about, and (knowingly) getting H265 and/or 4K content any time soon. Unknowingly (through services forcing H265) - I'm currently not subscribed to anything, but am considering Nebula and Curiosity Stream; can't see anyone dropping H264 altogether, not even Youtube. About the only forced-H265 source I can possibly see considering is DVB-T2, (probably streamed into the network from another box), where the resolution will most likely never go beyond 1080i. If the chip can sw-decode such H265 stream, possibly while overclocked, that's good enough.

    • Anime, and most movies in non-native language -> (rich) subtitles, and lots of 'em. I think this places additional requirements on the quality/capability of the DRM driver, as it isn't just scaling+scanning out a single plane with the video, but also combining the video plane (may not match display resolution) with display-resolution OSD/subtitle plane at all times. Ie. if the system starts stuttering the playing video when showing OSD, it's no good - just playing the video smoothly with nothing else showing isn't good enough (there's probably a workaround, where the subtitles are rendered into the video plane, but that limits their resolution and on-screen position, so.. "No, thanks.")

    • Plex client (server should be capable of transcoding to h264 if needed).

    • (maybe) hosting Kodi DB for all home Kodi clients - a non-roaming, passively-cooled TV box is IMHO best suited for the task. Weeks-long uptimes and low tolerance for kernel glitches affecting the DB operation (networking, storage) expected. Probably needs 4 GB of RAM?

    • (maybe) WiFi AP (assuming the driver supports it) - the other AP at home doesn't quite reach one room, having an extra AP for better coverage would be nice.

    • Case (for SBC): sufficient cooling required - mustn't overheat/throttle under sustained load (à la Raspberry Pi). Shouldn't need to disassemble the case to access sd-card, if the SBC has on-board IR the case mustn't block it (duh).

    I took a look at a few SBCs:

    - Rock Pi 4: I don't understand the point of putting RK3399 in a Raspberry form factor. RK3399 needs a beefy heatsink, and cools on the bottom, so it's not like I can use any Raspberry cases anyway, I think. Lots of USB ports are nice. No mention of infrared. Can buy some of the models locally for an OK price. Not a fan of having connectors on multiple/adjacent sides, with even the minimal setup (power, Ethernet, HDMI) having cables sticking out of 2 of them.

    - RockPro64 Can't seem to find a decent case for it. Doesn't come with infrared.

    - Rock960: Has a nice metal case, a bit bare-bones but probably sufficient aside from the missing IR.

    Anyway, this seems to be the relevant error from kodi.log:

    2020-02-16 14:33:36.338 T:612   DEBUG: EGL Debugging:
                                                Error: EGL_BAD_ALLOC
                                                Command: eglCreateImageKHR
                                                Type: EGL_DEBUG_MSG_CRITICAL_KHR
                                                Message: dri2_create_image_khr_texture
    2020-02-16 14:33:36.338 T:612   ERROR: CEGLImage::CreateImage - failed to import buffer into EGL image: 12291

    jernej, are you familiar with how the GPU/system memory split is set up? From top, I see 480 MiB is available to the system, leaving just 32 MiB to GPU. This is much smaller than the ~200 MB allocation for GPU I saw in the stock Android.

    EDIT: Never mind, read up on how the "memory split" works in mainline. CMA's reserved 96MiB should be good, I think.

    You can always press "o" during playback to check if video is HW decoded or not.

    Right. "ff-mpeg4 (SW)" Damn, I thought mpeg4 was supported. Still strange that it doesn't use all available CPU:

    Is there any file with "kodi_crashlog" in same folder than normal kodi log?

    Nope, just kodi.old.log

    Maybe ffmpeg decode mpeg4 only on one core.

    This is a single-core system, I believe.

    add "ignore_loglevel" to kernel command line

    Will do. However I did get to dmesg output through ssh1, and there is more - dmesg_video.log

    EDIT: Yep, with ignore_loglevel the above output is shown on UART, but that happens during startup, before I attempt to play the video. Nothing new shows up in dmesg when I try playing a video.

    1 - ssh a2k 'dmesg' > /tmp/dmesg.log # With ssh/config containing UserName, IdentityFile, HostName and LE host having the pubkey in .ssh/authorized_keys

    mpeg4 is slow because there is no HW acceleration and it's decoded by CPU.

    That is odd then, because the OSD reports CPU significantly below 100% when stuttering like that, typically 40-60%

    I would need at least Kodi debug log and dmesg output.

    Kodi log: kodi.log

    dmesg: It seems that after Kodi starts up, the output on UART stops. Is that intended (where should I get it, then)?

    Does that prevent to be able to navigate menu and start video playback?

    Videos - mpeg4 plays at low fps (< 10 fps) and visible glitches, but at least they keep up with intended playback speed and don't consume all CPU. H264 doesn't play, and makes OSD go bonkers. (see below)

    Can you make a photo of that or short video?



    Oh, and there's an exception on shutdown:

    Oh, and by the way - what would be the way to set a permanent MAC address on the built-in ethernet NIC?

    Thanks, that boots into Kodi :)

    I am seeing a strange shimmer in the Kodi GUI (starts as soon as the splash screen shows up). It's as if some lines would render the contents of the previous line, instead of its own pixels.

    Trying to get the MELE A1000 box up and running, the kernel panics when trying to start the early userspace: mybuild_klog.txt

    [    3.301289] Run /init as init process
    [    3.307300] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
    [    3.314970] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 ]---

    I built the image myself, from jernej 's mele branch (PROJECT=Allwinner ARCH=arm DEVICE=A20 UBOOT_SYSTEM=mele make image). I'm unable to confirm that the KERNEL file contains a valid initramfs. I have found initramfs.cpio among the build artefacts, and that does look like it should work:

    • /bin/sh links to /usr/bin/busybox
    • busybox present, compiled for 32bit ARM EABI5
    • /init script present

    Any suggestions how to troubleshoot this, or what else I should check?

    • Building whole image with DEBUG=yes?
    • Adding set -x at the very beginning of init and rebuilding an image with this change?

    I'm new to building LibreELEC, what would I need to clean to make either of these changes apply in the resulting image?

    Well.. there are ~15 CPIO signatures in there :D

    While there seems to be something compressed in there, trying to extract it results in a lot of cpio errors, not finding "member names" (file names?)

    Checked the init script, and will try booting with debugging in the kcmd, hopefully will get more clues what's wrong. If not, I reckon the intramfs is somehow broken.