I have uploaded a patch against VDR 1.3.36 to
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.36-multicamtest.diff
which is a first attempt to allow multiple channels to be decrypted at the same time, provided the CAM supports this.
There is currently no test whether this operation is possible or how many channels a given CAM can decrypt simultaneously, so use this with extreme care! This is just for testing!!
With my AlphaCrypt CAM I have successfully tested 3 parallel recordings of encrypted channels on the same transponder.
Now the reason why I am providing this patch is that I'd like to invite you folks to try this out and maybe see what might be wrong here. The problem is that whenever a channel is added or removed from the CA_PMT data, there are distortions in the recordings.
What I'm doing is to send either a single CA_PMT object (marked as CPLM_ONLY), in case there is only one channel to decrypt, or a list of such objects (CPLM_FIRST/CPLM_MORE/CPLM_LAST), in case there is more than one channel.
The standard says:
When the CA application receives a CA_PMT with a new list of programmes, it starts analysing the new list and usually stops the descrambling of the programmes of the previous list, except if it detects that this new list contains programme(s) or elementary stream(s) of the previous list. In this case, it should continue the descrambling of this programme or elementary stream without interruption visible by the user. For example, the only way to remove a programme from the list consists in sending a new list without the programme. In this case, the module should continue the descrambling of the other programmes of the list without interruption. Another typical example is when the host sends a new CA_PMT because the version_number of the PMT has changed. This change may not affect the CA operation and in this case, the module should not interrupt the descrambling.
So from this I would expect no distortions to happen when adding/removing channels from the list of CA_PMT objects.
Now there is either a flaw in my code, or my CAM just doesn't work as required by the standard.
Any hints here are appreciated.
Klaus
Klaus Schmidinger wrote:
I have uploaded a patch against VDR 1.3.36 to
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.36-multicamtest.diff
which is a first attempt to allow multiple channels to be decrypted at the same time, provided the CAM supports this.
There is currently no test whether this operation is possible or how many channels a given CAM can decrypt simultaneously, so use this with extreme care! This is just for testing!!
With my AlphaCrypt CAM I have successfully tested 3 parallel recordings of encrypted channels on the same transponder.
Now the reason why I am providing this patch is that I'd like to invite you folks to try this out and maybe see what might be wrong here. The problem is that whenever a channel is added or removed from the CA_PMT data, there are distortions in the recordings. ...
Meanwhile I got a message from Mascom (the manufacturer of the AlphaCrypt CAM) and they told me that the current CAM firmware actually has a problem there, and that it will be fixed in a future version.
Klaus
Klaus Schmidinger wrote:
Meanwhile I got a message from Mascom (the manufacturer of the AlphaCrypt CAM) and they told me that the current CAM firmware actually has a problem there, and that it will be fixed in a future version.
Wich one is the defective firmware version exactly? I am still running version 2.03, but thought about updating. Currently there is version 3.03 as an update available one Mascom's web page and 3.05 over air on ORF.
André.
André Weidemann wrote:
Klaus Schmidinger wrote:
Meanwhile I got a message from Mascom (the manufacturer of the AlphaCrypt CAM) and they told me that the current CAM firmware actually has a problem there, and that it will be fixed in a future version.
Wich one is the defective firmware version exactly? I am still running version 2.03, but thought about updating. Currently there is version 3.03 as an update available one Mascom's web page and 3.05 over air on ORF.
Version 3.05 still has the problem.
Klaus
On Sun, 2005-11-13 at 15:16 +0100, Klaus Schmidinger wrote:
Now the reason why I am providing this patch is that I'd like to invite you folks to try this out and maybe see what might be wrong here. The problem is that whenever a channel is added or removed from the CA_PMT data, there are distortions in the recordings.
I tested this patch with my single Technotrend DVB-C Premium 2.1 card + Conax 4.00e CAM and "not-so-vanilla" vdr version, with vdr-1.3.36 and dozen of plugins and patches to those.
So from this I would expect no distortions to happen when adding/removing channels from the list of CA_PMT objects.
Now there is either a flaw in my code, or my CAM just doesn't work as required by the standard.
Any hints here are appreciated.
Klaus
Not that I can give you any hint, only report what happened...
Recording another and watching another encrypted channel at the same time is possible, but gives very much same distortions as you described. Recording is jumpy and the livestream hangs in ~1-2 second periods.
Hope that I can help somehow.
--Mikko
Mikko Salo wrote:
On Sun, 2005-11-13 at 15:16 +0100, Klaus Schmidinger wrote:
Now the reason why I am providing this patch is that I'd like to invite you folks to try this out and maybe see what might be wrong here. The problem is that whenever a channel is added or removed from the CA_PMT data, there are distortions in the recordings.
I tested this patch with my single Technotrend DVB-C Premium 2.1 card + Conax 4.00e CAM and "not-so-vanilla" vdr version, with vdr-1.3.36 and dozen of plugins and patches to those.
So from this I would expect no distortions to happen when adding/removing channels from the list of CA_PMT objects.
Now there is either a flaw in my code, or my CAM just doesn't work as required by the standard.
Any hints here are appreciated.
Klaus
Not that I can give you any hint, only report what happened...
Recording another and watching another encrypted channel at the same time is possible, but gives very much same distortions as you described. Recording is jumpy and the livestream hangs in ~1-2 second periods.
Hope that I can help somehow.
Hi Mikko,
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;
at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Yes, I have only one Conax CAM in a CI with two slots. Removing that line fixed live stream. I really hoped it would fix recording too, but no...darn! :(
I noticed that if I'm recording encrypted channel and don't change channel but switch to replay mode of that at the same time recording channel, it gets distorted.
Only when I record and watch that same channel I get no distortions in recordings, same as if I'm without this patch :)
--Mikko
Mikko Salo wrote:
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Yes, I have only one Conax CAM in a CI with two slots. Removing that line fixed live stream. I really hoped it would fix recording too, but no...darn! :(
I noticed that if I'm recording encrypted channel and don't change channel but switch to replay mode of that at the same time recording channel, it gets distorted.
Only when I record and watch that same channel I get no distortions in recordings, same as if I'm without this patch :)
--Mikko
Are you getting distortions in the recording only when you switch live channels or start/stop a recording, or all the time, even if you don't do anything?
In the first case this could be a problem with your CAM not implementing the CA_PMT FIRST/MORE/LAST handling correctly. In the latter case I currently have no idea what might be wrong there.
Klaus
On Sat, 2005-11-19 at 10:43 +0100, Klaus Schmidinger wrote:
Mikko Salo wrote:
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Yes, I have only one Conax CAM in a CI with two slots. Removing that line fixed live stream. I really hoped it would fix recording too, but no...darn! :(
I noticed that if I'm recording encrypted channel and don't change channel but switch to replay mode of that at the same time recording channel, it gets distorted.
Only when I record and watch that same channel I get no distortions in recordings, same as if I'm without this patch :)
--Mikko
Are you getting distortions in the recording only when you switch live channels or start/stop a recording, or all the time, even if you don't do anything?
In the first case this could be a problem with your CAM not implementing the CA_PMT FIRST/MORE/LAST handling correctly. In the latter case I currently have no idea what might be wrong there.
Klaus
Heres the test cases I made after that cCiHandler fix:
Live | Recording | Play | Recording | Live | | | | distortions | distortions | -------------------------------------------------------------------- TV1000 | none | none | none | none | TV1000 | TV1000 | none | none | none | TV1000 | TV1000 | TV1000 | yes | (1 | (2 TV1000 | TV1000 action | none | yes | none | (3
(1 when card is in replay mode, not possible(?) (2 switched from live to play mode, still recording at background (3 every channel switch caused distortions in recording, tested with many channels from same transponder.
These are the cases that I could think of, did I miss someone? I hope that ascii table dont get messed up and this clears things up :)
system specs: Asus Pundit-S - Pentium 4 2.4GHz - Seagate 160Gb HD - 512M DDR - Technotrend Premium 2.1 DVB-C + 261d Firmware - Technotrend 3.5" CI - Conax 4.00e CAM
--Mikko
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
Mikko Salo wrote:
On Sun, 2005-11-13 at 15:16 +0100, Klaus Schmidinger wrote:
Now the reason why I am providing this patch is that I'd like to invite you folks to try this out and maybe see what might be wrong here. The problem is that whenever a channel is added or removed from the CA_PMT data, there are distortions in the recordings.
I tested this patch with my single Technotrend DVB-C Premium 2.1 card + Conax 4.00e CAM and "not-so-vanilla" vdr version, with vdr-1.3.36 and dozen of plugins and patches to those.
So from this I would expect no distortions to happen when adding/removing channels from the list of CA_PMT objects.
Now there is either a flaw in my code, or my CAM just doesn't work as required by the standard.
Any hints here are appreciated.
Klaus
Not that I can give you any hint, only report what happened...
Recording another and watching another encrypted channel at the same time is possible, but gives very much same distortions as you described. Recording is jumpy and the livestream hangs in ~1-2 second periods.
Hope that I can help somehow.
Hi Mikko,
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Hi and thank you Klaus
With this change I am recording now three encrypted channels from Canal+ Local subsciption and watch some else in the same time. It did take some time system to stabilize, when I started these recordings almost in the same time, vdr did restart two times befor to get stabilized. With two recordings in the same time works steady. When I now change channel, I get many messages like this:
Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 208 bytes to sync on next audio frame Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14047]: cAudioRepacker(0xC0): skipped 328 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14060]: cAudioRepacker(0xC0): skipped 196 bytes to sync on next audio frame
My setup:
Gentoo Linux with 2.6.13-gentoo-r3 kernel dvb-drivers from kernel with recent patch of Andrew de Quincey to ci-handling added manually editing Nexus 2.1 dvb-s with CI and "CAM: Conax 4.00e, 01, 0B00, 04B1" Terratec-Cinergy dvb-c 1200
Timo Helkiö
timo wrote:
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
Hi Mikko,
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Hi and thank you Klaus
With this change I am recording now three encrypted channels from Canal+ Local subsciption and watch some else in the same time. It did take some time system to stabilize, when I started these recordings almost in the same time, vdr did restart two times befor to get stabilized. With two recordings in the same time works steady. When I now change channel, I get many messages like this: Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 208 bytes to sync on next audio frame Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14047]: cAudioRepacker(0xC0): skipped 328 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14060]: cAudioRepacker(0xC0): skipped 196 bytes to sync on next audio frame My setup: Gentoo Linux with 2.6.13-gentoo-r3 kernel dvb-drivers from kernel with recent patch of Andrew de Quincey to ci-handling added manually editing Nexus 2.1 dvb-s with CI and "CAM: Conax 4.00e, 01, 0B00, 04B1" Terratec-Cinergy dvb-c 1200 Timo Helkiö
Hi Timo,
when you record one encrypted channel and switch the live channel between some other encrypted channels on the same transponder, do you get distortions in the _recording_ at the times when you switched the live channel? This is currently my main concern. I know that the AlphaCrypt CAMs have problems there (which will hopefully be fixed in a future software update for those), and was told that the Aston CAMs don't have such problems (that was somebody from aston-france.com telling me that, so it's not an actual test report). So I wonder whether the Conax CAMs work as expected...
As for the cAudioRepacker messages: a full featured DVB card can only handle a limited number of channels at the same time (be it encrypted or not), so maybe it is just too much for it. You could try the same scenario with unencrypted channels to see whether the messages appear there, too.
Klaus
On Sat, 2005-11-19 at 16:09 +0100, Klaus Schmidinger wrote:
timo wrote:
On Fri, 2005-11-18 at 14:49 +0100, Klaus Schmidinger wrote:
Hi Mikko,
if you have only one CAM in a CI adapter with two slots, then the line
newCaSupport = true;at the end of cCiHandler::SendCaPmt() could be triggering the jumpy live stream. Could you please try without this line?
Klaus
Hi and thank you Klaus
With this change I am recording now three encrypted channels from Canal+ Local subsciption and watch some else in the same time. It did take some time system to stabilize, when I started these recordings almost in the same time, vdr did restart two times befor to get stabilized. With two recordings in the same time works steady. When I now change channel, I get many messages like this: Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 208 bytes to sync on next audio frame Nov 19 16:42:35 piano vdr[14066]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14047]: cAudioRepacker(0xC0): skipped 328 bytes to sync on next audio frame Nov 19 16:42:36 piano vdr[14060]: cAudioRepacker(0xC0): skipped 196 bytes to sync on next audio frame My setup: Gentoo Linux with 2.6.13-gentoo-r3 kernel dvb-drivers from kernel with recent patch of Andrew de Quincey to ci-handling added manually editing Nexus 2.1 dvb-s with CI and "CAM: Conax 4.00e, 01, 0B00, 04B1" Terratec-Cinergy dvb-c 1200 Timo HelkiöHi Timo,
when you record one encrypted channel and switch the live channel between some other encrypted channels on the same transponder, do you get distortions in the _recording_ at the times when you switched the live channel? This is currently my main concern. I know that the AlphaCrypt CAMs have problems there (which will hopefully be fixed in a future software update for those), and was told that the Aston CAMs don't have such problems (that was somebody from aston-france.com telling me that, so it's not an actual test report). So I wonder whether the Conax CAMs work as expected...
As for the cAudioRepacker messages: a full featured DVB card can only handle a limited number of channels at the same time (be it encrypted or not), so maybe it is just too much for it. You could try the same scenario with unencrypted channels to see whether the messages appear there, too.
Klaus
Hi
Yes, I can see distortions, as a mather of fact there is jump in recording and screen after that is mixture of previuos "old" stream and new one with distortions between them.
Timo
-
André Weidemann -
Klaus Schmidinger -
Mikko Salo -
timo