Bug #2846
closed
capmt fails when descrambling on multiple adapters and same mux
Added by Sebastian K. almost 10 years ago.
Updated almost 10 years ago.
Found in version:
3.9.2849~gbdd0eb6-dirty
Description
Generally descrambling works on multiple adapters. Behavior now when watching two scrambled channels which are on same mux is descrambling fails.
Don't know if it's important but if camask differs for demuxers descrambling works.
Snipped from oscam where descrambling fails:
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 continue decoding of SRVID 002A
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 ecmpid 0 CAID: 1834 ECM_PID: 1C5E PROVID: 000000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 found 1 ECMpids and 1 STREAMpids in PMT
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 serving srvid 002A (13th Street) on adapter 0000 camask 0001 index 0000 pmtpid 0000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 ecmpid 0 CAID: 1834 ECM_PID: 1C1E PROVID: 000000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 found 1 ECMpids and 1 STREAMpids in PMT
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 serving srvid 001B (RTL Crime) on adapter 0000 camask 0001 index 0000 pmtpid 0000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 trying to descramble PID 0 CAID 1834 PROVID 000000 ECMPID 1C1E ANY CHID PMTPID 0000 VPID 002D
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 continue decoding of SRVID 002A
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 ecmpid 0 CAID: 1834 ECM_PID: 1C5E PROVID: 000000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 found 1 ECMpids and 1 STREAMpids in PMT
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 1 serving srvid 002A (13th Street) on adapter 0000 camask 0001 index 0000 pmtpid 0000
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 found channel in cache and matching prio -> start descrambling ecmpid 0
2015/05/15 00:03:02 11E2190 c (dvbapi) Demuxer 0 trying to descramble PID 0 CAID 1834 PROVID 000000 ECMPID 1C1E ANY CHID PMTPID 0000 VPID 002D
OSCam version r10653
update oscam, this was fixed in >= 10656
Still same behavior. Watching two scrambled channels on different muxes all is fine. If there are on same mux only the firstly tuned channel is descrambled. Stop working descrambling channel and resume other channel this one is descrambled.
TVHeadend: Build: 3.9.2851~g52e8375-dirty
OSCam: 1.20-unstable_svn Build: r10660
Hardware: Digital Devices GmbH Octopus DVB-C Adapter
you are right, seems to be introduced recently, currently trying to find the commit that caused it
24d7a6a3e31e2eb4d7f145aaaf0c84cb4e166665
f1e0b7c1ab7d80c4fa13be5434e04c05fe3fdf80
these two commits break descrambling on the same mux. Jaroslav should we log something or would you like to look at your changes b4?
Could you retry with the today's code? I fixed some reference counters there which affects simultaneous subscriptions on one mux.
I originaly verified this with the latest git master, after the changes for biss. Should I make a log with capmt or you need more?
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|cef20624489654d1eb71dddb04d6d0af1af045b9.
OK, OK. Fixed now.. Small typo, big impact (replaced || with && in a condition).
also this is working again as expected, thanks
I got exactly the same problem (althoug different logging) and I'm wondering when this release will be updated in the Debian unstable repo.
Currently I'm running - 3.9.2827~g477feab~wheezy
Cause I have no idea how I can easily test this and keep my configuration :-|
Thanks in advance
I got exactly the same problem (althoug different logging) and I'm wondering when this release/fix will be updated in the Debian unstable repo.
Currently I'm running - 3.9.2827~g477feab~wheezy
Cause I have no idea how I can easily test this and keep my configuration :-|
Thanks in advance
The 4.1.12 packages are available in unstable repos.
Not really related to the bug, but could you point me in the right direction, cause I only see the 3.9 version in the unstable repository.
Thanks in advance.
root@galadriel:~# apt-cache policy tvheadend
tvheadend:
Installed: 3.9.2827~g477feab~wheezy
Candidate: 3.9.2827~g477feab~wheezy
Version table:
*** 3.9.2827~g477feab~wheezy 0
500 http://apt.tvheadend.org/unstable/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
Tried it, but it keeps saying that this is the latest, I even tried it on a brand new machine, so it is not a cache problem.
Also available in: Atom
PDF