Posts by diederik

    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:

    I recently installed the Retrospect addon on my Rock64 running nightly-20220208-72b6d0d (RK3328.arm) which downloaded some (ChromeOS?) recovery image to get the widevine library which is needed to watch 'NPO start' (Dutch public broadcaster). But trying to watch something, it was buffering constantly. I SSH-ed into my kodi device and noticed 1 core was at 100% all the time. The stream being 540p x264, that didn't make sense.

    I found https://github.com/retrospect-add…ect/issues/1601 while I'm 99+% sure the title is incorrect it does describe the issue I had (and is in English). A similar Dutch issue suggest to revert to an older version of widevine which should fix the issue. But I only had one version.

    That first link points to an issue with inputstream.adaptive and in one of the comments a DL to 4.10.2252.5-linux-armv7.so was provided, but that is armhf, while rock64 runs aarch64/arm64, so that seemed useless for me. Then I did the following:

    Code
    kodi-rock64:~/.kodi/cdm # file libwidevinecdm.so 
    libwidevinecdm.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=d673f7acd89399ecffaeb3c9ea1545f0c932ba00, stripped

    So then I made a backup of that file, DL-ed the 4.10.2252.5-linux-armv7.so one and copied that onto libwidevinecdm.so and then a quick test indicated that the NPO Start stream worked perfectly :)

    But shouldn't I have gotten (initially and afterwards) a 64bit version of the widevine library?

    While my initial problem of getting an older version seems to be solved by DL-ing from a 'random' place, I still like to know if and how this can be done normally/properly.

    If the file with the dropouts is from a remote location (nfs), the first test to do is having the file locally. While GbE should be fast enough, when things don't work, verify all assumptions. I believe that True HD + Atmos requires a sustained high throughput and if there's any interruption, that can cause audio drops. With a normal file copy, it'll just slow down (temporary) and therefor take a (slight) bit longer. With audio, you'll get audio drops.

    Quote
    i have the drops with passthrough mode and also decoding to multi ch pcm. With multi ch pcm it is worse. So for me the hdmi connection to my onkyo av rz-830 seems to be okay and not the issue.

    You have (audio) problems in both cases, but in some cases it's worse. How does that lead to the conclusion that the hdmi connection is fine?

    I would actually suggest trying whether the problem is the same with a different hdmi cable. (verify your assumptions)

    I wonder how do you do this:

    do you do the download on the LE box only (no 2cd box involved) ?

    how do you get the correct download link for the new nightly ?

    I go to https://test.libreelec.tv/ and filter the list for 'rock64', right-click on the one entry that's still left and do 'Copy Link', then I switch to a terminal (tab) connected to my kodi device via SSH, change to ~/backup and do 'wget <paste-previously-copied-link>'.

    IOW all manual and from a 'normal' PC.

    I ran into a similar situation a while ago and since then I DL nightly images to ~/backup/ and copy it to ~/.update/ to apply a new nightly.

    IOW, I keep several old nightly builds which I 'know' are good around. Backing that/those up to another drive/PC would also be a good idea in case the storage medium in my kodi device gives problems.

    You can do that (too) until more nightly builds are kept, but even after that it may be useful to keep your own known-good copies around.

    Formatting the disc with UDF version 2.50 works:
    $ sudo mkudffs --utf8 --blocksize=2048 --media-type=bdr --udfrev=0x0250 --lvid=Backup2 --vid=Backup2 /dev/sr0

    After doing that, were you able to mount the disk then? I'm guessing 'yes' as you said it works, but better to verify then assume.

    If you then do the same command, but then explicitly use '2.60', would it fail like before or would that work?

    Another interesting test would be to only specify the required parameters, so it uses the default values for all others

    Why? It won't be the first time a Windows tool doesn't create things/disks according to spec/standard and while it may work on a or that specific Windows machine (possibly 'assisted' by that same disk creation tool), another tool working according to spec, may choke on it.

    The homepage of the 'udftools' package on Debian is https://github.com/pali/udftools and I'm guessing LE uses that too. You may find additional hints there (in issues f.e.).

    If you can reproduce the problem on a disk created on a Linux machine, that's also the (best) place to report it, so it can be fixed.

    personally I edit /storage/.kodi/usersdata/sources.xml as the format it simple and typing smb://user:pass@SERVER/SHARE is easier on a keyboad via SSH than using a remote in the GUI.

    Oh man, that is so much easier :D I also just discovered the 'System Tools' addon which gave me vim \o/

    I have one video source which I use the most, but it's listed last in 'Videos > Media sources'. I edited the sources.xml and put the source I use most often at the top of the list, but that didn't seem to affect the sorting.
    Is there a way to (manually) change the sorting? If so, how?

    I've had some mixed results so far. Several times it didn't see the soundcard I wanted it to see, so I've now blacklisted the module 'snd_soc_rockchip_spdif' on soundserver as I don't (plan to) use it anyway. Also when manually unloading and (re-)loading the pulseaudio modules, it sometimes worked and sometimes it didn't. I could not find any pattern in it.
    OTOH, when my PC is on, it always sees the soundcards from that machine and I can select them in Settings > System > Audio.

    I've just created one of my very first systemd unit file and rebooted my kodi device and it seems to work (now) :)

    But if someone who's more knowledgeable in this area could take a look and suggest improvements, I'd appreciate that.

    After creating that file, I put it in ~/.config/system.d/pulse-network-audio.service and then did "systemctl daemon-reload" and "systemctl enable pulse-network-audio.service" (and disabled my ~/.config/autostart.sh which did the things that are now in ExecStart)

    The RPi is still on, the HDD attached to it is still spinning and I can access it as a NAS; but the only way I can get it to output display is by switching it off and back on ... It's just really frustrating to have to go scrabbling around behind the TV stand to switch it off & on again, not to mention the fact that it's not good for the SD card or the HDD to be switched off like this, but I can't find another way to resolve the issue.

    If you have enabled SSH, you can SSH into it and give a 'reboot' command.
    If you have 'Kore' on your phone, you should be able to reboot it through that as well.
    Not a proper solution to your problem, but better then pulling the plug.