eselarm

No need to thank me in this case. You don't even read or understand or act upon it from the start; I mentioned essentially twice earlier what the problem is and now that I again opened that ssh log and you don't seem to understand how to handle ssh links. Is trivial for decades, you need to read docs or maybe ask an AI-bot, else forget about Linux and stay with Windows only.

AFAIR Windows uses other files/objects/regkeys when ssh admin/root I just remember it from other place on internet, test also with Linux only.

you cannot login as root via ssh using password, it is disabled by default for years already you need a normal user first or prepare the image/sd-card to use ssh keys/ids

in the root of the rootfs do: find . -name platform_install.sh find . -name u-boot-sunxi-with-spl.bin essentially construct correct dd arguments somethings else might be wrong though, so make sure you have a serial console/debug able with loglevel=7

The paste armbian URL displays nothing (anymore?) so without any (new) info from you, no-one can help you. AFAIR, 4K via HDMI connector is only recently available (on RK3588, not sure about RK3399), so make sure you can manage various combinations of U-Boot, kernel, rootfs. So sort of act like a developer, als make sure you have a serial console (debug) cable, else you cannot get any step further. Use a 26.2 based U-Boot and 6.19 rockchip64 kernel I would say, then see what happens.

If I understand you correctly: root via ssh is not allowed by default I usually setup (new) SBC's in a different way, but last time testing 2 of my boards with 26.2 minimal/IoT fresh image was via serial console, have not used ssh and certainly not putty. If no (serial) console, you might also have sme networking firewall issues somewhere in Windows or so, although would be vary rare. Have you setup a normal user first via (serial) console first?

You should also consider the bootloader (type and version), in principle you do not need the dtb- package as the dtb files are also in the kernel package (enough when doing own extlinux). U-Boot philosophy is to provide just enough so that the kernel/initrd/DTB can load and started. Audio is not part of that I think. LE certainly used other bootloader and as you already showed has more non-upstreamed patches. See my experience:

then this topic is not applicable

What hardware do you have? What exactly is in the M.2 slot?

What is in armbianEnv.txt then? Anyway you need to load and edit it such that you make sure loglevel=7 Then there will be more text after Starting kernel ... You also seem to have a power and/or reliability problem w.r.t. cables as characters are missing in your debug log text.

High chance this uses some proprietary hardware for 3.5mm audio jack. It has been like that for decades and you probably need to find some firmware blob somewhere maybe. I have also a similar situation, most part s of the computer work fine with Debian Trixie etc, but it took ages to get sound working and still buggy, endless beep or crash occasionally. If you are lucky is it maybe only a mute setting or so, use aumix etc to look what is going on. Not something Armbian specific I guess, but up to you to figure out. Then also mention various versions, what BIOS/UEFI version the computer is loaded with, what Armbian kernel and also specific image release (if it is an unmodified image writer based installation).

You should pipe the output from a serial console cable to another computer where you store it. Make sure kernel cmdline loglevel=7 AFAIR the OPI5+ can only use 5V as input supply power. Your 100W PSU might be a standard spec one so it does only deliver 3A at 5V. This might be a perfect 5.000V, but an extra cable in between will drop that a bit and the risk is then that short higher power drap will either make the 5V goo too low and/or the PSU will cut the power because more than 3A drawn during a short peak. You will need to look at powering first. Usually 5V only SBC's can be powered via other input then the USB-C input. You need to read the instruction for your OPI5+, and also OPi5, those might be different. OPI5+ and also OPi5 should transcode at more or less the same speed, large amount of memory does not really matter as it is just HW processing blocks doing the work in a rather limited memory space. You should do a manual CLI jellyfin-ffmpeg based transcode, see /var/log/jellyfin how commandline arguments for that specific video look like (and simplify it, output to 1 file instead of chunks m3u8). And or search this forum, I at least have posted examples for check/test earlier. You might also try to reproduce it with a publiclicy know video, look for big buck bunny test vids or so.

This is putting some sort of warning flag for myself. 'pretty sure', 'chatGPT', a Rockchip board v.s. Allwinner board.

OK, so the URL I posted is not correct. If those devices are there, your only option is to use dd with correct offsets on SPI/MTD or eMMC ( or SD-card) to write a U-Boot binary. An lsblk should show those devices, else maybe the armbian-install tool is likely correct with its error message.

see: https://radxa.com/products/network-computer/e25#techspec Only SD-card for this device, hence boot order is something fixed, just hardware. On software level it depends on how U-Boot it configured and compiled and on higher level, what partitions are found, can also be USB-stick, and what is on those partitions. Can be Armbian standard boot.scr or own extlinux or even EFI if you want. So minimum is SD-card with U-Boot on it, else nothing will happen unless maskROM is entered, see Radxa docs.