TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.

TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.

[Oliver Schinagl]

Hi list,

I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a 
year now. Running gentoo 64bit tracking the ~amd64 branch (that only get 
bi-monthly upgraded) I've been always more or less up to date.

This card however has never properly worked. I've been running vdr 1.6.* 
since that is what's stably in gentoo. Whilst writing this down I 
realized I still have to test me-tv to double check my findings.

Some background info. Here in NL we have 4 FTA channels and about 20 
conax encrypted channels that the CAM in the CI module decrypts. I have 
two smartcards, of which one is only in active use at the moment.

When changing channels between the FTA channels, the first 'bug' occurs. 
Somtimes (not predictably or anything, about 50% of the channel changes) 
sound stutters the first few seconds, upto 30 seconds sometimes. It 
sounds almost if the sound is being fed through some sort of PWM, that 
slowly catches up. So first you hear 1 second of audio, 3 seconds of 
nothing, then 1 second of audio again, then 2 seconds of nothing etc. 
This audio delay is random. E.g. sometimes it stutters for about 30 
seconds while it has a hard time to catch up, other times the audio 
needs only 2 or 3 seconds to catch up. Very occasionally it instantly 
works right. The stuttering appears to be worse on encrypted channels.

Encrypted channels has the additional annoyance, that quote often, an 
entire channel is not available. That is, every channel in its bouqet. 
Simply waiting on that channel for about a minute or two, mysteriously 
brings the unavailable channel up. Allthough it 'feels' like changing 
channel helps this fix faster, it's just a placebo effect if you ask me ;)

I cannot safely say that the same skipping happens to the video, I have 
not noticed it really. I have checked signal strength etc and though the 
strength is only at 55%, the SNR is at 99% quite stable and the BER 
(unrecoverable errors? are at 0). If for some reason there is 
interferance, bad whether, blocked antenna, then the BER goes up 
followed by distorted imagery and with really bad signal bad audio as 
well (humans are more sensitive to bad audio iirc).

I'm not sure what to profile, where to enable debugging, what logs to 
check or what to do to help 'fix' this.

lspci output:
00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
              Subsystem: Technotrend Systemtechnik GmbH DVB T-1500
              Flags: bus master, medium devsel, latency 32, IRQ 18
              Memory at f0162000 (32-bit, non-prefetchable) [size=512]
              Kernel drive in use: budget_ci dvb

/proc/interrupts
18:                499    107651  IO-APIC-fasteoi   saa7146  (0)

Tuner: tda10046h dvb-t, firmware revision 20


Thank you for your time,
oliver

Re: TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.

[Oliver Schinagl]

On 17-07-12 10:30, Oliver Schinagl wrote:
> Hi list,
>
> I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a 
> year now. Running gentoo 64bit tracking the ~amd64 branch (that only 
> get bi-monthly upgraded) I've been always more or less up to date.
>
> This card however has never properly worked. I've been running vdr 
> 1.6.* since that is what's stably in gentoo. Whilst writing this down 
> I realized I still have to test me-tv to double check my findings.
>
> Some background info. Here in NL we have 4 FTA channels and about 20 
> conax encrypted channels that the CAM in the CI module decrypts. I 
> have two smartcards, of which one is only in active use at the moment.
>
> When changing channels between the FTA channels, the first 'bug' 
> occurs. Somtimes (not predictably or anything, about 50% of the 
> channel changes) sound stutters the first few seconds, upto 30 seconds 
> sometimes. It sounds almost if the sound is being fed through some 
> sort of PWM, that slowly catches up. So first you hear 1 second of 
> audio, 3 seconds of nothing, then 1 second of audio again, then 2 
> seconds of nothing etc. This audio delay is random. E.g. sometimes it 
> stutters for about 30 seconds while it has a hard time to catch up, 
> other times the audio needs only 2 or 3 seconds to catch up. Very 
> occasionally it instantly works right. The stuttering appears to be 
> worse on encrypted channels.
>
> Encrypted channels has the additional annoyance, that quote often, an 
> entire channel is not available. That is, every channel in its bouqet. 
> Simply waiting on that channel for about a minute or two, mysteriously 
> brings the unavailable channel up. Allthough it 'feels' like changing 
> channel helps this fix faster, it's just a placebo effect if you ask 
> me ;)
>
> I cannot safely say that the same skipping happens to the video, I 
> have not noticed it really. I have checked signal strength etc and 
> though the strength is only at 55%, the SNR is at 99% quite stable and 
> the BER (unrecoverable errors? are at 0). If for some reason there is 
> interferance, bad whether, blocked antenna, then the BER goes up 
> followed by distorted imagery and with really bad signal bad audio as 
> well (humans are more sensitive to bad audio iirc).
>
> I'm not sure what to profile, where to enable debugging, what logs to 
> check or what to do to help 'fix' this.
>
> lspci output:
> 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
>              Subsystem: Technotrend Systemtechnik GmbH DVB T-1500
>              Flags: bus master, medium devsel, latency 32, IRQ 18
>              Memory at f0162000 (32-bit, non-prefetchable) [size=512]
>              Kernel drive in use: budget_ci dvb
>
> /proc/interrupts
> 18:                499    107651  IO-APIC-fasteoi   saa7146  (0)
>
> Tuner: tda10046h dvb-t, firmware revision 20
>
>
> Thank you for your time,
> oliver
P.S. I forgot to mention, that once tuned to a channel, I can receive 
(and decode) it fine for many hours. I think the longest I had one 
channel up was about 8 hours or so without issue. A dvb-t radio channel 
(thus not dab) i had up for even longer, so once it goes, it goes on 
happily forever!

Re: TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.

[Oliver Schinagl]

On 07/17/12 11:53, Oliver Schinagl wrote:
> On 17-07-12 10:30, Oliver Schinagl wrote:
>> Hi list,
>>
>> I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a
>> year now. Running gentoo 64bit tracking the ~amd64 branch (that only
>> get bi-monthly upgraded) I've been always more or less up to date.
>>
>> This card however has never properly worked. I've been running vdr
>> 1.6.* since that is what's stably in gentoo. Whilst writing this down
>> I realized I still have to test me-tv to double check my findings.
>>
>> Some background info. Here in NL we have 4 FTA channels and about 20
>> conax encrypted channels that the CAM in the CI module decrypts. I
>> have two smartcards, of which one is only in active use at the moment.
>>
>> When changing channels between the FTA channels, the first 'bug'
>> occurs. Somtimes (not predictably or anything, about 50% of the
>> channel changes) sound stutters the first few seconds, upto 30 seconds
>> sometimes. It sounds almost if the sound is being fed through some
>> sort of PWM, that slowly catches up. So first you hear 1 second of
>> audio, 3 seconds of nothing, then 1 second of audio again, then 2
>> seconds of nothing etc. This audio delay is random. E.g. sometimes it
>> stutters for about 30 seconds while it has a hard time to catch up,
>> other times the audio needs only 2 or 3 seconds to catch up. Very
>> occasionally it instantly works right. The stuttering appears to be
>> worse on encrypted channels.
>>
>> Encrypted channels has the additional annoyance, that quote often, an
>> entire channel is not available. That is, every channel in its bouqet.
>> Simply waiting on that channel for about a minute or two, mysteriously
>> brings the unavailable channel up. Allthough it 'feels' like changing
>> channel helps this fix faster, it's just a placebo effect if you ask
>> me ;)
>>
>> I cannot safely say that the same skipping happens to the video, I
>> have not noticed it really. I have checked signal strength etc and
>> though the strength is only at 55%, the SNR is at 99% quite stable and
>> the BER (unrecoverable errors? are at 0). If for some reason there is
>> interferance, bad whether, blocked antenna, then the BER goes up
>> followed by distorted imagery and with really bad signal bad audio as
>> well (humans are more sensitive to bad audio iirc).
>>
>> I'm not sure what to profile, where to enable debugging, what logs to
>> check or what to do to help 'fix' this.
>>
>> lspci output:
>> 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
>> Subsystem: Technotrend Systemtechnik GmbH DVB T-1500
>> Flags: bus master, medium devsel, latency 32, IRQ 18
>> Memory at f0162000 (32-bit, non-prefetchable) [size=512]
>> Kernel drive in use: budget_ci dvb
>>
>> /proc/interrupts
>> 18: 499 107651 IO-APIC-fasteoi saa7146 (0)
>>
>> Tuner: tda10046h dvb-t, firmware revision 20
>>
>>
>> Thank you for your time,
>> oliver
> P.S. I forgot to mention, that once tuned to a channel, I can receive
> (and decode) it fine for many hours. I think the longest I had one
> channel up was about 8 hours or so without issue. A dvb-t radio channel
> (thus not dab) i had up for even longer, so once it goes, it goes on
> happily forever!
> --

After spending about 5? Hours compiling Kaffeine and it's dependancies, 
I gave that a go. (me-tv does not support CAM's). While tuning went a 
little iffy at the start, not sure why, signal kept dropping and some 
SNR spikes, I managed to get all my channels tuned. Kaffeine is much 
much slower when changing channels. Takes about 2-4 seconds (haven't 
properly timed it). Kaffeine however never failed to tune a channel and 
sound always started properly.

Btw, I noticed the sound stuttering seems somewhat buffering related, it 
the sound that IS heard, is often the almost the same 'sample', but does 
slowly move forward in time.

I can immagine that Kaffeine does some really smart things VDR doesn't 
do, but even the slow channel change doesn't explain why VDR often fails 
to properly tune.


So it seems that the hardware is working quite well albeit slow on 
channel changing (in kaffeine anyway). I have tried a later version of 
VDR, as the whole reason i'm digging into this is, is because I was 
trying to get openbricks/geexbox/VDR/xbmc working where VDR is one of 
the development versions.

So anybody have any idea where to start finding the cause? Is it really 
VDR? Or is it something in the driver afterall? Anybody can share their 
experiences with a hardware! CAM?

P.S. I'm supprised about the bad signal, as I live about 500meters from 
the transmitter ...

Oliver