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 
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.
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
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
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 failedSo, 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/libI 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.
The code in the script:
(Which is a python script, idk if that matters)
Codeimport 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.
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
Codevideo=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 
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, strippedSo 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.