Project

General

Profile

Bug #2846

capmt fails when descrambling on multiple adapters and same mux

Added by Sebastian K. over 9 years ago. Updated over 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2015-05-15
Due date:
% Done:

100%

Estimated time:
Found in version:
3.9.2849~gbdd0eb6-dirty
Affected Versions:

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

History

#1

Updated by B C over 9 years ago

update oscam, this was fixed in >= 10656

#2

Updated by Sebastian K. over 9 years ago

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

#3

Updated by B C over 9 years ago

you are right, seems to be introduced recently, currently trying to find the commit that caused it

#4

Updated by B C over 9 years ago

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?

#5

Updated by Jaroslav Kysela over 9 years ago

Could you retry with the today's code? I fixed some reference counters there which affects simultaneous subscriptions on one mux.

#6

Updated by B C over 9 years ago

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?

#7

Updated by Jaroslav Kysela over 9 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|cef20624489654d1eb71dddb04d6d0af1af045b9.

#8

Updated by Jaroslav Kysela over 9 years ago

OK, OK. Fixed now.. Small typo, big impact (replaced || with && in a condition).

#9

Updated by B C over 9 years ago

also this is working again as expected, thanks

#10

Updated by Rob Maas over 9 years ago

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

#11

Updated by Rob Maas over 9 years ago

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

#12

Updated by Jaroslav Kysela over 9 years ago

The 4.1.12 packages are available in unstable repos.

#13

Updated by Rob Maas over 9 years ago

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

#14

Updated by B C over 9 years ago

apt-get update ???

#15

Updated by Rob Maas over 9 years ago

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