After examining the attached images in this thread, here is what appears to have happened:
Subject: [PATCH] dvb: make USB tuners work through the GigaBlue BCM7252 vtuner
(gbue4k, Vu+ Duo 4K Lite)
USB tuners on GigaBlue BCM7252 receivers (and the Vu+ Duo 4K Lite, which
uses the same platform) have not worked since the 2018 driver change: they
install and lock, but scans find nothing and channels stay black.
Cause: until mid-2018 the vtuner lived inside nexus.ko and its write()
passed TS data to the demux whenever a PID was active. The current
standalone dvb.ko added a gate: write() drops every TS packet until the
proxy frontend has reported a non-zero status via MSG_READ_STATUS.
enigma2 tunes the real USB frontend directly and never queries the proxy,
so the gate never opens and PAT/VCT/SDT reads time out.
Answering the status request exposes three more driver quirks:
- the proxy struct dvb_frontend is not zero-initialised, so fe->exit is
garbage and frontend ioctls fail with ENODEV until the device has been
opened read/write once.
- with a non-zero VTUNER_SET_ADAPTER, poll() injects empty PID list
messages whenever no PID is active, overwriting a pending request (its
caller then waits forever holding the vtuner lock, hanging enigma2's main
thread on the next demux filter), and every write() sleeps 100 ms. This
was already present in 2018 but harmless while nothing queried the proxy.
- closing the vtuner unregisters the proxy frontend, which blocks until all
handles on it are closed, so a proxy handle closed after the vtuner fd
deadlocks process exit.
On this platform only (nexus and dvb modules loaded): hold the proxy
frontend open read/write on a descriptor number reserved below the vtuner
fd, poll FE_READ_STATUS on it from a status thread, answer MSG_READ_STATUS
in the vtuner pump with the real USB frontend status, answer any other
request that waits for a response, and do not set VTUNER_SET_ADAPTER.
Other receivers are unaffected.
Tested on gbue4k: Hauppauge HVR-950 (ATSC, US) scan and playback;
DVB-T/T2 confirmed working in Europe.
Co-Authored-By:
Claude Opus 5.5 <
[email protected]>
About Sundtek:
The patch only changes enigma2's own vtuner handling (eDVBUsbAdapter). My understanding of Sundtek sticks, which I haven't verified on this box, is that they run their own userspace driver (mediasrv) rather than a normal kernel DVB driver. On set-top boxes, that driver can open the vtuner device itself. If it does, it would hit the same gate, and nothing in enigma2 can answer for it. On a box with a Sundtek plugged in, two quick checks using telnet or terminal:
ls /sys/class/dvb/ # a real kernel adapter for the Sundtek?
ls -l /proc/$(pidof mediasrv)/fd 2>/dev/null | grep vtuner # is mediasrv holding a vtuner itself?
Seems If mediasrv is holding /dev/misc/vtunerN, Sundtek's daemon has to answer MSG_READ_STATUS itself. Hence Sundtek would need to fix it.
