I have here the same Problem (no Locks by channel switching by some transponders) with VDR 1.3.38 with DVB-T.
Of course I have not so strong DVB-T signal, but with VDR 1.3.37 I have no Problems with channel switching and Locks!!
With tests with both VDR versions above I use the same kernel (2.6.15) and DVB driver.
Has this anything to do with the following changes?
- Improved TS/PES conversion to better handle lost TS packets (thanks to Reinhard Nissl). - The DVB devices now retune (and, if applicable, resend the DiSEqC data) if the lock is lost (based on a patch from Reinhard Nissl). - Fixed handling TS packets in cTS2PES (thanks to Reinhard Nissl). - Any cReceivers still attached to a cDevice when that device switches to a different transponder are now automatically detached (suggested by Patrick Fischer). - Adapted c(Dvb)Device: ProvidesCa() to the dynamic CA handling. - Added a mutex to synchronize cDevice: PlayPesPacket() and SetCurrentAudioTrack() (thanks to Reinhard Nissl).
best regards,
Juergen Judt
Juergen Judt wrote:
I have here the same Problem (no Locks by channel switching by some transponders) with VDR 1.3.38 with DVB-T.
Of course I have not so strong DVB-T signal, but with VDR 1.3.37 I have no Problems with channel switching and Locks!!
With tests with both VDR versions above I use the same kernel (2.6.15) and DVB driver.
Has this anything to do with the following changes?
- Improved TS/PES conversion to better handle lost TS packets (thanks to
Reinhard Nissl).
- The DVB devices now retune (and, if applicable, resend the DiSEqC data) if
the lock is lost (based on a patch from Reinhard Nissl).
- Fixed handling TS packets in cTS2PES (thanks to Reinhard Nissl).
- Any cReceivers still attached to a cDevice when that device switches to a
different transponder are now automatically detached (suggested by Patrick Fischer).
- Adapted c(Dvb)Device: ProvidesCa() to the dynamic CA handling.
- Added a mutex to synchronize cDevice: PlayPesPacket() and
SetCurrentAudioTrack() (thanks to Reinhard Nissl).
Are there any messages like
ERROR: frontend ... timed out while tuning to channel ...
in the log? If not, I'd say that rules out
- The DVB devices now retune (and, if applicable, resend the DiSEqC data) if the lock is lost (based on a patch from Reinhard Nissl).
Other than that I'd rule out
- Any cReceivers still attached to a cDevice when that device switches to a different transponder are now automatically detached (suggested by Patrick Fischer). - Adapted c(Dvb)Device: ProvidesCa() to the dynamic CA handling. - Added a mutex to synchronize cDevice: PlayPesPacket() and SetCurrentAudioTrack() (thanks to Reinhard Nissl).
since they have nothing to do with the actual tuning.
To test whether it's the remux stuff, try the remux.c file from version 1.3.37. It should be possible to just replace it and recompile.
Klaus
Sorry for this thread, the next time I will directly test by problems with an vanilla VDR!!! It was a plugin problem --> osdteletext !
Regards,
Juergen
Juergen Judt wrote:
Sorry for this thread, the next time I will directly test by problems with an vanilla VDR!!! It was a plugin problem --> osdteletext !
Unfortunately I don't use this plugin, but ttxtsubs (0.0.5-STE): Teletext subtitles. Maybe reason is same. I will try without it later.
Klaus Schmidinger wrote:
Are there any messages like
ERROR: frontend ... timed out while tuning to channel ...
in the log?
Yes it is.
Regards, SK
Additional info about NO_LOCK on low SR channel (without teletext subtitle plugin).
channels are: 1 HTB:11519:v:S60.0E:12000:515+8190:653=rus:0:0:2:65535:1:0 2 BELARUS-TV:11529:v:S60.0E:2893:511+4450:512:0:0:2:177:176:0
vdr-1.3.37 switching from ch 1 to 2:
femon output: status 1f | signal f8d0 | snr e430 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal f8bc | snr e4d2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 03 | signal ffff | snr 7b6c | ber 00000b00 | unc 00000000 | status 03 | signal ffff | snr 6fb4 | ber 00000000 | unc 00000000 | status 01 | signal ffff | snr 75ab | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr 789c | ber 00001400 | unc 00000000 | status 1f | signal ffff | snr e2cb | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal ffff | snr e310 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal ffff | snr e337 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
it takes 5 second to retune and LOCK.
vdr-1.3.38 same procedure.
messages log: Jan 12 14:49:28 sk vdr[3713]: switching to channel 2
syslog: Jan 12 14:49:30 sk vdr[3713]: ERROR: frontend 0 timed out while tuning to channel 2, tp 211529 Jan 12 14:50:31 sk vdr[3713]: ERROR: frontend 0 timed out while tuning to channel 2, tp 211529
femon: status 1f | signal fb3e | snr e475 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal f781 | snr e436 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 03 | signal ef71 | snr de30 | ber 00000300 | unc 00000000 | status 03 | signal ffff | snr b877 | ber 00000000 | unc 00000000 | status 01 | signal ffff | snr 7f5c | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr 87ba | ber 00001400 | unc 00000000 | status 03 | signal ffff | snr 822f | ber 00003000 | unc 00000100 | status 03 | signal ffff | snr 9342 | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr ab48 | ber 00000d10 | unc 00000000 | and so on...
Any idea?
Regards, SK
Suur Karu wrote:
Additional info about NO_LOCK on low SR channel (without teletext subtitle plugin).
channels are: 1 HTB:11519:v:S60.0E:12000:515+8190:653=rus:0:0:2:65535:1:0 2 BELARUS-TV:11529:v:S60.0E:2893:511+4450:512:0:0:2:177:176:0
vdr-1.3.37 switching from ch 1 to 2:
femon output: status 1f | signal f8d0 | snr e430 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal f8bc | snr e4d2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 03 | signal ffff | snr 7b6c | ber 00000b00 | unc 00000000 | status 03 | signal ffff | snr 6fb4 | ber 00000000 | unc 00000000 | status 01 | signal ffff | snr 75ab | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr 789c | ber 00001400 | unc 00000000 | status 1f | signal ffff | snr e2cb | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal ffff | snr e310 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal ffff | snr e337 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
it takes 5 second to retune and LOCK.
vdr-1.3.38 same procedure.
messages log: Jan 12 14:49:28 sk vdr[3713]: switching to channel 2
syslog: Jan 12 14:49:30 sk vdr[3713]: ERROR: frontend 0 timed out while tuning to channel 2, tp 211529 Jan 12 14:50:31 sk vdr[3713]: ERROR: frontend 0 timed out while tuning to channel 2, tp 211529
femon: status 1f | signal fb3e | snr e475 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal f781 | snr e436 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 03 | signal ef71 | snr de30 | ber 00000300 | unc 00000000 | status 03 | signal ffff | snr b877 | ber 00000000 | unc 00000000 | status 01 | signal ffff | snr 7f5c | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr 87ba | ber 00001400 | unc 00000000 | status 03 | signal ffff | snr 822f | ber 00003000 | unc 00000100 | status 03 | signal ffff | snr 9342 | ber 00000000 | unc 00000000 | status 03 | signal ffff | snr ab48 | ber 00000d10 | unc 00000000 | and so on...
Any idea?
You could try increasing the value of
#define DVBS_TUNE_TIMEOUT 2000 //ms
to something above 5000.
Klaus
Suur Karu wrote:
Klaus Schmidinger wrote:
You could try increasing the value of
#define DVBS_TUNE_TIMEOUT 2000 //ms
to something above 5000.
Bingo! This did a trick!
Sorry for my flame. Case closed.
Well, not quite.
The question remaining is whether this timeout should be generally set to a higher value. Or should we make it so that it depends on the srate? Longer timeout for smaller srate?
Can you confirm a relationship between the srate and the time it takes to get a lock?
Klaus
On Thu, 2006-01-12 at 15:19 +0100, Klaus Schmidinger wrote:
Suur Karu wrote:
Klaus Schmidinger wrote:
You could try increasing the value of
#define DVBS_TUNE_TIMEOUT 2000 //ms
to something above 5000.
Bingo! This did a trick!
Sorry for my flame. Case closed.
Well, not quite.
The question remaining is whether this timeout should be generally set to a higher value. Or should we make it so that it depends on the srate? Longer timeout for smaller srate?
Can you confirm a relationship between the srate and the time it takes to get a lock?
I think you will find that the timeout depends on the particular model of card as well.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger wrote:
The question remaining is whether this timeout should be generally set to a higher value. Or should we make it so that it depends on the srate? Longer timeout for smaller srate?
Can you confirm a relationship between the srate and the time it takes to get a lock?
Well, actually not. During tests on different channels I can't confirm srate and lock time dependency. For example: 1550 (OASI TV @12.5W) - 1sec 2200 (TBN Russia @12.5W) - 2sec 2960 (Avrasya-ANK @42E) - 1sec 3092 (Minsk TV @53E) - 7sec !!! 4883 (NTV Hayat @12.5W) - 3sec 8888 (Cine5* @42E) - 2sec
So, now I set DVB-S timeouts same as for DVB-T and DVB-C and quite happy.
Regards, SK
-
Juergen Judt -
Klaus Schmidinger -
Malcolm Caldwell -
Suur Karu