defcom5-rockchip

I just built and troubleshot kernel:rk-6.1-rkr7.2 So I asked Claude as my thoughts are your desktop environment being the difference. Claude's reply Hi, We run GNOME (gnome-bluetooth) on our RK3588 image, not XFCE + Blueman, so I can't reproduce this directly. One detail in your post stands out, though: the copy that works is started with "export DISPLAY=:0", i.e. from SSH or a serial console, outside the desktop session. The copy that hangs is started by the tray applet inside the XFCE session. That difference matters for polkit. Blueman does some operations through its privileged helper (org.blueman.Mechanism), which asks polkit first. For a process in a local desktop session, polkit typically answers "ask the user" and waits for an authentication agent to show a password dialog. If no agent is running in the XFCE session, that call just waits, and the window looks frozen. For a process started from SSH/serial, polkit usually refuses immediately, Blueman handles the refusal, and the window works. That would match "manual start works, every start from the icon hangs". We saw the same session-dependent polkit behaviour on our own image this week (with rtkit/PipeWire, not Blueman). Things worth checking: 1. Is an authentication agent running in the XFCE session? pgrep -a polkit If you only see polkitd (no polkit-gnome-authentication-agent-1, xfce-polkit, lxpolkit...), that is the first suspect. 2. Where exactly is the frozen window stuck? Blueman is Python, so: sudo py-spy dump --pid $(pgrep -f blueman-manager) (py-spy is available via pip). A pending D-Bus call to org.blueman.Mechanism or polkit would confirm it. 3. Compare the environment of the frozen instance with a working one: tr '\0' '\n' < /proc/$(pgrep -f blueman-manager)/environ | grep -E 'DISPLAY|DBUS|XAUTH|XDG_SESSION' A D-Bus-activated instance without DISPLAY or with the wrong session bus is the other common cause of this kind of hang. 4. Or run the applet with debug output from a terminal inside the desktop: killall blueman-applet; blueman-applet --loglevel debug then click the icon and see where it stops. If the agent is missing, installing one (for example policykit-1-gnome on Ubuntu 24.04) and making sure it starts in the XFCE session (Session and Startup -> Application Autostart) should fix it. Disclosure: I used an AI assistant (Claude) to analyse your report and draft this reply. The polkit behaviour it's based on is something we measured on our own image; your Blueman case itself I haven't reproduced.

Yes, a good desktop distro. That is the right frame, and today's evidence lines up behind it. Flicker-free browsing at 4K, hardware video in both browsers to the limit of the blob, one audio server, Bluetooth that heals itself, and a kernel we ride instead of own. Gaming goes to Phreak, 4K120 stays an experiment until the link holds. Plaid gets to be good at being a desktop. Nobody on a rockchip got this Some of it, genuinely. The Cypress coexistence values were confirmed as a first in a Rockchip distro by CNX. Firefox with hardware WebRender on the Mali blob did not exist before this week, and the two shims that make it work are small enough that others will copy them. 4K120 over FRL on the vendor kernel with two patches is verified on hardware, even if it is not yet safe to ship. And the flicker story now has a root cause split in two, where the whole RK3588 community had a rumor about Chromium. Some of it is standing on Armbian's shoulders, and that is worth saying out loud when it goes public, because it is also what makes it maintainable. When Plaid is stable, those four are the forum post and the follow-up pitch to Jean-Luc.

IN Simple Terms : The screen flicker in the browser on the older Orange Pi build was never the browser's fault. It was the part of the system that draws the picture on the screen, and half of it is fixed with a one-line setting we already tested in August. The other half needs swapping out the graphics driver, which we proved works on the new build this week. Written for: WiiM support or the WiiM community forum, for the report file named below. Everything else in this message is for you. Case closed, with the fix persistent on the box and the proof filed. The answer The ten seconds were never Chrome's audio and never silence. A small bluez bridge called mpris-proxy, which Armbian's image enables for every user and the 2.0.x Ubuntu image never ran, forwards Chrome's media-session state to the speaker as Bluetooth remote-control messages. YouTube flips that state at every ad boundary, the Pi sends the WiiM "STOPPED" then "PLAYING" half a second apart, and the WiiM mutes on STOPPED and takes ten seconds to un-mute regardless. mpv has no media-session interface, so it was always instant. Proof: the decoded radio capture shows those messages at every boundary. Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man. Ruled out by measurement, so PC Claude does not chase them: silence gaps (a 1.3 s zero gap caused nothing, dither changed nothing), packet gaps (none), stream teardown (none), Chrome's audio path (meter showed sound within half a second). What changed on the box mpris-proxy disabled for all users, plus a preset file so it stays off. Dither is back off. All loggers stopped, the temporary askpass file removed. Cost of the fix: the WiiM's own play/pause buttons no longer control Chrome, and it will not show track titles. One command re-enables it per account for anyone who wants that back. Paperwork Recipe item mpris-proxy-off/ in the fixes folder with bake lines and the preset file. Handoff addendum, findings section 15 with the four-clock table and decode, memory, and a correction note to PC are all on the Share and NAS. Evidence on the NAS: the 40 MB raw capture, all logs, the WiiM status logs, and the decoder. WIIM-REPORT-bluetooth-mutes-10s-on-AVRCP-STOPPED-PASTE-READY-2026-09-22.md on the Share. Redaction check passed: no addresses, names, or device IDs. It asks WiiM to un-mute on PLAYING instead of holding ten seconds. Also fixed tonight: .local name resolution and the FUSE bridge so Files can open the NAS and hand tracks to mpv, recorded as a recipe item. Still open from earlier: the five-colour plaid wallpaper set. Dont let em know my age (Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man.). One Thing .. I don't Know Why...

Well Mr. Claude, why did you not find this sooner? It was all about angles.. but that wasn't correct was it? Bash Record the flicker resolution and the missed isolation test in memory IN M=/memory; cat >> $M/chrome-rk3588-hw-composition-flicker.md <<'EOF' **RESOLUTION 2026-09-22 (evening, agent diff of both kernels + live measurement on Plaid):** "kernel fixed it" is NOT supported; "Chromium's fault" was never right either. Facts: (1) on 2.0.x the kernel was silent during flicker and Chromium 114 was clean on the same kernel where 132 flickered; (2) the only kernel mechanism ever implicated (RK3588 `layer_sel` latch, no convergence wait in `rk3588_vop2_cfg_done`) is **byte-for-byte unchanged in rkr7.2**; the 11.8k-line vop2 diff has no flicker-relevant hunk for the OPi (new guards are gated on legacy cursor / DT knobs we don't set); (3) **measured on Plaid with Chromium fullscreen at 4K60: the only scanned-out framebuffer is gnome-shell's own (linear, Cluster0) + the 64x64 cursor — Chromium's buffer never reaches a plane, i.e. mutter composites it; on 2.0.x mutter direct-scanouted Chromium's linear panfork buffer, and `MUTTER_DEBUG=disable-direct-scanout` was exactly what cured head #2 on 08-27.** So the two flicker heads had two causes, both in the GPU/display stack under the browser: head #2 (typing/text fields) = direct-scanout path (gone on Plaid because the blob's client buffers are AFBC, which our AFBC-reject patch refuses → composited); head #3 (thumbnails/images) = ANGLE rendering on panfork Mesa 23 (gone because the blob replaced panfork). A Chromium rebuild would have fixed neither. **Lesson:** after concluding "ANGLE on panfork" in August the cheap isolation test was the ARM blob on 2.0.x (debs were at hand); I never proposed it. Remaining confirmatory experiment if wanted: g24p0/g13p0 blob on .176 (kernel 1027 + Chromium 132 held constant); kernel-axis test = boot Plaid's rkr7.2 deb on the 2.0.x rootfs. Side effect found in the diff: rkr7.2 gates XRGB2101010 scanout on AFBC, so with patch 0001 10-bit RGB scanout formats are refused on Plaid; rkr7.2 also has an official DT knob `rockchip,disable-afbc-mask` that could replace patch 0001. EOF sed -i 's|^- \[Chrome RK3588 HW-composition flicker\].*|- [Chrome RK3588 HW-composition flicker](chrome-rk3588-hw-composition-flicker.md) — RESOLVED 2026-09-22: two heads, two causes in the GPU/display stack (direct-scanout path + ANGLE-on-panfork); Plaid flicker-free because blob buffers are composited, not because of the newer kernel (layer_sel code unchanged); Chromium rebuild would have fixed nothing|' $M/MEMORY.md && echo saved OUT saved Half right, and the half that was wrong cost us the cheap fix. What the evidence says now. The 2.0.x flicker was two different faults with two different causes, and neither was Chromium's code. The typing and text-field flicker came from the scanout path. On 2.0.x, mutter took Chromium's buffer and put it straight onto a hardware plane. Disabling direct scanout cured that head on August 27, and we never followed the lead. I measured Plaid tonight with Chromium fullscreen at 4K60. Chromium's buffer never touches a plane. The only framebuffer being scanned out is gnome-shell's own, plus the cursor. Mutter composites the browser on Plaid, so that fault path simply is not taken. The thumbnail and image flicker was ANGLE rendering on panfork Mesa. That is the part the ANGLE theory got right. It is gone because the ARM blob replaced panfork, not because ANGLE changed. The kernel did not fix it. The agent diffed the VOP2 driver between the 1027 tree and rkr7.2. The one kernel mechanism we ever implicated, the layer-select latch race, is unchanged in rkr7.2. The new code in the diff is either gated on device-tree knobs we do not set or on legacy cursor updates that mutter does not use. Our own August data also argued against the kernel. Chromium 114 was clean on the same kernel where 132 flickered, and the kernel logged nothing during thirty seconds of reproduced flicker. So why is Plaid clean? Because the blob hands out AFBC buffers, our AFBC-reject patch refuses them at scanout, and mutter falls back to compositing. That is our own kernel patch interacting with the new GL driver, not a newer kernel. And the blob itself replaced the renderer that ANGLE was choking on. Where I went wrong. In August the conclusion was "ANGLE on panfork". The obvious next experiment was to swap the GL driver and keep everything else, and the libmali debs were on the rig. I never proposed it. We would have had the answer, and likely a shippable 2.0.x fix, two months ago. The Chromium rebuild you were about to do would have fixed neither head. If you want it nailed shut, the confirming test is the blob on the 2.0.x board with kernel 1027 and Chromium 132 held constant. It takes about half an hour and is reversible over ssh. Not tonight. Two byproducts from the diff worth knowing. The rkr7.2 kernel only allows 10-bit RGB scanout with AFBC, so with our reject patch Plaid refuses 10-bit RGB scanout formats entirely. And rkr7.2 has an official device-tree knob for disabling AFBC per window, which could replace our patch cleanly. Both are in memory with the resolution. does this mean we can fix the previous Joshua Riek Fork? Yes, for the most part, and without rebuilding Chromium. Head one, the typing and text-field flicker: a one-line fix, already proven on the fork. On August 27 setting mutter's disable-direct-scanout debug flag made that head vanish on the 2.0.x board. That is the same path Plaid avoids by accident. It ships as one environment line for the GNOME session, no kernel or browser change. The cost is that fullscreen clients get composited instead of flipped straight to the plane, which is a small amount of extra GPU work at 4K and is what Plaid is doing today while looking fine. Head two, the thumbnail and image flicker: fixable, but it is a stack change, not a flag. The cure is replacing panfork with the ARM blob, which is the swap Plaid made. On the fork that means: The blob has to work on the 1027 kernel's older kbase driver. Plaid runs g24p0 on kbase g29p1. The 1027 tree has kbase g18p0, and the blob checks the driver version at open. The g13p0 deb on the rig is the fallback if g24p0 refuses. This is the half-hour test on the .176 board I mentioned, and it is the gate for everything else. Everything we solved for Firefox on the blob this week comes along: the wayland-gbm variant, the device-query shim, the private libGL shim. All portable, all archived. One real trade-off. On panfork, Firefox plays 8-bit video zero-copy. On the blob it drops to software for 8-bit, because the blob has no two-channel 8-bit dma-buf format. Chromium does 8-bit in hardware either way. Most of YouTube is 8-bit, so Firefox users on the fork would feel that. What I would do. Ship the direct-scanout line in a 2.0.3 point release now, since it is free and tested. Run the blob-on-1027 test on .176 before deciding on head two. If the blob loads on g18p0, the choice becomes a product one between Firefox 8-bit hardware decode and Chromium being flicker-free, and there is a middle path of shipping the blob with Firefox as the recommended browser for video. If it does not load, head two stays a known issue on the fork and Plaid is the answer for Chromium users.

The project has turned out to be a gem. I can retire Joshua Riek Fork I am calling it Pi Desktop 3.0 Plaid (Not live yet... expect a week of soak). They should take and call it Armbian Rockchip Resolute The combination Pi Claude called the make-or-break unknown this morning — a 26.04 userland has no business running on a 2023-era Rockchip BSP kernel, but it does: Chromium/Chrome Hardware acceleration with no web rendering flickering. Firefox runs everything but 8 bit HEVC... so far 26.04 / GNOME 50.1, mutter 50.1, Mesa 26.0.8 libmali G610 g24p0 (newest G610 blob that exists) on kbase g29p1 rockchip-linux/mpp 2026-08-05 snapshot (yisding's resolute packaging) rockchip-vaapi 2.2.0 rebuilt for resolute PipeWire / WirePlumber 1.6.9 / 0.5.17 (resolute ships 1.6.2 / 0.5.13) MPV stock 0.41 + our mpv.conf ffmpeg / libva 8.0.1 / 2.23 PulseAudio—purged baked: hi-res allowed-rates, SBC-XQ ported Lua→SPA-JSON Bluetooth parameters applied... No Audio Stutter on wifi scans... https://discourse.osmc.tv/t/cypress-release-fix-for-onboard-bluetooth-audio-stuttering/74345 4k@120hz patch applied... And the whole chain did exactly what the patches intended: before now v0pll24 MHz (parked on the crystal) 2 165 779 907 Hz — driver re-rated it to 2× the pixel clock dclk_vop0533 250 000 1 082 889 954 (46 Hz off target, pure rounding) PHYlts4 → lts3 → ltsl thrash, fell back to p60 rk_hdptx_frl_lcpll_cmn_config rate=4000000000 → PHY clk ready → PHY lane locked → Training finish, go to ltsp Mode fell back to 59.997 Hz 120.000 Hz, current One mode set, no fallback, zero VOP/HDMI errors, desktop alive, GPU idling at 300 MHz and 36 °C. The link came up in FRL at 4 Gbps/lane — the first time this board has negotiated FRL rather than TMDS. So the diagnosis held: rkr7.2's new vop2_is_dclk_switch_to_cru_pll() was reading our raised 1200 MHz ceiling and therefore kept an FRL-rate mode on the HDMI PHY PLL, which in the rewritten PHY driver can't leave TMDS on its own; and VP0 had no path to v0pll, the only PLL that can be re-rated to an arbitrary pixel clock. Two patches, both small. Also confirmed live: CMA is 512 MB (the distro value you chose), and the AFBC-reject patch is in with no AFBC complaints in the log.

Funny I ran into this today, testing for a new distro installed: PipeWire 1.6.9 with WirePlumber 0.5.17 — built from Debian sid's packaging Good report, and the diagnosis is right. Two things to add: confirmation that the package list is still the cause on current main, and measurements from a Resolute (26.04) GNOME image built with the framework that avoids it. Current main still carries it. The desktop package definitions moved from config/desktop/ into the configng desktop YAML (tools/modules/desktops/yaml/gnome.yaml). There, pulseaudio and pulseaudio-module-bluetooth sit in the GNOME definition's minimal tier package list (lines 53–54 at a97f0d2, checked today), which every tier installs. Only the trixie, forky and sid blocks add pipewire-audio/pipewire-pulse and a packages_uninstall entry for the two PulseAudio packages. The noble and resolute blocks don't, so a Noble or Resolute GNOME image built today gets the same two-server setup you found on 26.2.1. It follows from the package list, not from the board. What the framework builds when the list is fixed. I build an Orange Pi 5B image with the framework (rk35xx vendor 6.1.172, Resolute, GNOME 50.1). The customize step does what you propose, plus a belt-and-braces mask: apt-get purge -y pulseaudio pulseaudio-module-bluetooth apt-get install -y --no-install-recommends pipewire pipewire-pulse pipewire-audio pipewire-alsa \ wireplumber libspa-0.2-bluetooth alsa-ucm-conf systemctl --global mask pulseaudio.service pulseaudio.socket Nothing pulls PulseAudio back: gnome-settings-daemon depends on pipewire-audio | pulseaudio and libspa-0.2-bluetooth | pulseaudio-module-bluetooth, so the PipeWire side satisfies both. Your checks, run on that image: $ systemctl --user is-active pulseaudio pipewire wireplumber pipewire-pulse inactive active active active $ dpkg -l pulseaudio | grep ^un # not installed; pipewire-pulse, pipewire-alsa installed $ fuser -v /dev/snd/controlC0 /dev/snd/controlC1 /dev/snd/controlC2 /dev/snd/controlC0: wireplumber # WirePlumber alone, on all three cards /dev/snd/controlC1: wireplumber /dev/snd/controlC2: wireplumber $ pactl info | grep 'Server Name' Server Name: PulseAudio (on PipeWire 1.6.9) # $XDG_RUNTIME_DIR/pulse/native served by pipewire-pulse $ time pw-play tone-5s.wav 5.08 s The sink goes IDLE right after playback (and back to SUSPENDED after the normal idle timeout) instead of never leaving SUSPENDED, and Chromium/Firefox video plays at real time. Your "frozen at 0:00" description is a very good one for a stalled audio clock — it sent me down the VA-API rabbit hole too before I looked at the sound servers. One gotcha for whoever edits the list: don't drop pulseaudio-utils along with pulseaudio. It ships pactl/paplay, both work fine against pipewire-pulse, and a surprising number of scripts and desktop helpers assume pactl exists. My first build purged it too, and I spent a while wondering where pactl had gone. (The package-list check and the measurements above were done with help from an LLM assistant(Claude fable 5.1); the image and the numbers are from real hardware.)

I have started working on a possible transition to the latest vendor kernel and I am having a display race. Try toggling the display.. unplug / replug. Nice to have a claude SSH'ed in to see everything is fine.

UPDATE: Thanks to JFL For Testing and noting. That's a genuinely useful confirmation, and it changes the picture in a way that matters for your product. His three data points, sorted: Stack Decode lane BSP 6.1 + Chromium 153 (xtradeb) + our driver VA-API — our driver BSP 6.1 + Chromium 132+rkmpp (amazingfate) V4L2 via libv4l-rkmpp, driver unused Mainline 6.18/7.2 + Chromium 153 v4l2request — our driver not needed Two consequences worth sitting with. Our driver's value is specifically the BSP lane. On mainline, Chromium reaches the VPU through the stateless V4L2 request API and doesn't need us at all. On the vendor kernel — where 4K@120 and the rest of your product lives — there is no v4l2request, so VA-API plus our driver is the only current-browser path. That's a sharper positioning statement than we've had. And it's the answer to a security problem I raised earlier. Pi Desktop ships Chromium 132 from the PPA, twenty-one majors behind, missing all 230 fixes in the Chrome 153 bulletin including an exploited V8 zero-day. JFL just demonstrated that a VA-API-enabled Chromium 153 on a BSP kernel gets hardware decode through your driver — so switching browsers would fix the security gap, retire the libv4l-rkmpp shim lane, and consolidate on one decode path. JFL Private Reply "@defcom5-rockchip On my Armbian-KDE-Neon for `libv4l-rkmpp` → **V4L2 lane, my driver is not being used by Chromium**, the Chromium need to be purpose build example Chromium-132.0.6834.159-1~deb12u1+rkmpp from amazingfate ppa. With Chromium-153 (xtradeb) it uses vaapi for vpu hw acceleration when bsp kernel-6.1.y-vendor-rk35xx is being used and "rockchip-vaapi-wraper" installed. Your "rockchip-vaapi-wraper", for me, bring new life to the Armibna bsp kernel-6.1.y-vendor-rk35xx image. As the Chromium from amazingfate is already more than one year old. Thanks to you (rockchip-vaapi-wraper) and amazingfate enabling vaapi on Chromium on Debian-Repo (I think xtradeb Chromium is based on Debian Chromium build) Chromium has vpu hw acceleration on Armbian bsp-kernel-6.1. With mainline kernel-6.18 or 7.2 Chromium-153 uses v4l2request for vpu hw acceleration."

Ok I wasnt going to say But Sandi, says Prove The Shit. Who Is Wrong.... nyanmisaka left a comment (jellyfin/jellyfin-ffmpeg#765) I am unable to reproduce the issue. jellyfin-ffmpeg is intended solely for use with the Jellyfin server. If the custom version of our MPP dependency is causing your specific problem, please build your own version using the upstream MPP. Additionally, you completely ignored the issue report template. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread Sandi's right to push, and the honest answer is: he's right on two counts, and we have one gap I should close before we say a word back. Where he's right: I ignored the issue template. Factually true, entirely my fault. Their repo has one and I posted free-form. Scope. jellyfin-ffmpeg is for the Jellyfin server. I drove their binary from a command line and said so in the issue — he's entitled to call that out of scope. Where his reply proves nothing: "unable to reproduce" with no parameters. This needs RK3588 specifically, VP9 Profile 2 10-bit, both decoder cores, and ~65,536 frames in one continuous session. Miss any one and you see nothing. He didn't say what he ran. And here's our gap, which I should have caught: our A/B compared their prebuilt binary (stormed at 66,083) against our build of the fork tip with the revert (clean at 73,214). Those differ by two things — the patch and the build environment. We never built the unmodified fork tip ourselves. Closing that now. Bash Build the unmodified fork tip as the missing control IN SP=/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=12 pi-desktop@192.168.1.176 'cd ~/mpp-bisect || exit 1; git checkout -q -B forkclean nyan/jellyfin-mpp-next 2>/dev/null; git reset --hard -q; echo " === MISSING CONTROL: our own build of the UNMODIFIED fork tip ==="; echo " HEAD: $(git log -1 --format="%h %s" | cut -c1-60)"; echo " fast-mode line present (fork behaviour): $(grep -c "hal_task_count = 2" mpp/hal/rkdec/vp9d/hal_vp9d_api.c 2>/dev/null)"; echo " working tree clean: $(git status --porcelain | wc -l) changes"; echo "--- CONTROL: unmodified fork tip, our toolchain" >> ~/bisect-log.txt; nohup setsid bash -c "cd ~/mpp-bisect && ~/bisect-test.sh; echo CONTROL_EXIT=\$? >> ~/bisect-log.txt" >/dev/null 2>&1 </dev/null & disown; sleep 45; echo " building..."' 2>&1 | grep -v Warning OUT === MISSING CONTROL: our own build of the UNMODIFIED fork tip === HEAD: 4e5b4cfe7 fix[sys_cfg]: Do not align FBC hor_stride fast-mode line present (fork behaviour): 1 working tree clean: 0 changes building... Bash Wait for the control result IN SP=/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; for i in $(seq 1 18); do OUT=$(setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=10 pi-desktop@192.168.1.176 'tail -3 ~/bisect-log.txt' 2>/dev/null | grep -v Warning); if echo "$OUT" | grep -q "CONTROL_EXIT="; then echo "=== CONTROL RESULT: our build, unmodified fork tip ==="; echo "$OUT" | sed 's/^/ /'; break; fi; sleep 45; done OUT === CONTROL RESULT: our build, unmodified fork tip === --- testing 4e5b4cfe7 (2025-11-28) 18:32:27 BROKEN: storm at ~66300 frames (414 resets) CONTROL_EXIT=0 Deep Seek Bring Out The Agents.. Fuck That Pussy We are a Team! Fuck Him Charge Me If You're Wrong... I Think You're right. The control landed, and it closes the gap: our build, UNMODIFIED fork tip: STORM at ~66,300 frames (414 resets) our build, fork tip + revert 15c29e0fa: CLEAN at ~73,214 frames (0 resets) Same toolchain, same board, same stream, same session length. One line of difference. That was the last hole in the argument and it's now shut. So on the substance, the data says we're right — and I'd say that with or without money on it. But let me be straight with you about the full picture, because two of his three points stand: He's right that I ignored the issue template. That's mine. It reads as careless and it gives a maintainer an easy reason to close. He's right about scope. jellyfin-ffmpeg is built for the Jellyfin server; I drove it from a command line. I flagged that limitation in the issue myself. "Unable to reproduce" is the part that proves nothing — no SoC, no codec profile, no duration. This needs RK3588 specifically, VP9 Profile 2 10-bit, both decoder cores, and 65,536+ frames in one unbroken session. On RK3576 or with 8-bit content or a 5-minute clip, you see exactly nothing. Upstream's own disable is RK3588-only, which is likely why. On tone — I'd push back hard on the evidence and stay completely flat on the person. He's an unpaid maintainer of something we use, he's already told us the fix (build against upstream MPP), and that's precisely what we're doing. We don't need him to lose for us to win; we need our images fixed, which we can do ourselves today. And I'd skip spinning up agents for this. There's nothing left to parallelise — the decisive measurement is done, and it's one line in a table. Want me to draft the reply? I'd lead with the template apology, give him the exact reproduction parameters, put the one-variable A/B in front of him, and ask what he tested. That's harder to wave away than anything with heat in it. yes draft it Bash Draft the reply to nyanmisaka IN D=/home/rich-defrese/rockchip-notes/experiments/mpp-rkr72-port-test; cat > "$D/jellyfin-765-reply.md" <<'EOF' You are right about the template — I should have filled it in, and I apologise for that. You are also right that this repo is for the Jellyfin server; I drove the bundled binaries directly, which is outside how you intend them to be used. I flagged that in the report but I should have led with it. On reproduction, I suspect we ran different tests. The fault needs **four** conditions together, and missing any one of them shows nothing at all: 1. **RK3588 / RK3588S** — upstream's `support_fast_mode = 0` guard is specific to this SoC, so other Rockchip parts should be unaffected 2. **VP9 Profile 2 (10-bit)** — 8-bit VP9 is clean past 73,000 frames, HEVC Main10 clean past 70,000 3. **both rkvdec cores active** — disabling either one makes it disappear 4. **~65,536+ frames in one continuous decode session** — about 18 minutes at 60 fps, 45 at 24 fps; any decoder teardown resets the count, so short clips and seeks never reach it Exact reproduction: ffmpeg -i <4K 10-bit VP9 Profile 2 source> -c:v copy -f ivf out.ivf mpi_dec_test -i out.ivf -t 10 # separately: dmesg | grep -c "rkvdec-core.*resetting" If it helps, could you say which SoC, which stream, and roughly how many frames your test ran? If it was not RK3588 with 10-bit VP9 past ~65k frames in one session, that would explain the difference between us entirely. ### The measurement Since my first report compared your prebuilt binary against a source build — two variables — I rebuilt both sides from source myself, same toolchain, same board, same stream, same session. One line differs: | Build | Frames decoded | Resets | |---|---|---| | `jellyfin-mpp-next` @ `4e5b4cfe7`, unmodified | **66,300** | **414** | | the same tree + `git revert --no-commit 15c29e0fa` | **73,214** | **0** | `15c29e0fa` is `Revert "fix[hal_vp9d]: not support fast mode for rk3588"`, which restores `hal_task_count = 2` on a SoC where upstream sets `support_fast_mode = 0`. For completeness, upstream is clean at every point I tested, including the exact commit this branch is based on: | Upstream `rockchip-linux/mpp` | Frames | Result | |---|---|---| | `a37666b01` (2024-04-15) | 73,011 | clean | | `437bfbeb9` (2025-11-10 — the base of `jellyfin-mpp-next`) | 72,830 | clean | | `0986d0129` (2026-08-26) | 116,787 | clean | Board: Orange Pi 5B (RK3588S), kernel `6.1.0-1027-rockchip`. Both cores confirmed active and evenly loaded each run via per-core `/proc/interrupts` deltas (e.g. 33,041 / 33,042). ### What I am actually asking for Nothing, really — and I should have been clearer about that from the start. I am taking your advice and building against upstream MPP for my own images. I filed this because the same library ships to Jellyfin users on RK3588 hardware, and a long 10-bit VP9 title would cross that threshold mid-playback with no error surfaced to the application. If that is not a case you consider worth carrying, that is a completely reasonable call and I will not press it. Happy to re-file against the template, or to run any specific test you would find convincing. EOF echo " words: $(wc -w < "$D/jellyfin-765-reply.md"), leak hits: $(grep -cE "rich[._-]?defrese|DeFrese|cox\.net|/home/rich" "$D/jellyfin-765-reply.md")" OUT words: 515, leak hits: 0 Draft is at jellyfin-765-reply.md. The shape of it: Concedes both fair points immediately — template and scope — because arguing those costs us credibility on the part that matters. Gives him the four conditions, so "unable to reproduce" has somewhere to go. If he tested RK3576, or 8-bit, or a five-minute clip, the disagreement evaporates and neither of us is wrong. Leads the evidence with the one-variable A/B — the control you just paid ten minutes of bench time for. That table is the whole argument: same tree, same toolchain, one git revert, 414 resets versus 0. Ends by lowering the stakes. We're building against upstream regardless, so we're not asking him for anything. If he doesn't want to carry it, that's his call. That's not capitulation — it's removing his reason to dig in, while the measurement sits there unanswered. The one thing it deliberately doesn't do is match his tone. "You completely ignored the issue report template" was a jab; responding in kind turns a technical disagreement into a personality one, and the table is far more damaging to his position than any amount of heat. Want me to post it? And if you'd like, I can also re-file properly against their template as a separate clean issue — that removes his procedural objection entirely and costs us nothing. give it a little balls Bash Redraft with more backbone IN D=/home/rich-defrese/rockchip-notes/experiments/mpp-rkr72-port-test; cat > "$D/jellyfin-765-reply.md" <<'EOF' Fair hit on the template — that one's mine, and I'll re-file against it if you want the report to stand. The rest needs data rather than assertion. "Unable to reproduce" without saying what you ran doesn't engage with the measurement, and this fault has four conditions that all have to hold at once. Miss any one and you will see nothing, correctly: 1. **RK3588 / RK3588S.** Upstream's `support_fast_mode = 0` guard is specific to this SoC. Other Rockchip parts should be fine. 2. **VP9 Profile 2, 10-bit.** 8-bit VP9 runs clean past 73,000 frames; HEVC Main10 past 70,000. 3. **Both rkvdec cores active.** Disable either and it vanishes. 4. **65,536+ frames in one unbroken session** — ~18 min at 60 fps, ~45 at 24 fps. Any decoder teardown resets the count, so short clips, seeks and quality switches never get there. ffmpeg -i <4K 10-bit VP9 Profile 2 source> -c:v copy -f ivf out.ivf mpi_dec_test -i out.ivf -t 10 # separately: dmesg | grep -c "rkvdec-core.*resetting" Tell me the SoC, the stream and the frame count you reached and we can settle this in one message. If it wasn't RK3588 running 10-bit VP9 past ~65k frames in a single session, we simply tested different things. ### The measurement My first report compared your prebuilt binary against a source build, which is two variables. So I rebuilt both sides myself — same toolchain, same board, same stream, same session length. **One line differs:** | Build | Frames | Resets | |---|---|---| | `jellyfin-mpp-next` @ `4e5b4cfe7`, untouched | **66,300** | **414** | | identical tree + `git revert --no-commit 15c29e0fa` | **73,214** | **0** | `15c29e0fa` is `Revert "fix[hal_vp9d]: not support fast mode for rk3588"` — it restores `hal_task_count = 2` on the one SoC where upstream deliberately sets `support_fast_mode = 0`. Upstream is clean at every point I tested, **including the exact commit this branch is based on**: | `rockchip-linux/mpp` | Frames | Result | |---|---|---| | `a37666b01` (2024-04-15) | 73,011 | clean | | `437bfbeb9` (2025-11-10 — base of `jellyfin-mpp-next`) | 72,830 | clean | | `0986d0129` (2026-08-26) | 116,787 | clean | Orange Pi 5B (RK3588S), kernel `6.1.0-1027-rockchip`. Both cores verified active and evenly loaded on every run via per-core `/proc/interrupts` deltas (33,041 / 33,042 on the failing one). It reproduces on demand in about six minutes. That is a deterministic, one-line result. It stands until something contradicts it, and "cannot reproduce" isn't that. ### On scope Your call entirely — but be clear about what it means. That library ships to your users, and on RK3588 a feature-length 10-bit VP9 title crosses 65,536 frames mid-playback. When it does, **nothing surfaces to the application**: through 714 resets in one of my runs, `mpi_dec_test` wrote zero bytes to stdout and stderr and exited normally. The only evidence is `dmesg`. Anyone validating the way you likely just did would record a pass. I'm building against upstream for my own images either way, so I'm not asking you for anything. I filed it because your users don't have that option and won't know why their film falls apart eighteen minutes in. Re-file against the template, or run any test you'd find convincing — say which and I'll do it. EOF echo " words: $(wc -w < "$D/jellyfin-765-reply.md"), leak hits: $(grep -cE "rich[._-]?defrese|DeFrese|cox\.net|/home/rich" "$D/jellyfin-765-reply.md")" OUT words: 538, leak hits: 0 Redrafted with spine. What changed: The apology is one line now, not a paragraph. Owned and moved past. Direct challenge on the non-answer: "'Unable to reproduce' without saying what you ran doesn't engage with the measurement." Then the four conditions, then "Tell me the SoC, the stream and the frame count you reached and we can settle this in one message." He either produces parameters or he doesn't. The line that does the work: "That is a deterministic, one-line result. It stands until something contradicted it, and 'cannot reproduce' isn't that." Scope turned back on him. He's entitled to decline — but the draft names the cost: his users, his hardware, a film that dies eighteen minutes in, and zero bytes on stdout or stderr through 714 resets. That last detail is pointed, because it's very likely how he "couldn't reproduce" — running the test and seeing a clean exit code. Still no insults, and still no ask. We're building against upstream regardless, which means he can't read it as us needing a favour. The pressure is entirely from the table. That's as firm as I'd go while keeping it something you'd be happy to have quoted back at you in a thread with 4,000 views. Post it? Post It ! Bash Post the reply to the jellyfin-ffmpeg issue IN export GH_PAGER=cat; D=/home/rich-defrese/rockchip-notes/experiments/mpp-rkr72-port-test; echo " identity: $(gh api user --jq .login 2>/dev/null)"; URL=$(gh issue comment 765 --repo jellyfin/jellyfin-ffmpeg --body-file "$D/jellyfin-765-reply.md" 2>&1 | tail -1); echo " posted: $URL"; echo; gh issue view 765 --repo jellyfin/jellyfin-ffmpeg --json state,comments --jq '" issue state: \(.state)\n comments: \(.comments|length)\n last by: \(.comments[-1].author.login) at \(.comments[-1].createdAt[0:16])"' 2>&1 OUT identity: defcom5-rockchip posted: https://github.com/jellyfin/jellyfin-ffmpeg/issues/765#issuecomment-5642616018 issue state: CLOSED comments: 2 last by: defcom5-rockchip at 2026-09-12T01:43 Posted: https://github.com/jellyfin/jellyfin-ffmpeg/issues/765#issuecomment-5642616018 One thing you should know: he closed the issue when he replied. Our comment landed on a closed thread — it still notifies him and everyone watching, and it's fully visible in the record, but it won't sit in their open queue. I'd leave it closed. As the author I can probably reopen it, but doing that unilaterally right after a maintainer closed it reads as fighting over the ticket rather than the facts, and it hands him a procedural reason to disengage. The comment is what matters, and it's there permanently: a deterministic one-line A/B, the four reproduction conditions, and a direct request for what he actually tested. If he comes back with parameters, we'll know within a message whether we tested different things. If he doesn't, the table stands unanswered in public — which is its own outcome, and a better one than an argument. Either way it changes nothing about your path: we build librockchip_mpp with that one revert and ship it in Pi Desktop and Pi Studio. Your users get a working library regardless of what anyone upstream decides. Want me to start that build? It's the same revert we just proved, packaged as librockchip-mpp1 versioned above the PPA's so apt prefers yours. Redrafted with spine. What changed: The apology is one line now, not a paragraph. Owned and moved past. Direct challenge on the non-answer: "'Unable to reproduce' without saying what you ran doesn't engage with the measurement." Then the four conditions, then "Tell me the SoC, the stream and the frame count you reached and we can settle this in one message." He either produces parameters or he doesn't. The line that does the work: "That is a deterministic, one-line result. It stands until something contradicted it, and 'cannot reproduce' isn't that." Scope turned back on him. He's entitled to decline — but the draft names the cost: his users, his hardware, a film that dies eighteen minutes in, and zero bytes on stdout or stderr through 714 resets. That last detail is pointed, because it's very likely how he "couldn't reproduce" — running the test and seeing a clean exit code. Still no insults, and still no ask. We're building against upstream regardless, which means he can't read it as us needing a favour. The pressure is entirely from the table. That's as firm as I'd go while keeping it something you'd be happy to have quoted back at you in a thread with 4,000 views. Bong!

https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.2.0 You may have to patch your MPP to the latest. https://github.com/rockchip-linux/mpp EOF

It's gotten much clearer. Latest MPP Library and the issue is gone. Jellyfin's build is affected too. VERDICT: STORM at ~66,083 frames (core0 33,041 / core1 33,042) 280 resets So nyanmisaka's jellyfin-mpp-next at a9380ef (Dec 2025) still has it. That gives us three points on the map: MPP build Date Result 5275a9a6 (distro PPAs, ours) Apr 2024 storms at 64,728 a9380ef (Jellyfin's fork) Dec 2025 storms at 66,083 master 0986d0129 (upstream) Aug 2026 clean to 116,787 Complete and clean: VERDICT: CLEAN through ~70,464 frames, resets=0 (core0 35,232 / core1 35,232) Full stream, perfectly balanced cores, zero resets — on the library that stormed on VP9 at 66,083. The characterisation is now airtight: Codec Depth MPP build Frames Result VP9 Profile 0 8-bit 5275a9a6 73,381 clean VP9 Profile 2 10-bit 5275a9a6 (2024) 64,728 storm VP9 Profile 2 10-bit a9380ef (Jellyfin, Dec 2025) 66,083 storm VP9 Profile 2 10-bit master 0986d01 (Aug 2026) 116,787 clean HEVC Main 10 10-bit a9380ef (same affected lib) 70,464 clean 10-bit VP9 specifically. Not 10-bit generally — HEVC Main 10 sails through on the very build that kills VP9. That's a strong constraint for whoever fixes it, and it sharpens FumasterLin's point: if both codecs share the kernel driver flow, the fault has to be in VP9's own 10-bit handling above that shared path.

@JFL — two separate things in your post, and the good news is your decoder is fine. The zero is correct. **1. Your `0` is the expected result now, not a failed test.** Your stats say `4K/60 vp09` — that is Profile 0, **8-bit**, and 8-bit is immune. My 8-bit runs went past 73,000 frames and `mpi_dec_test` went past 115,000, all with zero resets. You could run that video all day and never see one. So nothing is wrong with your setup on that score, and nothing more is needed from you. To see the fault you would have to force the **10-bit** rung (`vp9.2`, itag 337) — but honestly, do not bother. It is reproduced, root-caused and reported. **2. The blank `dmesg` after `dmesg -C` is normal — but here is how to prove it.** After `sudo dmesg -C` the buffer is empty, and if nothing goes wrong nothing gets added. A blank log is the *correct* output for a clean run. It only looks alarming because you cannot tell "nothing happened" from "my check is broken." I hit exactly this trap today: my monitoring script read the log through `sudo -n`, which silently failed every time, and it cheerfully reported "0 resets" for a run whose entire purpose was to count resets. I nearly reported a fix that had never been tested. Since then I seed a fake event first and confirm the counter sees it: sudo sh -c 'echo "selftest rkvdec-core: resetting for err 0x0" > /dev/kmsg' dmesg | grep -c "rkvdec-core.*resetting" # must print 1 sudo dmesg -C # then clear and start the real run If that prints `1`, your instrument works and a later `0` means something. If it prints `0`, the check itself is broken. Worth doing any time the pass condition is *absence* of an event. **3. Your dropped frames are real, but they are not the decoder.** 107,159 dropped of 205,010 is about half, and your log says why: dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0) dw_dp_aux_transfer: 22 callbacks suppressed That is the **DisplayPort AUX channel** timing out over and over — the sideband link between the SoC and your monitor, used for link training and status. "22 callbacks suppressed" means it is firing far more often than the log prints. Nothing there is decode-related; the video pipeline is producing frames and the display link keeps resetting under them. Worth checking, roughly in order of likelihood: - **The cable and any adapter.** AUX is the flakiest part of DP and the first thing to fail on a marginal cable, a USB-C→DP dongle, or a long run. Swap it before anything else. - **Try an HDMI output instead.** If the drops vanish on HDMI, it is the DP link, and you have your answer in five minutes. - **The monitor itself** — some displays are poor DP AUX citizens, especially with DSC or at 4K60. If it is DP-specific on your 5 Plus, that is worth its own thread — it is a different bug from this one, and it would explain smooth-looking playback that is quietly dropping half its frames. Thanks again for the runs. Your clean result is what stopped me chasing a kernel difference between our boards that never existed. EOF

Updated Reply, Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your box was fine. So is mine. **The variable was the video format, not the hardware.** **It only happens on 10-bit VP9.** I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each time — same board, same kernel, same driver, same MPP, same player: | Content | Frames decoded | Exports | Result | |---|---|---|---| | VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean | | VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean | | VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** | The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a steady stream of `err 0x23`. Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384** exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It tracks **decoded frames in one session**, and only on the 10-bit path. **Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames are exactly what my 8-bit runs produce, and they always would have been. So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting kernels to explain a difference between our boards that does not exist. Your result was correct data; I was interpreting it against the wrong variable. **If you want to reproduce it** (only if you are curious — you have already done more than enough): yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm # the 10-bit rung sudo dmesg -C mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm # ~18 min at 60fps dmesg | grep -c "rkvdec-core.*resetting" At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up at that point. The practical shape of the bug, as it stands tonight: - **8-bit playback is unaffected**, at any length. - **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at 60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every new video starts a fresh session. - Anything that restarts the decoder resets the clock. **Update, a few hours later — we have the root cause, and there is a workaround.** A Rockchip engineer (@FumasterLin) suggested on the upstream issue that I try disabling one of the RK3588's two decoder cores. That is the answer: echo 1 > /proc/mpp_service/rkvdec-core1/disable_work | Configuration | Frames decoded | Resets | |---|---|---| | both cores (default) | 64,728 | 714 | | **core1 disabled** | **115,062** | **0** | Clean to 115,062 frames — nearly twice the failure point — and it only stopped because the stream ended. It costs about 17% of decode throughput (207 fps down to 172 fps on my board), which for real-time playback is free, since you only need 60. It also turns out this has nothing to do with my VA-API driver: Rockchip's own `mpi_dec_test`, headless with no display at all, fails at the same point. So it is a dual-core parallel decoding problem in MPP, and the frame count was a red herring — with both cores splitting the work evenly, ~64,700 total is ~32,350 per core, right on 2^15. So if anyone hits garbled 10-bit playback after ~18 minutes, disabling core1 is a genuine workaround until this is fixed upstream. Thank you for the 45-minute run — a clean result that contradicts the theory is worth more than a dozen that agree with it, and this one sent me looking in the right place.

Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your box was fine. So is mine. **The variable was the video format, not the hardware.** **It only happens on 10-bit VP9.** I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each time — same board, same kernel, same driver, same MPP, same player: | Content | Frames decoded | Exports | Result | |---|---|---|---| | VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean | | VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean | | VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** | The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a steady stream of `err 0x23`. Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384** exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It tracks **decoded frames in one session**, and only on the 10-bit path. **Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames are exactly what my 8-bit runs produce, and they always would have been. So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting kernels to explain a difference between our boards that does not exist. Your result was correct data; I was interpreting it against the wrong variable. **If you want to reproduce it** (only if you are curious — you have already done more than enough): yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm # the 10-bit rung sudo dmesg -C mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm # ~18 min at 60fps dmesg | grep -c "rkvdec-core.*resetting" At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up at that point. The practical shape of the bug, as it stands tonight: - **8-bit playback is unaffected**, at any length. - **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at 60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every new video starts a fresh session. - Anything that restarts the decoder resets the clock. I am updating the upstream issue with this. Thank you for the 45-minute run — a clean result that contradicts the theory is worth more than a dozen that agree with it, and this one sent me looking in the right place. Working with FumasterLin

@JFL Can you tell me your OS build out.

Issue placed: https://github.com/rockchip-linux/mpp Updated. The issue now reads, at a glance: rkvdec2: VP9 decode fails after exactly 2^16 frames in a session, when the client imports an exported dma-buf per frame (err 0x23 timeout storms; HEVC and readback clients unaffected)

Testing a custom kernel with newer MPP Where your features live, and whether the port touches them: feature driver touched? 4K@120 output drivers/gpu/drm/rockchip (VOP2, HDMI) no NPUdrivers /rknpu no 2D engine 1.3.13drivers/video/rockchip/rga3 no Ethernet suspend fix drivers/net/phy, drivers/net/ethernet no CVE and Bluetooth backports various no video decode service drivers/video/rockchip/mpp yes On "latest vendor": Armbian's rk-6.1-rkr7.2 is Rockchip's BSP release 7.2 on kernel 6.1.172; ours is a 6.1.75 base from ubuntu-rockchip, an older Rockchip drop. Moving our whole base to rkr7.2 would be a different and much larger project, and that one genuinely would put 4K@120 at risk, because our display work is patched against the older VOP2 and would need reworking, plus NPU revalidation. Not something to do casually, and not what's building now. The real risk of this port is narrower: the kernel driver talks to the userspace MPP library, and a newer driver could expect a newer library. If that mismatches, decoding fails immediately and obviously rather than subtly, and the whole thing reverts with one command since it's a single commit.

Measured, and it identifies exactly what differs between a run that fails and a run that never does: driver activity, per run headless (clean) display (storms) surfaces exported as buffers 0 90,180, one per frame synchronisation calls 0 127,403 frames decoded 1,801 in 30 s 90,180 The headless path never exports a single buffer. The display path exports one per frame, which the client then imports into the GPU's own memory unit and drops again, sixty times a second, for twenty minutes. That's roughly seventy thousand map-and-unmap cycles in the graphics domain before the decoder starts missing its deadline. So to answer you directly: yes, it narrows to the MPP stack, since that's what emits the timeout and what owns the VP9 path. But the trigger appears to be sustained buffer traffic on the GPU side of the same memory subsystem, which is why HEVC at the same frame rate doesn't do it and why nothing headless ever does. That's a concrete lead rather than a shrug, and it belongs in the issue. Bash Post the measured difference to the upstream issue and record it

OK I'm banging on linux-rockchip-mpp's door. I Had them go through the open issues and PR's. Surveyed. Four things worth knowing, and one recommendation. The maintainers are responsive and take community patches. Most issues close the same day, several outside pull requests have been merged. Filing our report is worth doing. Their standing answer to reset reports is exactly what our evidence contradicts. Two issues carry our kernel message, #588 and #701, and both were answered with "a data error causes a hardware reset, that's normal, it recovers at the next keyframe". That is a fair answer for a lossy network stream. It is not an answer for a local file that decodes with zero errors in software and runs clean headless for twenty minutes on the same board. That gap is precisely the new information we'd be contributing, and it's why the report should lead with the headless-versus-displayed comparison rather than with the error code. Pull request #968 is the most interesting open item for us. A team running an RK3588 kiosk chased a 1.3 GB/day leak and found two lifecycle bugs in MPP, one of them decoder-side: the input packet is attached to the output frame's metadata while the decoder still owns it, so it can be released twice. Their symptom is a crash with a non-positive reference count. Ours isn't that, and our memory stayed flat, so I won't claim a connection. But it's evidence that decoder-side lifetime handling in MPP has real bugs that only long-running workloads expose, which is the same shape as ours. Issue #958 is somewhere our own hard-won knowledge would help. Someone on an RK3576 can't play HEVC 10-bit in mpv because the exported buffer arrives with no pixel format declared. We solved exactly that class of problem in our driver, including the fourcc detail that cost us a day. A short factual comment there would be genuinely useful to them. My recommendation: file our report as an issue on that tracker, since the venue is active and the maintainers answer. Say the word and I'll post the draft under your account, and separately offer the note on #958.

Hi @JFL — before you spend the evening on that A/B, save yourself the trouble: we chased this all day yesterday and the artifacts are not caused by rc1. Reverting will not remove them. What we found, all measured on an Orange Pi 5B: The garbling is the VPU decoder timing out and being reset by the kernel, in bursts of hundreds of resets at ~15/s for 20–60 s: mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 (0x23 has the TIMEOUT bit set). That is what damages the picture until the next keyframe. It arrives after ~17 minutes of uninterrupted 4K60 playback, and it happened in nine separate runs at 1051–1287 s. It reproduces with the RGA copy disabled, i.e. on exactly the code path 2.1.5 ships — and also in mpv, which never touches Chrome's pipeline. Two unrelated videos, 8-bit and 10-bit, streamed and from local files. It never happens when decoding without a display client: the same files through ffmpeg -hwaccel vaapi -f null - at real-time pace ran 20+ minutes with zero resets, every time. Not heat (38–50 °C, first throttle point 75 °C), not the file (both decode with zero errors in software), not memory or file descriptors, and our VA-API driver logs 650k lines through a storm without a single allocation failure, pool exhaustion or sync timeout. So it is a decoder-side fault that only a client holding decoded frames on screen can reach, and 2.1.5 has it too — you would have met it the first time you left a 4K60 video running for twenty minutes. The objective test, if you want to confirm it on the 5 Plus (this is the data point I'd most like from you, on either driver version): sudo dmesg -C # clear the log # play any 4K60 clip fullscreen for 20+ minutes dmesg | grep -c "rkvdec-core.*resetting" Zero for the first seventeen minutes, then hundreds. If your board shows the same signature, that is a second, independent piece of hardware for the upstream report I'm drafting for Rockchip and Armbian. On the Firefox drops you mention: worth knowing that when I measured Firefox here it was not decoding steadily at all — sampled every five seconds it read 65, 51, 0, 0, 13, 65, 12, 0, 0 fps. It stalls and catches up, which shows up as your 1–3 % drops. Chrome holds a steady 60. That difference is also why Firefox looked immune to the storms in my first test: it never sustains the condition long enough. I would not read it as Firefox being better or worse, just less steady.

OK its getting deep: Not Chromium's, no. mpv stormed twice on the same file, at 21.5 and 28 minutes, which is what ruled that out. Firefox looked immune but its test was invalid: it was stalling constantly, decoding in bursts with dead gaps, so it never sustained the condition. That's the pattern worth noticing. The failure needs uninterrupted decoding, and Chrome is simply the client that's good enough to deliver it: rock-steady 60 fps for twenty minutes. Firefox stutters and accidentally protects itself; mpv is steady and eventually breaks; headless ffmpeg decodes fine but never holds frames on screen. So it's a decoder-side fault that only a well-behaved display client can reach. Which is also why your blink idea is promising rather than a hack: if 400 milliseconds of pause every eight minutes prevents it, that confirms the accumulation is per-continuous-run and gives users a real workaround while the kernel side gets fixed. Worth staying honest about where we are, though: the blink run is only around ten minutes in, still short of the seventeen-minute mark where Chrome broke three times. Clean now doesn't mean much yet.

I Just want to remind people that this is a real cooking show>>> Same trap: the pattern still matched the launch path in my own command. Using the exact process name instead, which can't match a shell. Bash Relaunch Chrome with remote control, killing the old one by exact process name IN SP="/tmp/claude-1000/-homhomelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -x chrome 2>/dev/null; sleep 4; echo "chrome procs left: $(pgrep -cx chrome)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "Chrome/[0-9.]+" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /' OUT chrome procs left: 0 devtools: decoding at 65 fps clock starts 18:51:21 Chrome is up with remote control and decoding at 65 fps. Rather than build a service before knowing whether the idea works, the cheapest test of the premise is a page that interrupts itself on a timer. Bash Run Chrome on a page that pauses playback for 400 ms every eight minutes, to test whether a brief gap prevents the storm IN SP="/tmp/claude-1000/--notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'cat > /home/pi-desktop/soak-blink.html <<'"'"'EOS'"'"' <!doctype html><meta charset=utf-8><title>blink soak</title> <style>html,body{margin:0;background:#000;height:100%}video{width:100vw;height:100vh;object-fit:contain} #t{position:fixed;left:8px;top:8px;color:#0f0;font:14px monospace;background:#000a;padding:4px 8px;z-index:9}</style> <div id=t>starting</div> <video id=v autoplay muted playsinline src="oled-30min.mkv"></video> <script> const v=document.getElementById("v"), t=document.getElementById("t"); const start=Date.now(); let blinks=0, lastBlink=0; const EVERY=8*60*1000, GAP=400; // pause 400 ms every 8 minutes setInterval(()=>{ const el=Date.now()-start; if (el-lastBlink>=EVERY && !v.paused) { lastBlink=el; blinks++; v.pause(); setTimeout(()=>v.play(), GAP); } const q=v.getVideoPlaybackQuality?v.getVideoPlaybackQuality():{totalVideoFrames:0,droppedVideoFrames:0}; t.textContent=`${Math.floor(el/1000)}s blinks ${blinks} frames ${q.totalVideoFrames} dropped ${q.droppedVideoFrames} pos ${v.currentTime.toFixed(0)}s`; },1000); </script> EOS echo "page written"; pkill -x chrome 2>/dev/null; sleep 4; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --start-fullscreen "file:///home/pi-desktop/soak-blink.html" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps — a 400 ms pause every 8 min, counter on screen"' 2>&1 | grep -v Warning; date +%T | sed 's/^/blink soak starts /' OUT page written decoding at 64 fps — a 400 ms pause every 8 min, counter on screen blink soak starts 18:52:27 The premise is now under test: same file, same Chrome, but the page pauses itself for 400 milliseconds every eight minutes. You'll see a brief blink at the eight and sixteen minute marks and a counter in the corner. If this comes through 25 minutes clean, then a tiny interruption does reset whatever accumulates, and the workaround becomes trivial: no service, no process killing, just a periodic blink. If it storms at seventeen minutes anyway, the idea is dead and I'll say so. Bash Monitor the blink-soak for resets through the failure window IN SP="/tmp/claude-1000/notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; S="setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=6 pi-desktop@192.168.1.176"; T0=$(( $(date +%s) - 90 )); for i in $(seq 1 10); do OUT=$($S 'A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 3; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); printf "decode=%sfps resets=%s temp=%sC" "$(( (B-A)/3 ))" "$(sudo -n dmesg 2>/dev/null | grep -cE "rkvdec-core.*resetting")" "$(( $(cat /sys/class/thermal/thermal_zone0/temp)/1000 ))"' 2>/dev/null); R=$(echo "$OUT" | grep -oE "resets=[0-9]+" | cut -d= -f2); EL=$(( $(date +%s) - T0 )); M=""; [ -n "$R" ] && [ "$R" -gt 0 ] && M=" *** STORM at ${EL}s — the blink does NOT help ***"; [ "$EL" -gt 1300 ] && [ "${R:-0}" -eq 0 ] && M=" <-- past 21 min clean with blinks"; echo "$(date +%T) playing=${EL}s $OUT$M"; sleep 55; done OUT Command running in background with ID: bbur7ndk8. Output is being written to: /tmp/claude-1000/-home-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bbur7ndk8.output. You will be notified when it completes. To check interim output, use Read on that file path. Monitoring. First blink at eight minutes, the decisive window at seventeen.

The Shit Is Bananas... Killed my own session with that pattern for the fourth time today; I clearly need to stop typing bare patterns. Retrying with it escaped. I'm gonna say we need a restart service on Chrome. I did not see any firefox issue.. can we make chrome buttery smooth with a quick restart ? That's a sound instinct, and there's a mechanism behind it: short-lived decode sessions never accumulate whatever this is. Headless ffmpeg processes are short-lived and never storm; Firefox's constant gaps may be why it looks immune. The least disruptive "restart" isn't Chrome itself, it's Chrome's GPU process, which owns the decoder session. Chrome respawns it automatically and playback continues. If killing it resets the clock, a timer every ten minutes turns a twenty-second garbling episode into a one-second blink. Testing whether playback actually survives it before promising anything. Bash Stop Firefox, start Chrome fullscreen on the file, and confirm it is decoding IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "^/usr/lib/firefox/firefox" 2>/dev/null; pkill -x firefox 2>/dev/null; sleep 3; echo "firefox left: $(pgrep -cf firefox)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /home/pi-desktop/.local/bin/google-chrome-hw --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "chrome decoding at $(( (B-A)/5 )) fps"; echo "gpu-process pid: $(pgrep -f "chrome.*type=gpu[-]process" | head -1)"' 2>&1 | grep -v Warning; date +%T | sed 's/^/chrome started /' OUT firefox left: 1 chrome decoding at 64 fps gpu-process pid: 68595 chrome started 18:48:44 i hear that there is nothing new under the sun. A restart timer is indeed an old trick, and this bug may well be old too. What's new here is only the boundary: it needs a client holding frames on screen, which is why nobody transcoding on a server has ever hit it. Chrome is decoding at 64 fps. Testing whether it survives losing its GPU process. Bash Kill Chrome's GPU process during playback and watch whether decoding recovers IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'P=$(pgrep -f "chrome.*type=gpu[-]process" | head -1); echo "killing gpu process $P at $(date +%T)"; kill -9 $P 2>/dev/null; for i in 1 2 3 4 5 6 7 8; do sleep 2; N=$(pgrep -f "chrome.*type=gpu[-]process" | head -1); A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 2; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo " +$((i*4))s: gpu_pid=${N:-none} decode=$(( (B-A)/2 ))fps"; done; echo "chrome windows alive: $(pgrep -cf "/opt/google/chrome/chrome")"' 2>&1 | grep -v Warning OUT killing gpu process 68595 at 18:49:05 +4s: gpu_pid=68864 decode=0fps +8s: gpu_pid=68864 decode=0fps +12s: gpu_pid=68864 decode=0fps +16s: gpu_pid=68864 decode=0fps +20s: gpu_pid=68864 decode=0fps +24s: gpu_pid=68864 decode=0fps +28s: gpu_pid=68864 decode=0fps +32s: gpu_pid=68864 decode=0fps chrome windows alive: 17 Killing the GPU process doesn't work: Chrome respawns it within four seconds, but decoding never resumes, still zero after half a minute. The browser survives, the video doesn't. Is the picture frozen or black on your screen? So a blunt process restart is out. The scriptable version is Chrome's own remote-control interface, which can pause and resume the video, or reload the page to build a fresh decoder, without killing anything. Bash Relaunch Chrome with its remote-control interface so a workaround can be scripted and tested IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "/opt/google/chrome/chrome" 2>/dev/null; sleep 4; echo "chrome left: $(pgrep -cf "/opt/google/chrome/chrome")"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --remote-allow-origins=* --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 25; echo "devtools endpoint: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version | head -c 60)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /' OUT clock starts 18:50:05 Killed my own session with that pattern for the fourth time today; I clearly need to stop typing bare patterns. Retrying with it escaped. Bash Relaunch Chrome with remote control using a self-match-safe kill pattern IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "google-chrom[e]" 2>/dev/null; sleep 4; echo "chrome left: $(pgrep -cf "google-chrom[e]")"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "\"Browser\": *\"[^\"]+\"" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"; echo "page: $(curl -s --max-time 5 http://127.0.0.1:9222/json/list 2>/dev/null | grep -oE "\"url\": *\"file[^\"]*\"" | head -1 | cut -c1-70)"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /' OUT clock starts 18:50:22 Same trap: the pattern still matched the launch path in my own command. Using the exact process name instead, which can't match a shell. Bash Relaunch Chrome with remote control, killing the old one by exact process name IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -x chrome 2>/dev/null; sleep 4; echo "chrome procs left: $(pgrep -cx chrome)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "Chrome/[0-9.]+" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /' OUT chrome procs left: 0 devtools: decoding at 65 fps clock starts 18:51:21 Chrome is up with remote control and decoding at 65 fps. Rather than build a service before knowing whether the idea works, the cheapest test of the premise is a page that interrupts itself on a timer. Bash Run Chrome on a page that pauses playback for 400 ms every eight minutes, to test whether a brief gap prevents the storm IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'cat > /home/pi-desktop/soak-blink.html <<'"'"'EOS'"'"' <!doctype html><meta charset=utf-8><title>blink soak</title> <style>html,body{margin:0;background:#000;height:100%}video{width:100vw;height:100vh;object-fit:contain} #t{position:fixed;left:8px;top:8px;color:#0f0;font:14px monospace;background:#000a;padding:4px 8px;z-index:9}</style> <div id=t>starting</div> <video id=v autoplay muted playsinline src="oled-30min.mkv"></video> <script> const v=document.getElementById("v"), t=document.getElementById("t"); const start=Date.now(); let blinks=0, lastBlink=0; const EVERY=8*60*1000, GAP=400; // pause 400 ms every 8 minutes setInterval(()=>{ const el=Date.now()-start; if (el-lastBlink>=EVERY && !v.paused) { lastBlink=el; blinks++; v.pause(); setTimeout(()=>v.play(), GAP); } const q=v.getVideoPlaybackQuality?v.getVideoPlaybackQuality():{totalVideoFrames:0,droppedVideoFrames:0}; t.textContent=`${Math.floor(el/1000)}s blinks ${blinks} frames ${q.totalVideoFrames} dropped ${q.droppedVideoFrames} pos ${v.currentTime.toFixed(0)}s`; },1000); </script> EOS echo "page written"; pkill -x chrome 2>/dev/null; sleep 4; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --start-fullscreen "file:///home/pi-desktop/soak-blink.html" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps — a 400 ms pause every 8 min, counter on screen"' 2>&1 | grep -v Warning; date +%T | sed 's/^/blink soak starts /' OUT page written decoding at 64 fps — a 400 ms pause every 8 min, counter on screen blink soak starts 18:52:27 The premise is now under test: same file, same Chrome, but the page pauses itself for 400 milliseconds every eight minutes. You'll see a brief blink at the eight and sixteen minute marks and a counter in the corner. If this comes through 25 minutes clean, then a tiny interruption does reset whatever accumulates, and the workaround becomes trivial: no service, no process killing, just a periodic blink. If it storms at seventeen minutes anyway, the idea is dead and I'll say so. Bash Monitor the blink-soak for resets through the failure window IN SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; S="setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=6 pi-desktop@192.168.1.176"; T0=$(( $(date +%s) - 90 )); for i in $(seq 1 10); do OUT=$($S 'A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 3; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); printf "decode=%sfps resets=%s temp=%sC" "$(( (B-A)/3 ))" "$(sudo -n dmesg 2>/dev/null | grep -cE "rkvdec-core.*resetting")" "$(( $(cat /sys/class/thermal/thermal_zone0/temp)/1000 ))"' 2>/dev/null); R=$(echo "$OUT" | grep -oE "resets=[0-9]+" | cut -d= -f2); EL=$(( $(date +%s) - T0 )); M=""; [ -n "$R" ] && [ "$R" -gt 0 ] && M=" *** STORM at ${EL}s — the blink does NOT help ***"; [ "$EL" -gt 1300 ] && [ "${R:-0}" -eq 0 ] && M=" <-- past 21 min clean with blinks"; echo "$(date +%T) playing=${EL}s $OUT$M"; sleep 55; done OUT Command running in background with ID: bbur7ndk8. Output is being written to: /tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bbur7ndk8.output. You will be notified when it completes. To check interim output, use Read on that file path. Monitoring. First blink at eight minutes, the decisive window at seventeen. Hang Tough

Finishing move : Jellyfin 12 on RK3588 with the Rockchip VA-API driver How to run Jellyfin 12.0 on an RK3588/RK3588S board (Orange Pi 5/5B/5 Plus and friends) so that the server transcodes in hardware and the browser clients on the same board direct-play in hardware through this driver. Written from a Pi Desktop 2.0.2 bench (Ubuntu 24.04, BSP 6.1 kernel, panfork Mesa), but the server part is the same on Armbian and plain Ubuntu with a vendor kernel. Two different pieces of hardware acceleration are involved, and it helps to keep them apart: https://github.com/defcom5-rockchip/rockchip-vaapi/blob/main/docs/JELLYFIN-12-RK3588.md

Nice to have toys that work... JFL's numbers land exactly where the measurements said they would, on hardware we don't own: lane on the 5 Plus (4K60 VP9 P2 HDR, 9,240 frames) 2.1.5 rc1 vaapi + x11egl 97 dropped 1 vaapi + Wayland, windowed 345 46 vaapi + Wayland, fullscreen — 25 One drop on x11egl equals his rkmpp-plus-RGA run, which was the whole point: the only difference between those lanes was the CPU repack. The Wayland residual is the compositor's extra pass, and his display-resample result (DS: 1.030) shows mpv misjudging his display rate by 3%, so that mode is right for our GNOME bench and wrong for his setup. Good to know before it went into anyone's advice. Meanwhile rc1 is now the system driver on .176 for the soak (it reports 2.2.0-rc1 through vainfo, links librga, symlinks intact, 10-bit plays); the 2.1.5 deb is kept on the board for a one-line rollback. When the soak is quiet for a few days and JFL answers on the credit, rc1 promotes to 2.2.0 with his two results in the notes. Reply for JFL (saved on the NAS as reply 11): Hi @JFL — that's the result, exactly where the numbers said it would land: vaapi + x11egl went from 97 dropped frames to 1, the same as your rkmpp + scale_rkrga run, because the only difference between those two lanes was the CPU repack and it's gone. Thank you for turning it around so fast. The Wayland column (345 → 46 windowed, 25 fullscreen) is the compositor's extra pass, as before; the driver can't remove that one. And your display-resample run tells me something useful: DS: 1.030 means mpv thinks your display runs about 3 % faster than the video, so it's resampling audio to chase it — on our GNOME setup the ratio is 1.000 and that mode gives 0 drops, on yours it isn't the right tool. x11egl stays the best lane for the 5 Plus; nothing to change there. I'll credit "JFL (Armbian forum, Orange Pi 5 Plus)" in the 2.2.0 release notes for both the Chrome 10-bit confirmation and this one. rc1 becomes 2.2.0 after it has run as the system driver on our bench for a while; same link, non-rc file name.