[dvblast-devel] Tuner issues - not DVR output, resetting

[Nuno Mota]

Hi Douchin,

Thank you very much for your feedback. I'm very inclined to agree with you
on this one. The only difference from all my tests is this ProCAM.

So the CAM stays in the middle of the TS data? If the CAM malfunctions then
there's no data reaching the user space (e.g. dvblast)?

Regards,
Nuno

2015-11-16 13:54 GMT+00:00 Doychin Dokov <dokov at silistra.tv>:

> The CAM, especially when talking about 3rd market non-official ones like
> PowerCAMs, can cause lots of issues. You can confirm/deny this by simply
> pulling it out.
>
> Also, please note that PowerCAMs have a limit on the TS datarate they can
> handle - on high-bitrate transponders they choke and do not work reliably.
>
> - D.
>
> 2015-11-16 15:52 GMT+02:00 Nuno Mota <mundumelga at gmail.com>:
>
>> "According to our observations, this happens when the tuner flaps a lot
>> (e.g. due to temporary bad signal) - then dvblast tries to retune (maybe)
>> too fast, which causes the demod lockup."
>>
>> I did find some odd things regarding this.
>>
>> I bought a couple of attenuators and started meddling with the signal.
>> The signal goes berserk when I lower signal values. But in all of my
>> tryouts, the moment I increase the signal levels everything seems to go
>> back to normal. The only times it doesn't, I don't have enough data passing
>> through the tuner and I see occasional errors but in a very low rate, which
>> makes me think that a lot of data is not being passed through the tuner.
>> But some is, error rate is not enough to trigger a reset and I don't get
>> any "no DVR output". In those cases a simple process restart is sufficient
>> to put everything back to normal.
>>
>> Now, in this case, not even a process restart is enough.
>>
>> I don't understand exactly how CAMs works in the frontend level, but
>> could it be that this CAM, in this situation is blocking the TS data for
>> some reason? Due perhaps to this tuner flaps?
>>
>> After a system reboot this is what I get. No transport errors or
>> discontinuities at all.
>>
>> status:
>> HAS_SIGNAL
>> HAS_CARRIER
>> HAS_VITERBI
>> HAS_SYNC
>> HAS_LOCK
>>
>> Bit error rate: 67108863
>> Signal strength: 47914
>> SNR: 54175
>>
>>
>>
>>
>> 2015-11-16 13:27 GMT+00:00 Doychin Dokov <dokov at silistra.tv>:
>>
>>> There's probably no issue with input signal. This  is a known issue with
>>> TBS cards when used with dvblast, the only workaround is to reboot the
>>> system when this happens.
>>>
>>> According to our observations, this happens when the tuner flaps a lot
>>> (e.g. due to temporary bad signal) - then dvblast tries to retune (maybe)
>>> too fast, which causes the demod lockup.
>>>
>>> - D.
>>>
>>> 2015-11-16 15:25 GMT+02:00 Nedveďal Marián <neiveial at stonline.sk>:
>>>
>>>> Hi,
>>>>
>>>> you got great value BER. This indicates an error in the signal.
>>>>
>>>> ----- Original Message -----
>>>> Od: Nuno Mota <mundumelga at gmail.com>
>>>> Dátum: Monday, November 16, 2015 1:18 pm
>>>> Predmet: [dvblast-devel] Tuner issues - not DVR output, resetting
>>>> Komu: Mailing list for DVBlast developers <dvblast-devel at videolan.org>
>>>>
>>>> >
>>>> Hi,
>>>>
>>>> >
>>>> I'm having a lot of issues with a TBS card. I'm not sure what's wrong.
>>>> There's this warning that there's no DVR output. What does this mean
>>>> exactly?
>>>>
>>>> >
>>>> Besides that, there's a CAM in it. I don't know why but it opens twice
>>>> all the times. This is in a loop right now. I've never seen this before.
>>>>
>>>> >
>>>> ADAPTER1[1657]: warning: no DVR output, resetting
>>>> ADAPTER1[1657]: debug: frequency 12129000 is in Ku-band (higher)
>>>> ADAPTER1[1657]: debug: configuring LNB to v=13 p=0 satnum=3
>>>> uncommitted=1
>>>> ADAPTER1[1657]: debug: tuning DVB-S frontend to f=12129000
>>>> srate=27500000 inversion=-1 fec=999 rolloff=35 modulation=legacy pilot=-1
>>>> mis=0
>>>> ADAPTER1[1657]: debug: closing ConditionalAccess session (3)
>>>> ADAPTER1[1657]: debug: frontend has acquired signal
>>>> ADAPTER1[1657]: debug: frontend has acquired carrier
>>>> ADAPTER1[1657]: debug: frontend has acquired stable FEC
>>>> ADAPTER1[1657]: debug: frontend has acquired sync
>>>> ADAPTER1[1657]: info: frontend has acquired lock
>>>> ADAPTER1[1657]: debug: - Bit error rate: 67108863
>>>> ADAPTER1[1657]: debug: - Signal strength: 67091451
>>>> ADAPTER1[1657]: debug: - SNR: 67108863
>>>> ADAPTER1[1657]: debug: CI slot 0 is active
>>>> ADAPTER1[1657]: debug: opening ResourceManager session (1)
>>>> ADAPTER1[1657]: debug: opening ApplicationInformation session (2)
>>>> ADAPTER1[1657]: info: CAM: PCAM V5.2, 01, 02CA, 3000
>>>> ADAPTER1[1657]: debug: opening ConditionalAccess session (3)
>>>> ADAPTER1[1657]: debug: CA system IDs supported by the application :
>>>> ADAPTER1[1657]: debug: - 0x100
>>>> ADAPTER1[1657]: debug: closing ConditionalAccess session (3)
>>>> ADAPTER1[1657]: debug: opening ConditionalAccess session (3)
>>>> ADAPTER1[1657]: debug: CA system IDs supported by the application :
>>>> ADAPTER1[1657]: debug: - 0x100
>>>> ADAPTER1[1657]: warning: no DVR output, resetting
>>>>
>>>> >
>>>> Has anyone ever seen this behaviour before? Is the CAM perhaps choking
>>>> the TS stream?
>>>> >
>>>>
>>>> >
>>>> Regards,
>>>> Nuno
>>>>
>>>> > > _______________________________________________
>>>> > dvblast-devel mailing list
>>>> > dvblast-devel at videolan.org
>>>> > https://mailman.videolan.org/listinfo/dvblast-devel
>>>> _______________________________________________
>>>> dvblast-devel mailing list
>>>> dvblast-devel at videolan.org
>>>> https://mailman.videolan.org/listinfo/dvblast-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dvblast-devel mailing list
>>> dvblast-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/dvblast-devel
>>>
>>>
>>
>> _______________________________________________
>> dvblast-devel mailing list
>> dvblast-devel at videolan.org
>> https://mailman.videolan.org/listinfo/dvblast-devel
>>
>>
>
> _______________________________________________
> dvblast-devel mailing list
> dvblast-devel at videolan.org
> https://mailman.videolan.org/listinfo/dvblast-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/dvblast-devel/attachments/20151116/830151af/attachment-0001.html>