I've recently started having problems with my picture (breaks up/stops altogether). In trying to diagnose the problem I see this from vdr (1.7.15) when starting vdr-sxfe (remote) from xineliboutput (cvs from 4/9/10):
Sep 5 21:23:29 giradot vdr-sxfe[10886]: [10903] [demux_vdr] PMT changed, resetting demuxer Sep 5 21:23:29 giradot vdr: [10370] frontend 0/0 lost lock on channel 6, tp 110773 Sep 5 21:23:30 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 184 Sep 5 21:23:30 giradot vdr: [10370] frontend 0/0 regained lock on channel 6, tp 110773 Sep 5 21:23:30 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: transport error Sep 5 21:23:30 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: transport error Sep 5 21:23:30 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 120 Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 131 Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: transport error Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 68 Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: transport error Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: transport error Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 37 Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 40 Sep 5 21:23:31 giradot vdr-sxfe[10886]: [10903] [demux_vdr] ts2es: no payload, size 184
In particular the "lost lock"/"regained lock" looks strange. Searching through the archives suggests this could be due to a weak signal. I ran femon and got this:
FE: Conexant CX24116/CX24118 (DVBS) status SCVYL | signal d840 | snr d800 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d999 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr d666 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr db33 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d800 | ber 00000081 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr db33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Which looks ok, the snr value seems high enough, so any other reason why the lock would be lost. I also see this in my dmesg which looks odd:
DVB: adapter 0 frontend 0 frequency 89399000 out of range (950000..2150000) DVB: adapter 0 frontend 0 frequency 89399000 out of range (950000..2150000) DVB: adapter 0 frontend 0 frequency 89399000 out of range (950000..2150000) DVB: adapter 0 frontend 0 frequency 89399000 out of range (950000..2150000)
-- Scott
Al 05/09/10 22:54, En/na Scott Waye ha escrit:
In particular the "lost lock"/"regained lock" looks strange. Searching through the archives suggests this could be due to a weak signal. I ran femon and got this:
FE: Conexant CX24116/CX24118 (DVBS) status SCVYL | signal d840 | snr d800 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d999 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr d666 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr db33 | ber 00003e71 | unc 000000a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d800 | ber 00000081 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal d840 | snr db33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Which looks ok, the snr value seems high enough, so any other reason why the lock would be lost.
No, there are 3 lines where the unc is not 0. Those indicate that the demodulator couldn't correct some of the data, so that's probably the cause of your problems. As an aside, every card reports those values in a different way, mine for example shows unc at 0 even with a much higher ber, and the unc is supposed to be cumulative, not instantaneous. I don't trust neither the signal strength nor the snr, partially trust the ber, but definitely the only value that means something is the unc (provided you decipher if your frontend give a cumulative value - i.e. ever increasing- or instantaneous -i.e it goes back to 0).
Bye
-
Luca Olivetti -
Scott Waye