v0.4.0 — pay-TV-safe pre-tune by default
What changed
Pre-tune of scrambled channels no longer engages the CA descrambler by default. The pool now uses the canonical 9-arg iRecordableService.prepare() (signature verified against openatv/enigma2 7.6) and passes descramble=False, so the FBC tuner locks the transponder without adding ECM / decoder load to the user's softcam, OSCam dvbapi, cardsharing or CI+ CAM path. Safe for cardsharing accounts (no anti-share ECM heat), single-decode CAMs (no contention with live), CI+ modules.
User-visible effect: scrambled HIT zaps show a brief black frame (~400 ms, the descrambler's first ECM round-trip) between tuner lock and clear picture. Free-to-air channels are unaffected.
New per-direction opt-in toggles
Three separate settings restore the v0.3.7-style behaviour where the descrambler engages during pre-tune, one toggle per pre-tune slot. UI labels:
- Activate descrambler in NEXT pay-TV pre-tune — engages the descrambler on the NEXT slot (bouquet position immediately below live). HITs a Channel ↓ press.
- Activate descrambler in PREVIOUS pay-TV pre-tune — engages the descrambler on the PREVIOUS slot (bouquet position immediately above live). HITs a Channel ↑ press.
- Activate descrambler in LAST pay-TV pre-tune (history) — engages the descrambler on the HISTORY slot (most recent non-live channel). HITs the last-channel button and the top entry of the history selector.
All three default off. The three slots are mechanically symmetric: all three re-arm on every successful zap, and each enabled toggle holds exactly one continuous descrambler session above the live consumer regardless of zap activity. Per-zap ECM bursts and parallel-decode count are identical across the three directions; card / softcam load scales with how many toggles are on, not with which one. Pick the direction that matches the user's primary zap action.
For cardsharing setups whose anti-share heuristic looks at long-window service diversity (rather than raw ECM rate), HISTORY's target set stays small for recall-heavy viewing while NEXT/PREV move with the live channel through the bouquet.
Provider coverage
All empirical numbers in these notes (ECM rates, ~400 ms black-frame, three-parallel-decode capacity) come from a single test bench: HD+ Nagravision (CAID 1843) on OSCam-smod through the GigaBlue UHD Quad 4K Pro's internal smartcard reader. The descramble=False mechanic itself sits above the CA layer and is provider-agnostic — Sky DE / UK / IT (Videoguard, NagraMA), ORF (Cryptoworks, Irdeto), M7 Group, Vodafone GigaTV, freenet TV / Diveo via CI+ CAM should all see the same architecture-level behaviour. The specific numbers will vary: black-frame duration is typically 200–700 ms depending on CA system and pairing, and consumer cards / CAMs often handle only one or two parallel decode sessions reliably. NCam, CCcam, mgcamd and mainline OSCam may also handle the enigma2-restart dvbapi-desync below differently.
Other improvements
ZAP_TIMINGlog line and/tmp/fbc_csc_timing.csvcarry the target service reference, so off-box analysis can classify FTA vs scrambled per zap.- CSV header migrate-on-first-write: a pre-0.4.0 timing CSV is rewritten in place on first launch so column counts stay consistent across the whole file. Idempotent.
- New "Descrambler behaviour and pay-TV channels" section in
docs/architecture.md.
Install
ssh root@<your-box>
wget https://github.com/empyfi/FBC-ChannelSpeedChange/releases/download/v0.4.0/enigma2-plugin-extensions-fbc-channelspeedchange_0.4.0_all.ipk -O /tmp/fbc.ipk
opkg install /tmp/fbc.ipk
init 4 && sleep 2 && init 3After enigma2 comes back, if pay-TV channels are black, restart the softcam manager once (/etc/init.d/softcam stop && /etc/init.d/softcam start) — see README "Operational note" for details.
Full release notes: CHANGELOG.md