On 01.12.2010 16:28, Halim Sahin wrote:
> Hi,
> On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
>> On 01.09.2009 23:38, Simon Baxter wrote:
>>>>> I was afraid that might be the suggestion!
>>>>>
>>>>> It seems pretty random when the CAM will crash. It is possible it's
>>>>> only on certain channels, and only one of the CAMs - it only happens
>>>>> very rarely....
>>>>
>>>> So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
>>>> and exactly one of them sometimes fails, right?
>>>>
>>>> Have you tried swapping the two CAMs?
>>>> This should tell us whether the problem is with the CAM or with
>>>> the CI adapter.
>>>>
>>>> Klaus
>>>
>>> I've discovered this happens to both CAMs, so it's either not a hardware
>>> issue, or both CAMs are affected.
>>>
>>> Managed to capture the following logs prior to the CAM dropping from
>>> "AlphaCrypt" to "CAM Ready" (with no decrypting)
>>>
>>> Sep 2 08:17:21 freddy vdr: [27702] switching to channel 11
>>> Sep 2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702,
>>> tid=1150)
>>> Sep 2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
>>> Sep 2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702,
>>> tid=6564)
>>> Sep 2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended
>>> (pid=27702, tid=1152)
>>> Sep 2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
>>> Sep 2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended
>>> (pid=27702, tid=1151)
>>> Sep 2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started
>>> (pid=27702, tid=6565)
>>> Sep 2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started
>>> (pid=27702, tid=6566)
>>> Sep 2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
>>> Sep 2 08:17:34 freddy vdr: [27702] switching to channel 1
>>> Sep 2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702,
>>> tid=6564)
>>> Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
>>> continuity errors
>>> Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
>>> continuity errors
>>> Sep 2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
>>> Sep 2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702,
>>> tid=6567)
>>> Sep 2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended
>>> (pid=27702, tid=6566)
>>> Sep 2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
>>> Sep 2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended
>>> (pid=27702, tid=6565)
>>> Sep 2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started
>>> (pid=27702, tid=6568)
>>> Sep 2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started
>>> (pid=27702, tid=6569)
>>> Sep 2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702,
>>> tid=6567)
> > > Sep 2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread ended
>>> (pid=27702, tid=6569)
>>> Sep 2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
>>> Sep 2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended
>>> (pid=27702, tid=6568)
>>> Sep 2 08:17:39 freddy vdr: [27702] switching to channel 1
>>> Sep 2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
>>> Sep 2 08:17:39 freddy vdr: [27702] info: Channel not available!
>>> Sep 2 08:17:41 freddy vdr: [27702] switching to channel 9
>>> Sep 2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702,
>>> tid=6570)
>>> Sep 2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
>>> Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep 2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep 2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
>>> initialised successfully
>>
>> This looks more like a driver bug to me.
>
> Well maybe but unfortunately responds to my mails in linux-dvb /
> linux-media mailinglist for that problem.
>
> @Klaus:
> If that problem happens, a manual reset of the cam under vdr's
> menu->settings->ci brings the cam back.
>
> What about trying to reset a cam automatically when it's Status is !=
> msReady?
>
> Like this:
> diff --git a/device.c b/device.c
> index 681049b..7904de2 100644
> --- a/device.c
> +++ b/device.c
> @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView
> if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
> for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
> SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
> + if (CamSlot->ModuleStatus() == msPresent)
> + CamSlot->Reset();
> if (CamSlot->ModuleStatus() == msReady) {
> if (CamSlot->ProvidesCa(Channel->Caids())) {
> if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
Have you tested this?
Did it actually work?
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
