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

[Doychin Dokov]

Depends on the device itself, but in case of TBS cards - yes, the whole TS
is routed via the CAM. Depending on encoding you use, I'll suggest you
replace the PowerCAMs with AlphaCrypt Pro.

- D.

2015-11-16 16:19 GMT+02:00 Nuno Mota <mundumelga at gmail.com>:

> 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
>>
>>
>
> _______________________________________________
> 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/45a16983/attachment.html>