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

[Doychin Dokov]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/dvblast-devel/attachments/20151116/79712051/attachment.html>