Experimental option for third-party V4 receivers on BBShiftString: mute the V4 chain's packet phase (or send its config packet once)

[Starfield3]

Dan — a follow-up from the rig of #2948/#2959/#2964, an observation with a small opt-in suggestion, not a bug in your fix.

Rig: K32-Max (PocketBeagle 2), FPP 10.1.2 release image, SRx1 v5 on 33-36 (4 x 768 px), a Genius V4 receiver (third party, firmware not updatable) on 37-40 (768/768/192), boosters on all seven ports, 40 fps, remote of a Pi 5 master. Same rig and cabling that ran ~25 min clean on 698a864 yesterday.

Today, same 16-item playlist from the master, driver switched by copying pre-built binaries and restarting fppd, receiver power-cycled before each phase:

phase	driver	play time	sequence starts	Genius V4
1	release 10.1.2 (698a864)	~25 min	4	froze 3x, each at a start or at its own boot
2	10.1 + #2948 mute (V4 head off for the whole packet phase, no config packet)	60 min	14	fluid
3	release again	30 min	8	fluid, then froze at the 8th start
4	mute again	31 min	6	fluid, cables moved by hand mid-run

"Froze" = last frame held, receiver deaf until its own power cycle; never mid-song. The V5 receivers on the same bus were unaffected in every phase, and the K32 side is identical in all four: 40.0 fps every minute, your gate line declining one frame per sequence start and none during play, 0 eFUSE, 0 skips. Release PRU images and libs SHA-256-identical to yesterday's build; port config identical key by key; log level (debug on/off) no difference.

Possibly relevant from the log: with V5 queries on 50 % of frames the driver reports 26.2 ms per query frame against the 25 ms budget, and as a remote the box slews its period between 24.0 and 26.5 ms every ~30 s (LightDelay lines) - the V4 chain's packet phase is what gets tight at 24.0 ms. Kernel with the 10.1.2 image is 6.18.52-k3-r56 (was 6.18.48-k3-r54); nothing about PRU/pinctrl in the kernel log.

My reading: this receiver tolerates a config packet badly when the frame around it is tight; a Falcon receiver evidently doesn't care. The ask is small: an opt-in, clearly experimental setting for non-Falcon V4 receivers - the full packet-phase mute for a V4 chain, or its config packet sent once at start and on change instead of every packet frame - default off, Falcon behaviour untouched. We run the mute locally and are fine for the season; this is so the next person with a mixed chain has a switch instead of a patch. Meter logs for all phases on request.

[Starfield3]

For scale, this is the whole change on 10.1.2 - the mute is what ports 2-4 of a chain already get (max), applied to the send-only head when a setting is on. No PRU change: the head simply drops out of the AFTER_FIRST_PACKET group, so the parked masks never see it, and the cached config packet is no longer stamped into its slot. Setting read once in setupFalconV5Support(), so restart-fppd semantics.

src/non-gpl/BBShiftString/BBShiftString.cpp, setupFalconV5Support():

// opt-in for non-Falcon V4 receivers that lock up on config packets (#2972)
const bool muteV4 = getSettingInt("BBShiftStringV4PacketPhaseMute", 0) != 0;
...
p1->m_gpioCommands.clear();
if (sendOnly) {
    if (muteV4) {
        // line off for the whole packet phase in every frame: the chain never
        // receives a config packet and runs on the receiver's stored port config
        p1->m_gpioCommands.emplace_back(1, max, 0, 0);
    } else {
        p1->m_gpioCommands.emplace_back(1, GPIO_CMD_AFTER_FIRST_PACKET, 0, 0);
    }
}
...
// where the send-only config packet is cached for stamping:
if (rc->isSendOnly() && !muteV4) {
    m_sendOnlyConfigPackets.emplace_back(port, packets[port]);
}

www/settings.json, group "output":

"BBShiftStringV4PacketPhaseMute": {
  "name": "BBShiftStringV4PacketPhaseMute",
  "description": "V4 receiver chains: mute the packet phase (experimental)",
  "tip": "For non-Falcon V4-compatible receivers that lock up on configuration packets. The chain head's line stays off for the whole packet phase in every frame, so the receiver never receives a configuration packet and runs on its stored port configuration - program it once with this off, then enable. Falcon receivers do not need this and should not use it.",
  "level": 2, "gatherStats": true, "restart": 1, "reboot": 0,
  "checkedValue": "1", "uncheckedValue": "0", "default": "0", "type": "checkbox",
  "platforms": ["BeagleBone 64", "BeagleBone Black"]
}

Since your header comment notes a V4 receiver is specified to get its config packet regularly, the right granularity is probably per chain (a flag on the head port in co-bbbStrings.json) rather than per cape - a Falcon V4 next to this receiver would still want its packets. The per-cape checkbox above is the ten-line version; if you'd take either as a PR against master, say which and I'll send it.