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

[Nuno Mota]

Thank you. I'll try to debug this a little bit more then.

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

> 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
>>
>>
>
> _______________________________________________
> 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/c9556d4c/attachment-0001.html>