Hi, on some channels I get Video Data Stream Broken messages, not sure quite what triggers them yet. They continue till the recording has finished.
I have switched off the emergency exit when VDSB occurs, two reasons why:
1. It never cures the problem 2. Occasionally I get a single VDSB written when tuning to certain channels, the emergency exit would happen, but after the restart I would get a single VDSB again when the channel was tuned, ending up in a loop, as the VDR restart is not curing the problem.
So, I wanted to know if anyone has any code or rules for rsyslog to identify multiple VDSB messages so I could trigger other actions. For example a reboot of the PC or maybe a driver load/unload. I know I could extend the VDR start script to unload/load the DVB drivers after a VDR exit too.
Anyone have other suggestions maybe?
Cheers Brian
Am 27.04.2013 10:50, schrieb Brian-Imap:
Hi, on some channels I get Video Data Stream Broken messages, not sure quite what triggers them yet.
VDSB is triggered if a recording doesn't receive any video data within 30 seconds. Usually this is because either the channel doesn't exist / doesn't broadcast, or because the DVB hardware failed and stopped working. If you disable emergency exit, VDR will likely continue to see no data, so forget about that recording.
I know I could extend the VDR start script to unload/load the DVB drivers after a VDR exit too.
This is the only thing that might cure a VDSB, and the only reason to do an emergency exit at all. Its quite unlikely that restarting VDR without reloading drivers will make any difference. (though not impossible, I've seen strange crosstalk effects in the past, and VDR doing something completely different after restart sometimes helped.)
Cheers,
Udo
On 27.04.2013 12:36, Udo Richter wrote:
Am 27.04.2013 10:50, schrieb Brian-Imap:
Hi, on some channels I get Video Data Stream Broken messages, not sure quite what triggers them yet.
VDSB is triggered if a recording doesn't receive any video data within 30 seconds. Usually this is because either the channel doesn't exist / doesn't broadcast, or because the DVB hardware failed and stopped working. If you disable emergency exit, VDR will likely continue to see no data, so forget about that recording.
I know I could extend the VDR start script to unload/load the DVB drivers after a VDR exit too.
This is the only thing that might cure a VDSB, and the only reason to do an emergency exit at all. Its quite unlikely that restarting VDR without reloading drivers will make any difference. (though not impossible, I've seen strange crosstalk effects in the past, and VDR doing something completely different after restart sometimes helped.)
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Moin, strange, here are some example messages that I send myself per email:
VDR-Test-Cellar(SDA2): 01:43 VDSB VDR-Test-Cellar(SDA2): 01:43 VDSB VDR-Test-Cellar(SDA2): 01:42 VDSB VDR-Test-Cellar(SDA2): 01:41 VDSB VDR-Test-Cellar(SDA2): 01:41 Start 2013-04-27 01.41 Friday Night Dinner VDR-Test-Cellar(SDA2): 01:30 Stop 2013-04-27 00.01 Later... with Jools Holland VDR-Test-Cellar(SDA2): 01:26 Start 2013-04-27 01.26 Bluestone 42 VDR-Test-Cellar(SDA2): 00:01 Start 2013-04-27 00.01 Later... with Jools Holland VDR-Test-Cellar(SDA2): 23:50 Stop 2013-04-26 22.59 QI VDR-Test-Cellar(SDA2): 23:20 Stop 2013-04-26 21.56 Ben Earl VDR-Test-Cellar(SDA2): 23:20 Stop 2013-04-26 22.26 Have I Got News for You VDR-Test-Cellar(SDA2): 23:10 Stop 2013-04-26 21.58 The Genius of Turner#3A Painting the Ind VDR-Test-Cellar(SDA2): 22:59 Start 2013-04-26 22.59 QI VDR-Test-Cellar(SDA2): 22:26 Start 2013-04-26 22.26 Have I Got News for You VDR-Test-Cellar(SDA2): 21:58 Start 2013-04-26 21.58 The Genius of Turner#3A Painting the Ind VDR-Test-Cellar(SDA2): 21:56 Start 2013-04-26 21.56 Ben Earl VDR-Test-Cellar(SDA2): 21:55 VDSB VDR-Test-Cellar(SDA2): 18:38 Up VDR-Test-Cellar(SDA2): 07:40 Going down
At 21:55 there is a single VDSB depsite the fact that no recording is running. Then all is OK till 01:41 that recording triggers the VDSB and they continue until the recording end time is reached. So its this continual repeated VDSB that I want to catch if possible.
The single one at the start is what stops me activating the emergency exit in VDR.
Cheers Brian
Am 27.04.2013 14:06, schrieb Brian-Imap:
The single one at the start is what stops me activating the emergency exit in VDR.
Do you have an in-accurate system clock and/or clock syncing enabled? VDR will falsely trigger an VDSB if the clock is set more than 30 seconds ahead while a recording is running. If you set the clock by DVB time, I'd suggest restricting it to one channel only.
Cheers,
Udo
On 28.04.2013 03:28, Udo Richter wrote:
Am 27.04.2013 14:06, schrieb Brian-Imap:
The single one at the start is what stops me activating the emergency exit in VDR.
Do you have an in-accurate system clock and/or clock syncing enabled? VDR will falsely trigger an VDSB if the clock is set more than 30 seconds ahead while a recording is running. If you set the clock by DVB time, I'd suggest restricting it to one channel only.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hmmm, I wasn't setting system time, so I have now activated that and set it to use the ZDF transponder. I'll take a look at what is happening with my system clock too. So you assume it was falsely triggering a VDSB thinking 30 secs had passed when in fact the clock probably was adjusted instead? Cheers Brian
Am 28.04.2013 16:52, schrieb Brian-Imap:
So you assume it was falsely triggering a VDSB thinking 30 secs had passed when in fact the clock probably was adjusted instead?
Its the only false alarm I know of, and would be an explanation why this happens on the start of a recording. Tuning to the channel for recording may activate the clock sync for that transponder, and cause a time jump once. All other explanations involve crappy driver/hardware or bad reception.
There should be a log message indicating the clock sync.
Cheers,
Udo
Handling of VDSB should be improved somehow, or at least add some configuration.
It's annoying if VDR is recording multiple channels, and one channel has VDSB.. emergency exit at this point will break all the other recordings, which otherwise would be fine.
Also I think VDR should try tuning to same channel with another frontend. People might have different size dishes on different tuners. Some channels might be unavailable in bad weather with small dishes, but view with larger one. VDR should try all possible methods to tune the wanted channel, before resorting to emergency exit..
Perhaps VDR should also store the time of previous emergency exit.. if VDSB continues after first emergency exit, it's not very useful to exit again. One emergency exit per recording should be enough. 28.4.2013 20.52 "Udo Richter" udo_richter@gmx.de kirjoitti:
Am 28.04.2013 16:52, schrieb Brian-Imap:
So you assume it was falsely triggering a VDSB thinking 30 secs had passed when in fact the clock probably was adjusted instead?
Its the only false alarm I know of, and would be an explanation why this happens on the start of a recording. Tuning to the channel for recording may activate the clock sync for that transponder, and cause a time jump once. All other explanations involve crappy driver/hardware or bad reception.
There should be a log message indicating the clock sync.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 28.04.2013 19:45, Udo Richter wrote:
Am 28.04.2013 16:52, schrieb Brian-Imap:
So you assume it was falsely triggering a VDSB thinking 30 secs had passed when in fact the clock probably was adjusted instead?
Its the only false alarm I know of, and would be an explanation why this happens on the start of a recording. Tuning to the channel for recording may activate the clock sync for that transponder, and cause a time jump once. All other explanations involve crappy driver/hardware or bad reception.
There should be a log message indicating the clock sync.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Moin, well I did have a problem in my rsyslog conf meaning I did sometimes send a VDSB email when it should have been something else. That is OK now. What I am seeing is the following:
May 11 23:39:24 localhost vdr: [4863] frontend 1/0 timed out while tuning to channel 7, tp 210906
Where the channel and transponder are random. I have three cards in my system, one is a Cine 2 that appears to provide frontends 0/0 and 2/0, FE 1/0 is my FF card. I picked out various tuning messages and used FEMON to check that each of the channels that had a problem could be tuned on each device, and that gave me no problems.
I wonder if its just a transient thing?
I have the clock stuff setup as suggested and dont see any clock sync messages, it is just set up to use ZDF now.
I guess I'll go back to an activated emergancy exit now to get the DVB module load/unload back.
Cheers Brian
-
Brian-Imap -
Teemu Suikki -
Udo Richter