Posts by diederik

  • Seeking login/access details

    Quote from ADKM

    From memory there was some issue at setup and things were done 'differently". Possibly a script of some kind was needed, but impossible to say for sure.

    After reading the links I've been able to change directories and see various files including mountshares.sh and startup.log. I've not found any autostart.sh.

    Permanent mount of Samba share fails may be of use and especially the link referenced there:

    https://wiki.libreelec.tv/how-to/mount_network_share

    Quote

    Are these text files. Is there a way to view them ?

    In Unix/Linux, everything is a file (unless it is a process).

    You can view files in a number of ways: cat, less (quit with 'q') or nano (=text editor)

  • Netflix

    Look through the log files in .kodi/temp/ to see if you can find any hint as to why it is failing.

    Generally, if you want help, you should provide WAY more info (in English) so people have something to go on. Right now it only says "it doesn't work", which is not useful for others to start with.

    Info like 'used hardware'/'LE version' should be considered the bare minimum.

    When errors occur, run pastekodi and share the URL that is printed which generally provides a LOT of information for people to go on.

    HTH

  • shell script to get the latest nightly (old)

    Quote from JoeAverage

    but sorry I guess I never will support those platforms.

    That's quite alright :)

    Quote

    why ?

    look into nightly download directory and compare with your os-release.

    on the first you'll see a lot of "sub-variants" (?, the part between git tag and .img.gz) for .eg. 3328, but no such sub-variants in your os-release.

    Knowing that it's not automatically applicable to all devices, is useful to know.

    I don't know a way to differentiate those sub-variants programmatically either.

    Quote

    and I feel I'm getting old, earlier ~18 h nonstop wasn't a theme. When I have bitten in a task it goes nonstop until tiredness isn't "fixable" with further caffeine and lastely realizing that I repeat the same programming mistake over and over again ... :D

    One of the best and often underappreciated 'debugging' techniques, is taking a break/nap or plainly a good nights sleep ;)

  • shell script to get the latest nightly (old)

    Not requested, but I run LE on a Pine64 Rock64 device:

    which may still help in learning about variations in /etc/os-release outputs

  • Just dug out old PC based Media Centre - will it run?

    Quote from Garzie

    does anyone know if i can plug that in after installing libreelec - or will it not search for and install drivers for that if plugged in after initial install

    On every boot LE (well probably the kernel) searches for and tries to initialize the devices it finds. Including new ones.

    If your (new) soundcard/device is supported by the upstream* Linux kernel, then it should just work.

    *) Upstream means in Linus Torvalds (git) repository. Several devices claim Linux support, but that's only with a highly modified custom kernel. Then it becomes much more questionable whether it will 'just' work on LE.

  • shell script to get the latest nightly (old)

    Quote from JoeAverage

    3. I nowhere check the needed disk space to download, copy the ~/backup and to handle the uncompression the update installer does.

    for 3.:

    I guess I need ~2.5 - 3x the image size as required disk space (1x update, 1-2x the uncompressed update, 1x copy in backup).

    What I do is DL it to ~/backups/ and then copy it to ~/.update/. And then reboot it.

    I do NOT do any decompression myself (but on reboot I assume it does get decompressed (in RAM?)). I assume that the reboot+update also removes the copy from ~/.update/.

    Quote

    therefore I need to fetch the image size from download server *before* I start downloading at all.

    I don't know if it already exist, but a (small) downloadable file with the filename + size + checksum (to verify whether the DL succeeded) seems very useful and shouldn't be too hard. That's something LE needs to provide, but could become part of the build process?

    Quote

    I'm completely undecided to put the new script online again ..., until at least I get a fix for the disk space part ...

    Have you thought about putting it in a(n online) git repo? (and putting a link to that in your script thread)

    Code should be put under version control (git) and it allows others to create Pull (or Merge) Requests, one can use git's tool to see what changed between version, etc.

    If you put care into your git commit messages, that can help (future) you and others to understand why certain changes have been made. That also helps you in your learning process

  • shell script to get the latest nightly (old)

    Quote from JoeAverage

    I've fixed the most mistakes I made via shellcheck, but not all.

    That's a judgment you ofc have to make yourself, but I normally assume that shellcheck is right and I'm not.

    Quote

    the fixed version of the script is exchanged now in comment #5 to not blow up this thread.

    Why not in #1? That's the easiest to find. If you want to keep it in #5, then link to it in #1?

    Quote

    * just a bad habit or in my fingers using rm with "-r".

    I'm not a fan of using -f 'by default' either, but it's easier to make the case where that is warranted

    Quote

    I couldn't find something "potentially catastrophic";

    I delete at three points in the script, always bundled with a true of the prev. command, e.g. cd ~/.update && rm -f *;

    that should be fine, cause if nothing is to update there shouldn't be anything in ~/.update (left from me).

    Oh, you'd be surprised in all the ways a 'seemingly' simple script can fail. See Bugs in Hello World to see how the simplest program 'of all times' can fail ;)

    Over time I've learned to create the ThisShouldNeverHappenException class (in Java) and you'd be surprised how many times that got triggered :-O

    I don't know about busybox's rm applet, but the 'standard' rm program added a check that rm -rf wasn't executed from '/' and errors out (unless you add an explicit parameter to override that) even though the user specified '-f' (force)! Too many people ran that command 'accidentally' from the wrong dir and thereby completely wiping out their system. Unrecoverable.

    It's good that you thought about defensive programming :thumbup:

    Quote

    also I work in /tmp what is a) cleaned via reboot and b) I delete what I downloaded there

    * 'mktemp'

    there is a variant using tmpfile with a process number at the end in bash (in sh too ?)

    currently can't remember hwo it extactly called ...

    You use wildcard ('*') instead of explicitly named file(s) (or directories), so you may be using/removing more then you expect(ed). If other programs/addons use /tmp too, you may be breaking their operations.

    I used mktemp as that is available on LE, but IIRC (on my Debian Sid box) its use is actually deprecated. The goal is to create a temporary file (or directory) yourself, work with that file/directory and when done, clean/remove that file/directory (explicitly, thus no use of wildcards). Which function is used to create to temporary file/directory, is not important.

    Quote

    * script runs on LE here with #!/bin/bash

    Yep and that works.

    But if you check the script with tools like shellcheck, then it verifies it against the actual bash program, which isn't what's used on LE. Changing the shebang to #!/bin/dash (the default non-interactive shell on Debian (based?) systems) may be useful too as it may reveal issues when it would be run under that shell. Even though you have no intention to actually run it against dash, it could improve the quality of your script nonetheless.

    Quote

    * functions

    I usually do use them esp. when I need to run parts of the script more then once

    That's indeed the most common reason to use functions.

    Another reason is to make the code better structured and (thereby) readable. I think that's a worthwhile goal in itself, but it also makes it easier for others to review the script

    When code is in the 'global namespace' it gets run no matter what, including after an error occurred which is probably not what you want. When code is put into functions, that code is only executed when explicitly called.

    And that call can be guarded/surrounded by various test/if-statements.

    If your code is structured like this:

    Code
    setup_working_dir() {}
check_for_update() {}
download_update() {}
verify_downloaded_update() {}
install_update() {}
cleanup_working_dir() {}

    Then the code in the 'global namespace' would then just be calling those functions, guarded by checks.

    Very readable and code only gets executed when all the preconditions are met.

    There are (ofc) multiple ways to do that, but this (structure) is what I prefer. YMMV.

    Quote

    extend the script with more hardware types ... [like RPi]

    You may want to take into account that people could be using a 512MB or 1GB SD card on which downloads fail because of -ENOSPACE ;)

    HTH

  • shell script to get the latest nightly (old)

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

  • Update URL/channel for nightly builds

    Quote from mfizz

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

  • Recommendation for a passively cooled solution

    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.

  • LibreELEC on Firestick?

    Quote from pope3909

    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.

    Quote from pope3909

    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.

  • Audio and Video out of sync on certain videos

    Quote from renegadeandy

    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.

    Quote from renegadeandy

    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.

  • Can I remotely access the files on the attached hard drive in Libreelec?

    Quote from dimo777

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

  • [OT] Rock64: display alignment issue outside LE

    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.

  • WRITE ACCESS ON HDD

    Quote from JoeAverage

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