Shenzhen RK PVT — Remote Test, Round 1
2026-10-21 · Wilber Zheng · times are UTC+7 · every test ran remotely over SecureLink
Summary: every runnable functional, video, soak and CPU/memory test passed on the PVT, and no board hardware fault was found. Each remaining failure has a known cause: two come from the site setup (the monitor and the SD card were unplugged), and two are player product issues on a China network. The render benchmark gave no valid result, because the site monitor runs at 100 Hz and its assets load too slowly over the link. We also found a player bug: on its first start after boot, the player reports an OS version with no kernel part.
1. Environment and device
Device under test
| Item | Value |
|---|---|
| Device | RK3576 ProPlayer Gen5, PVT board back from production, flashed with our OS by the vendor. Board: Giada DN84 (gaidatech-evb-giada-dn84) |
| Image | dbg455 · git b66382a24 · bake 20261019T035857Z-243057817-b66382a24 · built 2026-10-19. The image is the evt image; it runs unchanged on this PVT board |
| Kernel | 6.1.99-rockchip-standard |
| Player / utils | 5.7.1-P31-RK / 4.0.1+dev.3bec1631 |
| Hardware | 8-core CPU (governor performance, big cores 2208 MHz) · RAM 3.99 GB · eMMC 58.3 GB · zram 7.6 GB · about 46 °C at idle |
| Identity | UUID 6ebb86096de8a20ba982d3ac78091817f789 · backend _id 6ad8311bf16f6753eb64516a |
| Portal | Screen name rk_pvt_shenzhen · account testing10 (team FsnNPHeasJZGW5mgq) · folder "Test Bench — wilber-msa2-ubuntu (Wilber's desk — remote)" · time zone Asia/Shanghai |
| Content | Playlist 2Bws8X3cnD3Q23tfg. It is not in our content library and its name is unknown. simple-playlist was pushed at noon and was replaced before 16:30. Video player type: default |
Network
| Item | Value |
|---|---|
| Site network | Wi-Fi "Redmi_AX6S" (5 GHz, 5745 MHz, signal 74), IP 192.168.31.166/24, gateway 192.168.31.1. The first network the board used could not be reached over SecureLink; the board was reachable only after the site switched to a hotspot |
| SecureLink | 100.65.179.160 · region APAC · connected. The board was allocated APAC from the start (10:28). The portal's region field showed US until 14:28, so only the label lagged |
| Latency / bandwidth | About 110 ms RTT with occasional loss (one 30% ping-loss blip, recovered within 1 min) · about 2 MB/s to Cloudflare · about 70 KB/s to opstech · about 230 KB/s through an ssh reverse tunnel |
| Reachable from the board | Reachable: Power BI, www.cnn.com, S3, app/support.optisigns.com, social-player, weather API, Baidu, captive.apple.com, Cloudflare, ipinfo, ipwho, geojs Not reachable: YouTube, ytimg, Google, connectivitycheck.gstatic.com · edition.cnn.com is very slow (about 80 KB/s) · ipapi.co returns 403 Connections from the board to our host over SecureLink: blocked |
Peripherals
| Peripheral | State |
|---|---|
| Monitor | Xiaomi Mi Monitor on HDMI-A-1, 1920×1080 @ 100 Hz. Unplugged around 16:50, then reconnected |
| SD card | SanDisk-type 64 GB SDXC (SDR104, 198 MHz), ext4, auto-mounted at /run/media/mmcblk1p1. rk_test_build ran a read/write test: the md5 of 64 MB of random data matched, write 22.9 MB/s, read 84.3 MB/s. The card was pulled while mounted around 16:54, leaving 3 I/O errors in the kernel log |
| Not present | Capture card, smart plug, serial, test Wi-Fi. Cases that need them are not in this suite |
Test side
| Item | Value |
|---|---|
| Test kit | A local remote-board suite on Wilber's desk (the harness repo is not modified). It runs stages in order, with a link check before and after each stage. Each failure is classified as a link problem or a real failure and rerun once. After each stage the kit verifies the portal name, folder, content and player, restores anything that changed, and meters data on the board's own interface counters |
| Harness code | device-harness origin/main d0658b99 (a separate, uncommitted checkout) |
| Rig | proplayer-rk-wilber-pvt-01: host resolved from the backend's SecureLink IP; no capture, plug or serial; no network changes |
| Cases adapted locally | DEV-CTL-021: longer waits · SYS-AN-002: the settings restore retries for 10 min · SYS-FN-055: longer waits (90 s) · OS-RES-001 / SYS-REL-008 / SYS-FN-013 / SYS-REL-011: playlist swapped to pl-gen5-golden (no YouTube/CNN/Google members) |
| Timeline | 17:03 S1–S4 · 17:28 S5–S6 · 18:47 S7 (two failed attempts) · 19:03 S7a · 19:19 retest · 19:35 done |
2. Results by stage
| Stage | What | Pass | Fail | Skip | Time | Data | Notes |
|---|---|---|---|---|---|---|---|
| S1 | Read-only OS health (12) | 11 | 1 | 0 | 6 min | 8 MB | OS-BOOT-001 and OS-KERN-002 failed first because the monitor was unplugged; both pass on retest. OS-KERN-001 fails only on the 3 SD-pull errors |
| S2 | Device management via backend (7) | 7 | 0 | 0 | 5 min | 5 MB | Screenshot, remote terminal, telemetry, proof of play; the reported osVersion was correct |
| S3 | Player kill and respawn (1) | 1 | 0 | 0 | 1 min | 48 MB | The restarted player re-fetched the current playlist |
| S4 | Content push and web (4) | 3 | 1 | 0 | 9 min | 108 MB | SYS-FN-055: the troubleshoot wizard does not complete (see §4) |
| S5 | mpv video (5 cells) | 5 | 0 | 0 | 4 min | 275 MB | Hardware decode, no dropped frames, three render types |
| S5b | Playback soak (4, pl-gen5-golden) | 4 | 0 | 0 | 50 min | 144 MB | OS-RES-001 20 min, SYS-FN-013 zram, SYS-REL-008 memory, SYS-REL-011 cache |
| S6 | Services that may be blocked in CN (4) | 2 | 0 | 2 | 17 min | 58 MB | 7-min Power BI soak and S3 upload pass. The Power BI and news render cases need a capture card and skip |
| S7a | CPU / memory (hwbench) | 1 | 0 | 0 | 14 min | 51 MB | Numbers in §3 |
| S7b | Render benchmark | 0 | no valid result | — | 13 min | 1 MB | The monitor runs at 100 Hz while the canary band is set for 60 Hz, and the test pages time out loading over the link |
Data used on the PVT in total: about 716 MB. No failure was caused by a link drop: every rerun failed for the same reason as the first run. After every stage the kit confirmed the screen name, folder, content, video player type and player state were back as before.
3. Performance (S7a: player stopped, preheated to 46.7 °C)
| Metric | Median | Notes |
|---|---|---|
| CPU CoreMark | 10582 iter/s | 3 runs, CoV 0.10% |
| Memory STREAM copy | 11279 MB/s | 3 runs |
| Memory STREAM triad | 10192 MB/s | 3 runs, CoV 0.11% |
| tinymembench memcpy | 5439 MB/s | 1 run |
| Memory latency | 126 ns | 1 run |
OS-RES-001 20-min soak on pl-gen5-golden: player memory 1.09–1.61 GB, minimum MemAvailable 2.19 GB, no swap used, CPU mean 23%, max SoC temperature 64.7 °C, no OOM kill, no restart.
The device-side restore timer (it brings the player back if the link dies while the player is stopped) was used for the first time and worked: armed before the player stopped, re-armed before each test, removed at the end. The player and the guards were restored and the staged binaries were deleted.
4. Findings
| # | Finding | Evidence | Type |
|---|---|---|---|
| 1 | osVersion misses the kernel part: on the first player start after boot it reports -dbg455 / -dbg464 instead of 6.1.99-dbg… | Seen on both the PVT and evt-01. Correct after any later player restart. The value comes from the player's uname -r | awk (utils.yocto.ts); the same command run by hand is correct | Player bug, root cause open |
| 2 | The troubleshoot wizard often does not finish on a China network | Of its probes, connectivitycheck.gstatic.com is blocked (10 s timeout) and ipapi.co returns 403. It did not finish within 90 s. Once it reached the summary, but "Test again" stalled | Player product issue (affects CN customers) |
| 3 | The kernel reports the SD card as RM=0 / HOTPLUG=0, so the external-storage case DEV-CTL-013 skips when run unchanged | With a temporary detection change by rk_test_build it passes: the portal stored the path and the player acknowledged it. The change is not committed | Kernel config, raised with Phuoc |
| 4 | The 100 Hz monitor makes the render benchmark refuse the run as "rig unhealthy" | The canary measured 100.0 fps against a 60 Hz band | Test environment |
| 5 | The monitor and the SD card were unplugged on site | First-pass failures of OS-BOOT-001, OS-KERN-002 and OS-KERN-001; the first two pass after the monitor came back | Test environment |
| 6 | Early SecureLink unreachability came from the site network (16% of attempts reached the board). After the hotspot switch the board was reachable. The portal region field lagged behind the real allocation | infras peer page; ping/ssh before and after the network change | Network environment |
5. Next steps (in priority order)
- Root-cause the osVersion bugrecommended: reboot evt-01 once and capture the player's first start (log and environment), then hand the result to the player owner. Needs Wilber's OK to reboot evt-01.
- Troubleshoot wizard: ask the player team to stop depending on gstatic for the online check (or give each probe a short timeout so one blocked host cannot stall the wizard), and to replace ipapi.co.
- Render benchmark retest: switch the output to 1080p60 for the run and serve the assets from the board's own tmpfs. This temporarily changes the display mode and stages files on the board (both reverted after); it needs Wilber's OK. Alternatively, use evt-01 numbers, since it is the same SoC.
- SD card detection: rerun DEV-CTL-013 with a card inserted once the kernel config change from Phuoc lands.
- OS-KERN-001: rerun after the next PVT reboot, which clears the SD-pull errors. If the hotspot is down at boot, the board lands in the settings UI, so someone must be on site.
- Playlist 2Bws…: confirm who assigned it and whether simple-playlist should be restored.