Posts by diederik

It works absolutely fine on my Rock64 (with LG TV), but I do run nightlies (from https://test.libreelec.tv/)

Yeeh

Looks like a LOT is happening lately and it also seems with increased velocity \o/

https://patchwork.kernel.org/project/linux-rockchip/list/ is rather interesting to follow

Quote from knaerzche

The missing driver for the display controller which is entirely new and adding it will be kind of a huge effort.

Is this that huge effort: https://patchwork.kernel.org/project/linux-…/?series=634531 ?

If so, then it seems we're getting close

Quote from nicozanf

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

Quote from lukeluke1979

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.

Quote from jojobro1

The code in the script:

(Which is a python script, idk if that matters)

Code

import os
os.system("echo pwm_100 > /dev/ttyUSB0")

Are you sure about redirecting it to '/dev/ttyUSB0'?
That is usually a serial console attached to USB (at least that's where I know it from).

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.

Quote from frakkin64

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.

Quote from ilmich

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

Thanks

Quote from frakkin64

There isn't one, this is why the user space on most ARM builds is still 32-bit.

Thanks

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:

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.

In RE: PulseAudio network sending (rock64) I described how I did it with a systemd unit file.

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'm currently working to integrate that patch into a (self-compiled) Debian kernel, but I'd really prefer it if it was integrated upstream, so that Debian would pick it up automatically and I can go back to using Debian's kernels again.

So if there's a way I can help with this, I'd be happy to

Quote from JoeAverage

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.

Is this supposed to be the way to customize the sorting?
If so, I can mark this thread as resolved. If not, I'd like to know the way it is supposed to work, assuming it is supported.