Posts by diederik

    Couple of suggestions:

    • don't use the '-r' option with 'rm' as you don't need it and if there's a bug in your script, potentially catastrophic
    • Use https://www.shellcheck.net/ (or the similarly named tool from your Linux distro if you have it) to check your script for errors/warnings and fix them. BEST TOOL EVAR!
      You may want to change the first line to '#!/bin/sh' as otherwise shellcheck will assume you use actual bash, which isn't included in LE.
    • Use 'mktemp' to create a temporary file(name), store that in a variable (I'll use 'TMP_DL_FILE')
    • use 'wget ${DOWNLOAD_URL} -O ${TMP_DL_FILE} to store 'index.html' as ${TMP_DL_FILE}
    • process ${TMP_DL_FILE} as you now used 'index.html'
    • when done with it, do "rm -f ${TMP_DL_FILE}"
    • Using, and after use cleaning up, your own file doesn't interfere with a potentially existing file with the same name. 'index.html' is far more common then what 'mktemp' produces
    • 'Advanced' tip: try to put the various (distinct) functionality in their own function ('check_for_updates', 'download_update', etc) (so things aren't in the 'global namespace')

    Trivial question perhaps, is there an easy way to see what commits have been done since the previous nightly on github?

    At https://github.com/LibreELEC/LibreELEC.tv/commits/master you can see the (new) commits and on the 'right side' you'll see a 7 character string which is the abbreviated commit ID (first 7 chars of it; if you hover over it or click on it, you'll see the full commit ID).

    For the Rock64, the latest (as of right now) is: LibreELEC-RK3328.arm-11.0-nightly-20220609-5cf5d46-rock64.img.gz (which is 0 bytes which isn't 'supposed' to happen)

    After '11.0-nightly-<date>' you see 5cf5d46 which is that same 7 char string, ie commit ID, you can look up on GitHub.

    The previous one is: LibreELEC-RK3328.arm-11.0-nightly-20220608-9d4c846-rock64.img.gz so the commits between 9d4c846 and 5cf5d46 is what has changed (essentially).

    I use a Pine64's Rock64 with the aluminum case (you do need that for proper cooling!) and I can (even) play 4k HDR streams. All passively cooled.

    I would recommend their Quartz64 instead though. It might be a bit 'rough around the edges' right now as its software support is still getting upstreamed (into Linus' kernel), but that's progressing quite quickly.

    The HW is much newer and with a smaller production process and therefor runs much cooler then the Rock64.

    I just bought a $90 PI ZERO 2W on eBay and a heatsink to slap on it and will throw on the 9.2.6 image.

    Feel free to sell me a reasonably priced CM4... I only need ... a front end to my TrueNAS file server (for my 1080p TV) so I don't exactly need a super computer.

    Did you know that RPi's aren't the only devices on the planet?

    For $35 (Pine64 Rock64 2GB) + $7 (5V3A PSU) + $13 (Premium Aluminum Casing) + $25 (32GB eMMC module) = $80 you can easily play 1080p files (even 4k).

    That's just one option (and not necessarily the best); there are others.

    Could this simply be trying to watch 1080P videos on a Raspberry pi 2 is not really going to work?

    You could try if it works with LE 9.2.x as I think that it has a special implementation, which is not and will not be available with 10.x.y.
    Search on this forum to see if and how and with what constraints it could be possible.

    I don't see why this is an issue on kodi - where I can play the same files on a mac or a windows PC without doing anything and the audio and video is in sync perfectly (clearly this isn't a video file based issue, more something on the method of playback)

    The most likely explanation is that a mac or windows PC has FAR better/faster hardware then the RPi 2, which is a slow/underpowered device.

    The command I use is : ssh xxx.xxx.xx.x(my ip). A password is required and I enter a libreelec, but it doesn't work.

    You first need to have enabled SSH access, which is an option during initial setup.
    You can also do it via Settings -> LibreELEC -> Services.

    If you've done that, then you likely need to specify that you want to connect to your LibreELEC device as 'root' user by doing "ssh [email protected]" (=your IP address) and then give the password you set up in 'Services'.

    I'm assuming my issue is Off Topic as LibreELEC (nightly) works brilliantly on my Rock64 8) If it's deemed inappropriate, feel free to close/delete this thread.

    I have 2 Rock64 devices, both connected via HDMI cable to my AVR (Pioneer SC-1224) which in turn is connected via HDMI cable to my 4k LG TV.

    One Rock64 runs LE and it correctly identifies my AVR (as seen in Settings - System - Audio) and in Setting - System - Display, Resolution is 3840x2160p, Refresh rate is 60.00 and GUI resolution limit is 1080. If I remove the 'quiet' keyword from the kernel command line, I see that all the boot messages are nicely lined up.

    Another Rock64 runs Debian Testing/Bookworm and when using a Debian/stock kernel, then the left (8?) chars of the boot messages aren't visible. When starting a GUI, I'm still missing the left part. So I build a patched Debian (5.15) kernel which consists of patches taken from https://github.com/LibreELEC/Libr…s/linux/default. When I use that to boot up, all the boot messages are properly lined up, just like with LE :)

    When I then start a GUI (I've mostly tested it with sway (wayland), but also tried it with Xorg) all is well as well ... in 4k resolution. But the Rock64 doesn't have the (memory?) bandwidth to properly support that resolution and I also don't need it; 1080p is absolutely fine (for f.e. ncmpc). But when I switch resolution to 1080p, the output is shifted again. Think of like holding a piece of paper over the screen and then move it up and to the left, so I'm missing a part of the display output both on the left and the top.

    Switching to any other resolution causes the output to stop entirely.

    I'm assuming this is an upstream bug, which I'd like to report, but I have no idea in which component the bug is and therefor I don't know which upstream to contact.

    As you do have it working and with your patches I already made an improvement, I'm hoping you can tell me where (most likely) the bug is located.

    Thanks in advance and sorry if this is/was inappropriate.

    *I* would backup the files from the disk and would format it

    And not use F2FS. It's (now) even questionable for flash storage media (as they now have intelligent controllers build-in).

    Using ext4 is likely best, but then Windows won't be able to read it. If that's important, then NTFS is probably your next best option.

    Code
    [2022/04/05 21:24:43:3497] E: lws_create_context: failed to load evlib_uv
    [2022/04/05 21:24:43:3498] E: libwebsockets context creation failed

    So, I think there is a library missing. Running the full binary (statically linked) from ttyd repository works fine. Under

    Code
    /storage/.kodi/addons/service.ttyd/lib

    I have : libjson-c.so.5 , libuv.so.1 and libwebsockets.so.19

    My guess would be 'libev.so.4' as 'libev4' and 'libuv1' are dependencies of 'libwebsockets*' on Debian Sid

    Through the KODI GUI I installed the MPD plugin and activated SSH.

    Then I disabled KODI to auto start

    I'm confused. You run a KODI plugin without KODI? How does that work then?

    By looking at LE, I've managed to improve/enable audio for Rock64 (RK3328) on Debian('s kernel), so that I could run mpd. But recently sound broke ... again. (and also have a related issue, which I may post about on this forum)

    My LE device (another Rock64) continues to run flawlessly, so maybe I could use an entirely different approach.

    I have no experience with the youtube app, but youtube provides its videos in various formats. If you don't specify a specific format, then youtube will choose one for you and that may be the wrong one for your device.

    What you described sounds like youtube chose the wrong one for you and if you got 4k VC-1 format, but your device doesn't support that in hardware, then it decodes it in software on the CPU ... which may not be fast enough and then you'd get the symptoms you described.

    Rockchip might me something worth looking at, not super familiar with those boards, but I believe a lot of it is mainline supported.

    I can confirm that Rockchip (community, including LE) does amazing work with upstreaming/mainlining support for its devices and is one of the main reasons I'm interested in them.

    I have a Rock64 and I'm quite impressed with what LE manages to make it do, including 4k HDR x264/x265 support (and possibly also vp9). It does have a heating/thermal issue though, but after buying the aluminum case, that issue was resolved.

    I would recommend to take a serious look at Pine64's Quartz64 Model-B (See Quartz64 section at https://www.pine64.org/2022/03/15/mar…he-quartzpro64/) as it has better hardware and runs much cooler due to 22nm build process. It seems like LE doesn't have an image for it yet, though. Keeping an eye on https://wiki.pine64.org/wiki/Quartz64_Development should be helpful.

    The benefit of F2FS is nowadays (also) rather dubious and could even be harmful as the controllers inside the various flash media have gotten much better. In 'the old days' they were quite dumb and F2FS added (some) intelligence to them, but that intelligence is now present in the (HW) controllers. They have much better info and control of the storage media then the generic F2FS ever could.

    The potentially harmful part is in that 2 parties trying to do the same/similar thing can actually work against each other.

    do you have a 4k tv ?!?! green screen usually indicates a resolution not supported by the driver.

    try to edit the extlinux / extlinux.conf file present in the fat partition of the sd card by adding

    Code
    video=HDMI-A-1:1280x720

    Earlier today I read this post and just now I booted into my self-compiled kernel (Debian + some of LE patches) ... and got a green screen on my Rock64 (RK3328). What a coincidence :D

    Thanks :thumbup: