schwar3kat

You can't use the official Kodi ppa version of Kodi. It doesn't include k35xx acceleration or a working widevine cdm for arm64. Assuming that you are using amazingfate's ppa for Kodi and haven't updated Kodi from the Kodi official ppa, then updating or installing the inputstream.adaptive plugin from that ppa or from any Kodi repository will prompt you to update widevine. cdm, The widevine cdm update that is installed doesn't currently work with arm64 Linux. So most likely you have the wrong libwidevinecdm.so installed. At the bottom of my notes below, you can follow how to manually copy the right one, assuming that you have it installed in amazingfate's Chromium. If you have the wrong Kodi installed then remove it and remove the official ppa. If my notes are correct these are the steps to get Chromium widevine cdm and Kodi installed (use at your own risk): sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia sudo apt update sudo apt full-upgrade sudo apt install libwidevinecdm I might specifically have installed or reinstalled Chromium, but I don't have it in my notes. It may have done it automatically with the upgrade. Some DRM streamers check the Chromium user agent on arm64 and won't work unless they find a ChromeOs user agent. Create a launcher for DRM-Chromium with the correct user agent for widevine (or just launch it like this from the command line): chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS aarch64 15236.80.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.125 Safari/537.36" Check widevine DRM works in Chromium with https://bitmovin.com/demos/drm sudo apt install ubuntu-desktop kodi Start Kodi and install your plugins. Try to run one DRM video and when it errors, do an apt install for inputstream.adaptive as recommended by the error message. Install widevine cdm as prompted. This will create the directory structure for widevine and install the non-working version. Copy libwidevinecdm.so from /lib/chromium-browser/WidevineCdm/_platform_specific/linux_arm64/ to /home/{username}/.kodi/cdm/ Restart Kodi. If this doesn't work perhaps follow the thread where I had a similar issue: A useful resource that explains the issues. https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html

It turns out that the slyguy plugins for the NZ services replaced the widevinecdm.so with apparently the same version but it had a different size. I replaced it and it now works.

Thanks @amazingfate Yes that's a good blog. I've got both services working on Chromium. They must be similar to Netflix. They didn't like the user-agent and when I changed to the Chromebook user-agent, they worked. Hopefully Kodi will also be a simple fix.

Thanks @amazingfate that demo video works on my Chromium. So it looks like it is not a Widevine issue. I will do some more investigating.

Hi @amazingfate Does your ppa:liujianfeng1994/rockchip-multimedia repo widevinecdm still work? I'm running Armbian 23.08.0 Jammy with Linux 5.10.160-rk35xx on Opi5+ I installed your rockchip-multimedia-config, and kodi kodi-inputstream-adaptive libnss3 I'm trying to get some NZ streaming services to work on Kodi, but inputstream.adaptive errors with 'Unable to load widevine shared library (/home/kschwar3/.kodi/cdm/libwidevinecdm.so)'. The libwidevinecdm.so file from your repo exists in that location. The Chromium browser also fails on these streaming services. I tried reinstalling chromium-browser, libc-bin and libc6 from your repo.

Orangepi zero plus Images boot, network connection functions (iperf3). USB ports function. Orangepi R1 Images boot, both ethernet ports and wifi function as expected (iperf3).

PR submitted. https://github.com/armbian/build/pull/5231

Orangepi R1 Plus LTS (RK3328) - networking issue AR-1747. Caused by one of the network interface logical names changing from eth0 to end0. I can can submit a PR to fix this with a rename in /etc/udev/rules.d/70-rename-lan.rules which is already created from a hook in the board config file (to rename the other network interface). Already tested and works as expected on current and edge, Ubuntu and Debian. Before I take this route, I'm just wondering if anyone knows a reason for this happening that could possibly lead to a better fix? I didn't find anything obvious in the PR's.

- Orange Pi PC - Pine64 Images boot (xfce_desktop), network connection functions (iperf3). USB ports function, HDMI video and audio work.

I couldn't reproduce the problem, after deleting `cache/tools/oras`, even with CLEAN_LEVEL=debs ARTIFACT_IGNORE_CACHE=yes. I deleted the whole cache and was able to reproduce it. EDIT: deleting cache/tools/oras. does reproduce the error. Not sure why I didn't get the same result earlier. https://github.com/armbian/build/issues/4889

Thanks @schwar3kat ! This has been elusive, but its clear that when the tooling is 1st downloaded, the parsing fails. 2nd run the tooling is already there so doesn't fail. Will try to address! Do you want me to log a GitHub issue for this?

https://github.com/armbian/build/issues/4879

Hold off investigating for now. This might be my fault. I usually set global git username and user email. I think that I may only have set them locally on the master branch folder. I will retest when I get a chance. Edit: Tested. Damn, I messed up. Of course it can't do mbox without email address. Apologies for wasting your time.

@rpardini Next/main. Creating patches. When I create a patch with armbian/build master (deprecated) using CREATE_PATCHES=yes, I get a patch in the output/patch folder in mbox format. When I create a patch with armbian/build main using CREATE_PATCHES=yes ARTIFACT_IGNORE_CACHE=yes, I only get a diff file in the output/patch folder. Is this intentional, a bug, or have I perhaps not set something up? Can I get a mbox patch?

@rpardini My apologies for not testing much on next/main the last two weeks. (13+ hour workdays with two hour commute is a bit rough). New main branch. Error on first run. The build works on second run. Running on Linux Mint Vera (Jammy) without docker: $ git clone --depth 1 https://github.com/armbian/build Cloning into 'build'... remote: Enumerating objects: 8900, done. remote: Counting objects: 100% (8900/8900), done. remote: Compressing objects: 100% (5308/5308), done. remote: Total 8900 (delta 3651), reused 7386 (delta 3146), pack-reused 0 Receiving objects: 100% (8900/8900), 83.75 MiB | 5.65 MiB/s, done. Resolving deltas: 100% (3651/3651), done. Updating files: 100% (12015/12015), done. $ cd build $ ./compile.sh BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no CREATE_PATCHES=no COMPRESS_OUTPUTIMAGE=img ...... [\U0001f331] Getting ORAS manifest [ ORAS manifest from ghcr.io/armbian/cache-uboot/uboot-orangepi-r1plus-lts-current:2022.07-Se092-Pbb0c-B680b ] [\U0001f331] Downloading required [ ORAS tooling ] parse error: Invalid numeric literal at line 1, column 11 [\U0001f4a5] Error 4 occurred in SUBSHELL [ SUBSHELL at /mnt/data/build-armbian/armbian-main/build/lib/functions/general/oci-oras.sh:141 ] [\U0001f4a5] Error 4 occurred in main shell [ at /mnt/data/build-armbian/armbian-main/build/lib/functions/general/oci-oras.sh:141 oras_get_artifact_manifest() --> lib/functions/general/oci-oras.sh:141 is_artifact_available_in_remote_cache() --> lib/functions/artifacts/artifacts-obtain.sh:279 artifact_uboot_is_available_in_remote_cache() --> lib/functions/artifacts/artifact-uboot.sh:107 artifact_is_available_in_remote_cache() --> lib/functions/artifacts/artifacts-obtain.sh:24 do_with_logging() --> lib/functions/logging/section-logging.sh:72 obtain_complete_artifact() --> lib/functions/artifacts/artifacts-obtain.sh:169 build_artifact_for_image() --> lib/functions/artifacts/artifacts-obtain.sh:209 main_default_build_packages() --> lib/functions/main/build-packages.sh:49 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:4 do_with_default_build() --> lib/functions/main/default-build.sh:17 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:17 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:126 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:164 main() --> compile.sh:52 ] [\U0001f4a5] Cleaning up [ please wait for cleanups to finish ] Sorry vnc copy messed up the icons. Logs attached. log-build-fad6555a-d76c-4966-b374-91b1812b012a.log log-build-fad6555a-d76c-4966-b374-91b1812b012a.log.ans summary-build-fad6555a-d76c-4966-b374-91b1812b012a.md

Which manual are you using. My manual doesn't have anything about GPIOs on pg130. (orangepi_r1_plus_lts_rk3328_user manual_v1.4) Only ports A and D are exposed according to the manual image. Correction: GPIO C0 is exposed on pin 10, I just didn't spot it. Example: Pin 13 -- gpioNumber: 2, port: 'A', portNumber: 2

Hi gangclar, I assume that you mean OrangePi R1 Plus LTS ? (not LTS plus). This board is usually used as a router or firewall, so I don't think that the community has done much with GPIO. I don't use GPIO, and know very little about it. Page 5 of the user manual gives you the GPIO pin mapping on the board image. There are other things to take into account. Device tree mappings will almost certainly not exist, because only devices included by default are included in the default device tree. You will probably need to develop a specific device tree overlay for your application place it in the overlay directory, and select it in armbian-config or in the armbianEnv.txt boot file. https://docs.armbian.com/User-Guide_Allwinner_overlays/ (This is for allwinner. Rockchip is similar). Kat

Orangepizeroplus tested success: Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepizeroplus_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on ethernet and wifi ports simultaneously. 2 images listed on RC testing form (minimal build left off).

Orangepi-r1 tested success: Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepi-r1_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on both ethernet ports simultaneously. Wifi works. 2 images listed on RC testing form (minimal build left off).

Orangepi-r1plus-lts tested success: Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepi-r1plus-lts_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on both ports simultaneously. 2 images listed on RC testing form (minimal build left off).

Suggestion: allow more than two images per board in the RC testing form.

SD cards tend to get corrupted if they lose power in the middle of a write. It's is unlikely to be build related.

I was just looking into trying to set this up manually a couple of days ago, but life got in the way and I didn't take it very far. Just a fun idea to try out and maybe get a little more speed when stuff isn't cached.

Excellent... just making sure that the issue is on your radar. I noticed a distcc.sh in the compilation folder. I'm guessing/hoping that this will mean easy distributed compilation.

It's unlikely that anyone here will be able to help you with knowledge about a third party image. Your best option would be to ask on the forum of the maintainer of that image.