<div dir="ltr"><span style="font-size:12.8px">"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."</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I did find some odd things regarding this.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Now, in this case, not even a process restart is enough.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">After a system reboot this is what I get. No transport errors or discontinuities at all. </span></div><div><span style="font-size:12.8px"><br></span></div><div><div style=""><span style="font-size:12.8px">status:</span></div><div style=""><span style="font-size:12.8px">HAS_SIGNAL</span></div><div style=""><span style="font-size:12.8px">HAS_CARRIER</span></div><div style=""><span style="font-size:12.8px">HAS_VITERBI</span></div><div style=""><span style="font-size:12.8px">HAS_SYNC</span></div><div style=""><span style="font-size:12.8px">HAS_LOCK</span></div><div style=""><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px">Bit error rate: 67108863</span></div><div style=""><span style="font-size:12.8px">Signal strength: 47914</span></div><div style=""><span style="font-size:12.8px">SNR: 54175</span></div><div style="font-size:12.8px"><br></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-16 13:27 GMT+00:00 Doychin Dokov <span dir="ltr"><<a href="mailto:dokov@silistra.tv" target="_blank">dokov@silistra.tv</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- D.</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-11-16 15:25 GMT+02:00 Nedveďal Marián <span dir="ltr"><<a href="mailto:neiveial@stonline.sk" target="_blank">neiveial@stonline.sk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br><span lang="en"><span>you got</span> <span>great value BER</span></span>. <span lang="en"><span>This indicates</span> <span>an error in the</span> <span>signal.</span></span><br><br>----- Original Message -----<br>Od: Nuno Mota <<a href="mailto:mundumelga@gmail.com" target="_blank">mundumelga@gmail.com</a>><br>Dátum: Monday, November 16, 2015 1:18 pm<br>Predmet: [dvblast-devel] Tuner issues - not DVR output, resetting<br>Komu: Mailing list for DVBlast developers <<a href="mailto:dvblast-devel@videolan.org" target="_blank">dvblast-devel@videolan.org</a>><br><br>> <div dir="ltr"><div>Hi,</div><div><br>> </div><div>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?</div><div><br>> </div><div>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.</div><div><br>> </div><div><div>ADAPTER1[1657]: warning: no DVR output, resetting</div><div>ADAPTER1[1657]: debug: frequency 12129000 is in Ku-band (higher)</div><div>ADAPTER1[1657]: debug: configuring LNB to v=13 p=0 satnum=3 uncommitted=1</div><div>ADAPTER1[1657]: debug: tuning DVB-S frontend to f=12129000 srate=27500000 inversion=-1 fec=999 rolloff=35 modulation=legacy pilot=-1 mis=0</div><div>ADAPTER1[1657]: debug: closing ConditionalAccess session (3)</div><div>ADAPTER1[1657]: debug: frontend has acquired signal</div><div>ADAPTER1[1657]: debug: frontend has acquired carrier</div><div>ADAPTER1[1657]: debug: frontend has acquired stable FEC</div><div>ADAPTER1[1657]: debug: frontend has acquired sync</div><div>ADAPTER1[1657]: info: frontend has acquired lock</div><div>ADAPTER1[1657]: debug: - Bit error rate: 67108863</div><div>ADAPTER1[1657]: debug: - Signal strength: 67091451</div><div>ADAPTER1[1657]: debug: - SNR: 67108863</div><div>ADAPTER1[1657]: debug: CI slot 0 is active</div><div>ADAPTER1[1657]: debug: opening ResourceManager session (1)</div><div>ADAPTER1[1657]: debug: opening ApplicationInformation session (2)</div><div>ADAPTER1[1657]: info: CAM: PCAM V5.2, 01, 02CA, 3000</div><div>ADAPTER1[1657]: debug: opening ConditionalAccess session (3)</div><div>ADAPTER1[1657]: debug: CA system IDs supported by the application :</div><div>ADAPTER1[1657]: debug: - 0x100</div><div>ADAPTER1[1657]: debug: closing ConditionalAccess session (3)</div><div>ADAPTER1[1657]: debug: opening ConditionalAccess session (3)</div><div>ADAPTER1[1657]: debug: CA system IDs supported by the application :</div><div>ADAPTER1[1657]: debug: - 0x100</div><div>ADAPTER1[1657]: warning: no DVR output, resetting</div></div><div><br>> </div><div>Has anyone ever seen this behaviour before? Is the CAM perhaps choking the TS stream?<br>> </div><div><br>> </div><div>Regards,</div><div>Nuno</div></div><br>> > _______________________________________________<br>> dvblast-devel mailing list<br>> <a href="mailto:dvblast-devel@videolan.org" target="_blank">dvblast-devel@videolan.org</a><br>> <a href="https://mailman.videolan.org/listinfo/dvblast-devel" target="_blank">https://mailman.videolan.org/listinfo/dvblast-devel</a>
<br>_______________________________________________<br>
dvblast-devel mailing list<br>
<a href="mailto:dvblast-devel@videolan.org" target="_blank">dvblast-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/dvblast-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/dvblast-devel</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
dvblast-devel mailing list<br>
<a href="mailto:dvblast-devel@videolan.org">dvblast-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/dvblast-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/dvblast-devel</a><br>
<br></blockquote></div><br></div>