Good morning,
I see logging like this all the time in my syslog file:
May 22 06:36:45 hex vdr: [31292] frontend 0 timed out while tuning to channel 31, tp 298 May 22 06:37:06 hex vdr: [31292] frontend 0 timed out while tuning to channel 33, tp 322
And:
May 22 09:59:58 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 09:59:59 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338
What does this mean? The channels referred to (31, 33 and 41) are channels that we never, ever watch as they are encrypted. Normally these three or neighbor channels are referred to in the error logging. We almost never use channels above 20. So, why does VDR try to tune into them and why would it fail? We have two FF cards but we still would like them both to do something that benefits us, not go randomly tune into uninteresting channels. :)
Best regards, Jan Ekholm
On 22.05.2009 09:07, Jan Ekholm wrote:
Good morning,
I see logging like this all the time in my syslog file:
May 22 06:36:45 hex vdr: [31292] frontend 0 timed out while tuning to channel 31, tp 298 May 22 06:37:06 hex vdr: [31292] frontend 0 timed out while tuning to channel 33, tp 322
And:
May 22 09:59:58 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 09:59:59 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338
What does this mean? The channels referred to (31, 33 and 41) are channels that we never, ever watch as they are encrypted. Normally these three or neighbor channels are referred to in the error logging. We almost never use channels above 20. So, why does VDR try to tune into them and why would it fail? We have two FF cards but we still would like them both to do something that benefits us, not go randomly tune into uninteresting channels. :)
Well, I'm still working on the code that reads the user's mind and determines what they might find "interesting" ;-)
You can turn off the EPG scan to keep VDR from tuning through the various transponders.
Klaus
On Fri, 22 May 2009 13:22:16 +0200 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Well, I'm still working on the code that reads the user's mind and determines what they might find "interesting" ;-)
Have you thought about a keyed logging system? It would also be nice if VDR had a logfile to itself instead of syslog.
Tony Houghton wrote:
It would also be nice if VDR had a logfile to itself instead of syslog.
Fix your syslogd and RTFM :)
-l level, --log=level
Set logging to level. 0 = no logging, 1 = errors only, 2 = errors and info, 3 = errors, info and debug. The default logging level is 3. If logging should be done to LOG_LOCALn instead of LOG_USER, add '.n' to LEVEL, as in 3.7 (n=0..7).
On Fri, 22 May 2009 16:38:36 +0300 Lauri Tischler lwgt@iki.fi wrote:
Tony Houghton wrote:
It would also be nice if VDR had a logfile to itself instead of syslog.
Fix your syslogd and RTFM :)
-l level, --log=level
Set logging to level. 0 = no logging, 1 = errors only, 2 = errors and info, 3 = errors, info and debug. The default logging level is 3. If logging should be done to LOG_LOCALn instead of LOG_USER, add '.n' to LEVEL, as in 3.7 (n=0..7).
It's a start. Do you happen to know whether any of the abstract ietf properties rsyslog can filter on correspond to the ident parameter passed to openlog()?
On Friday 22 May 2009 14:22:16 Klaus Schmidinger wrote:
On 22.05.2009 09:07, Jan Ekholm wrote:
Good morning,
I see logging like this all the time in my syslog file:
May 22 06:36:45 hex vdr: [31292] frontend 0 timed out while tuning to channel 31, tp 298 May 22 06:37:06 hex vdr: [31292] frontend 0 timed out while tuning to channel 33, tp 322
And:
May 22 09:59:58 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 09:59:59 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338
What does this mean? The channels referred to (31, 33 and 41) are channels that we never, ever watch as they are encrypted. Normally these three or neighbor channels are referred to in the error logging. We almost never use channels above 20. So, why does VDR try to tune into them and why would it fail? We have two FF cards but we still would like them both to do something that benefits us, not go randomly tune into uninteresting channels. :)
Well, I'm still working on the code that reads the user's mind and determines what they might find "interesting" ;-)
You can turn off the EPG scan to keep VDR from tuning through the various transponders.
But turning off the scanning means there's no EPG data? I would rather just disable the channels in channels.conf (or similar) so that they are there and updated with new data should they ever be needed. No point in VDR scanning a lot of channels (100+) that we can't anyway access nor want to have any EPG data for.
On 05/23/09 11:42, Jan Ekholm wrote:
On Friday 22 May 2009 14:22:16 Klaus Schmidinger wrote:
On 22.05.2009 09:07, Jan Ekholm wrote:
Good morning,
I see logging like this all the time in my syslog file:
May 22 06:36:45 hex vdr: [31292] frontend 0 timed out while tuning to channel 31, tp 298 May 22 06:37:06 hex vdr: [31292] frontend 0 timed out while tuning to channel 33, tp 322
And:
May 22 09:59:58 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 09:59:59 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 lost lock on channel 41, tp 338 May 22 10:00:01 hex vdr: [31292] frontend 0 regained lock on channel 41, tp 338
What does this mean? The channels referred to (31, 33 and 41) are channels that we never, ever watch as they are encrypted. Normally these three or neighbor channels are referred to in the error logging. We almost never use channels above 20. So, why does VDR try to tune into them and why would it fail? We have two FF cards but we still would like them both to do something that benefits us, not go randomly tune into uninteresting channels. :)
Well, I'm still working on the code that reads the user's mind and determines what they might find "interesting" ;-)
You can turn off the EPG scan to keep VDR from tuning through the various transponders.
But turning off the scanning means there's no EPG data? I would rather just disable the channels in channels.conf (or similar) so that they are there and updated with new data should they ever be needed. No point in VDR scanning a lot of channels (100+) that we can't anyway access nor want to have any EPG data for.
EPG data is always collected for the transponders you actually tune to. The EPG scan just automatically switches through all transponders, which is apparently not what you want.
You could also remove all unwanted channels from your list and set "DVB/Update channels" to "names and PIDs". Then the EPG scan would only switch through the desired transponders.
Klaus
On Sat, 2009-05-23 at 11:47 +0200, Klaus Schmidinger wrote: ...
You could also remove all unwanted channels from your list and set "DVB/Update channels" to "names and PIDs". Then the EPG scan would only switch through the desired transponders.
I believe there is room for improvement.
Of course I want *all* channels I can use and I want new channels, too, if can use them.
And I do not want to go through my list of channels manually all the time, find those that I cannot view and delete them manually.
I believe VDR could do a much better (more thorough, less error-prone) job at that than I ever could.
Here is a list of improvements that would greatly help maintaining a clean and useful channel list:
1) When VDR does its EPG scan, it switches to all channels anyway. Why not test each channel and see if it actually delivers data? If it does, set a new configuration field to 0. If it does not, increment that field by one. Lets call this field the "absent" value. The reason why we do not get any data does not matter. Maybe the channel is temporarily not broadcasting. Maybe it has ceased to exist. Maybe I do not have a cam for it. Maybe I have a suitable cam, but no subscription.
2) When zapping, automatically skip channels that have an "absent" value of > 5 (maybe that value should be configurable).
3) Do not display channels anywhere that have an "absent" value of > 5 (maybe that value should be configurable. If you set it to zero, all useless channels will show up again).
4) A "cleanup" run could remove all channels that have an absent value that exceeds a certain number (maybe 50).
5) You could define additional criteria that would increment the "absent" value during an EPG scan. For example: 5a) the channel does not broadcast one of the audio languages that I have configured as the set of languages that I can understand. 5b) the channel broadcasts video, but with less than 1 Mbit/s. (That would get rid of all those advertising channels which only broadcast slide shows).
Cheers, Carsten.
On 05/23/09 12:44, Carsten Koch wrote:
On Sat, 2009-05-23 at 11:47 +0200, Klaus Schmidinger wrote: ...
You could also remove all unwanted channels from your list and set "DVB/Update channels" to "names and PIDs". Then the EPG scan would only switch through the desired transponders.
I believe there is room for improvement.
Of course I want *all* channels I can use and I want new channels, too, if can use them.
And I do not want to go through my list of channels manually all the time, find those that I cannot view and delete them manually.
I believe VDR could do a much better (more thorough, less error-prone) job at that than I ever could.
Here is a list of improvements that would greatly help maintaining a clean and useful channel list:
- When VDR does its EPG scan, it switches to all channels anyway. Why not test each channel and see if it actually delivers data?
Actually it only tunes to *transponders*, not individual channels.
If it does, set a new configuration field to 0. If it does not, increment that field by one. Lets call this field the "absent" value. The reason why we do not get any data does not matter. Maybe the channel is temporarily not broadcasting. Maybe it has ceased to exist. Maybe I do not have a cam for it. Maybe I have a suitable cam, but no subscription.
When zapping, automatically skip channels that have an "absent" value of > 5 (maybe that value should be configurable).
Do not display channels anywhere that have an "absent" value of > 5 (maybe that value should be configurable. If you set it to zero, all useless channels will show up again).
A "cleanup" run could remove all channels that have an absent value that exceeds a certain number (maybe 50).
You could define additional criteria that would increment the "absent" value during an EPG scan. For example: 5a) the channel does not broadcast one of the audio languages that I have configured as the set of languages that I can understand. 5b) the channel broadcasts video, but with less than 1 Mbit/s. (That would get rid of all those advertising channels which only broadcast slide shows).
Sounds like a perfect task for a plugin - with tons of config parameters and endless threads about what makes sense and what doesn't ;-) (SCNR). At any rate, it's way too complex for the core VDR code, and goes against the KISS principle.
Klaus
Klaus Schmidinger wrote:
On 05/23/09 12:44, Carsten Koch wrote:
On Sat, 2009-05-23 at 11:47 +0200, Klaus Schmidinger wrote: ...
You could also remove all unwanted channels from your list and set "DVB/Update channels" to "names and PIDs". Then the EPG scan would only switch through the desired transponders.
I believe there is room for improvement.
Of course I want *all* channels I can use and I want new channels, too, if can use them.
And I do not want to go through my list of channels manually all the time, find those that I cannot view and delete them manually.
I believe VDR could do a much better (more thorough, less error-prone) job at that than I ever could.
Here is a list of improvements that would greatly help maintaining a clean and useful channel list:
- When VDR does its EPG scan, it switches to all channels anyway. Why not test each channel and see if it actually delivers data?
Actually it only tunes to *transponders*, not individual channels.
If it does, set a new configuration field to 0. If it does not, increment that field by one. Lets call this field the "absent" value. The reason why we do not get any data does not matter. Maybe the channel is temporarily not broadcasting. Maybe it has ceased to exist. Maybe I do not have a cam for it. Maybe I have a suitable cam, but no subscription.
When zapping, automatically skip channels that have an "absent" value of > 5 (maybe that value should be configurable).
Do not display channels anywhere that have an "absent" value of > 5 (maybe that value should be configurable. If you set it to zero, all useless channels will show up again).
A "cleanup" run could remove all channels that have an absent value that exceeds a certain number (maybe 50).
You could define additional criteria that would increment the "absent" value during an EPG scan. For example: 5a) the channel does not broadcast one of the audio languages that I have configured as the set of languages that I can understand. 5b) the channel broadcasts video, but with less than 1 Mbit/s. (That would get rid of all those advertising channels which only broadcast slide shows).
Sounds like a perfect task for a plugin - with tons of config parameters and endless threads about what makes sense and what doesn't ;-) (SCNR).
There used to be a plugin ,'autosort' i believe, which did some of those things.
There used to be a plugin ,'autosort' i believe, which did some of those things.
http://www.vdr-wiki.de/wiki/index.php/Autosort-plugin http://www.copypointburscheid.de/linux/autosort.htm
home page of that plugin doesn't work
where is it possible to download that plugin for vdr 1.7.7 ?
Goga
Goga777 wrote:
There used to be a plugin ,'autosort' i believe, which did some of those things.
http://www.vdr-wiki.de/wiki/index.php/Autosort-plugin http://www.copypointburscheid.de/linux/autosort.htm
home page of that plugin doesn't work
where is it possible to download that plugin for vdr 1.7.7 ?
I have no idea, I have vdr-autosort-0.1.3.tgz file, dated 1.4.2007 so I'm sure it needs work, to run with vdr-1.7.7
I can mail it to you if you like, its only 40kb file.
There used to be a plugin ,'autosort' i believe, which did some of those things.
http://www.vdr-wiki.de/wiki/index.php/Autosort-plugin http://www.copypointburscheid.de/linux/autosort.htm
home page of that plugin doesn't work
where is it possible to download that plugin for vdr 1.7.7 ?
I have no idea, I have vdr-autosort-0.1.3.tgz file, dated 1.4.2007 so I'm sure it needs work, to run with vdr-1.7.7
I can mail it to you if you like, its only 40kb file.
thanks I found it here http://www.copypointburscheid.de/linux/vdr-autosort-0.1.3.tgz
Goga
On Saturday 23 May 2009 12:47:49 Klaus Schmidinger wrote:
EPG data is always collected for the transponders you actually tune to. The EPG scan just automatically switches through all transponders, which is apparently not what you want.
You could also remove all unwanted channels from your list and set "DVB/Update channels" to "names and PIDs". Then the EPG scan would only switch through the desired transponders.
Well, that sounds like an excellent idea, I'll have a go. On our cable network here there are loads on commercial channels that we can't see nor will we ever want them. So I rather get rid of those errors from syslog if possible. I'll try your suggestion.
Thank you!
-
Carsten Koch -
Goga777 -
Jan Ekholm -
Klaus Schmidinger -
Lauri Tischler -
Tony Houghton