@MMGen Thank you. But if you recreate the partitions, why would it matter? The new gpt partition will overwrite/ignore the mbr stuff... I'm just trying to understand here. I actually had that problem with missing backup table, but fixed it with rewriting the tables with gdisk. But I don't recreate the partition in that situation, because when I do recreate the partition the problem with missing backup table did not happen, that's why I'm confused. But I will do some testing if not copying the first 32k will actually fix that issue (or rather, if I dd /dev/zero to clear it), even though it sounds very strange to me because the backup table on gpt is on the LAST blocks, only for mbr/hybrid are they on the first.

@bedna: Actually, my previous answer was incorrect. That area is not empty: it contains the Protective MBR, GPT partition header and GPT partition table, and we don’t want to copy those for the following reasons: a) There’s no reason to do so, since we create the partitions later; b) If we did, we’d end up with a corrupted partition table anyway unless we copied the backup header and tables too. That’s why we skip this area and begin writing at 0x8000 (32k), which is where the Armbian bootloader begins. If you’re just making backups, there’s no reason not to copy all the data, however. Different goals, different methods.

I've made some progress in debugging the mpv error... I introduced some additional debug display instructions into the mpv source code, so I could see what was actually happening. And here is the new log: [vd] Codec list: [vd] hevc - HEVC (High Efficiency Video Coding) [vd] hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder [vd] hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper [vd] Opening decoder hevc [vd] Looking at hwdec hevc_rkmpp-rkmpp... ctx->hwdec_devs = 0xffff64347e20 [vo/gpu] Loading hwdec drivers for format: 'drm_prime' [vo/gpu] Loading hwdec driver 'drmprime' [vo/gpu/drmprime] Using EGL dmabuf interop via GL_EXT_EGL_image_storage [vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128 [vo/gpu/drmprime] ADDING DRMPRIME DEVICE [vo/gpu/drmprime] hw->devs=0xffff64347e20 [vo/gpu/drmprime] av_device_ref=0xffff64348860 ADD: ctx=0xffff6434af60 hw_imgfmt=1057 type=8 av_device_ref=0xffff64348860 num_hwctxs=1 [vo/gpu/drmprime] DEVICE ADDED [vo/gpu] Loading hwdec driver 'drmprime-overlay' [vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display. [vo/gpu] Loading failed. Searching: hw_imgfmt=1057 device_type=12 (rkmpp) num_hwctxs=1 ENTRY 0: ctx=0xffff6434af60 av_device_ref=0xffff64348860 hw_imgfmt=1057 type=8 (drm) hw_ctx = (nil) [vd] Could not create device. [vd] Using software decoding. [vd] Detected 8 logical cores. [vd] Requesting 9 threads for decoding. [vd] Selected decoder: hevc - HEVC (High Efficiency Video Coding) [vd] DR parameter change to 1920x1088 yuv420p align=64 [vd] Allocating new (host-cached) DR image... [vo/gpu] DR path suspected slow/uncached, disabling. [vd] ...failed.. [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vd] Using container aspect ratio. [vo/gpu] reconfig to 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vo/gpu/wayland] Reconfiguring! [vo/gpu] max content size: 1024x600 [vo/gpu] monitor size: 1024x600 The result says exactly this: VO (drmprime): add a DRM type device Decoder (rkmpp): look for an RKMPP type device => can't find it => hw_ctx = NULL => Could not create device => decoding software More precisely: ADD: hw_imgfmt = 1057 type = DRM and immediately after: Searching: hw_imgfmt = 1057 device_type = RKMPP So the problem is not: The MPP, FFmpeg, mpv does not create hwdec_devs, drmprime driver The problem is that the two components are not talking about the same type of device. Actually, that tells me something else very important: hwdec_drmprime.c from mpv was written for decoders using: Vape, V4L2, other DRM backends It creates AVHWDeviceType = DRM, instead, FFmpeg's hevc_rkmpp is a new decoder, which expects AVHWDeviceType = RKMPP. These two pieces of code were not made for each other. That also explains why the decoder exists... I have hevc_rkmpp, but mpv knows absolutely nothing about RKMPP. mpv only knows: drmprime and drmprime creates a DRM device. My logical conclusion is that the official MPV is not suitable for the rkmpp hardware (it doesn't know about its existence). So what to do ? Where do I get a suitable MPV ?

I tried installing it to the internal eMMC memory, and now it won't boot. It looks like it'll have to stay on the SD card—or is there a way to install it?

Hi all, After a recent update bumped the current kernel to the 6.18 series, the rear 3.5mm jack on my NanoPC-T6 LTS stopped playing any sound. I'm connecting it to an external amplifier that worked fine before the update. What I see on 6.18 (6.18.35-current-rockchip64): The audio card (rt5616) still shows up in aplay -l and playback commands run without errors, but no sound comes out. Volume levels and mute aren't the issue — I checked those. What fixed it: downgrading via armbian-config to linux-image-current-rockchip64=25.11.2 (kernel 6.12.58). With 6.12 the audio works perfectly again. So 6.12 works and 6.18 doesn't, at least on my board. Is anyone else seeing this on a T6 / T6 LTS with the 6.18 current kernel? Happy to share any logs or run commands if it helps to narrow it down. Thanks!