VDSB due to timer on off-air channel...

Message ID Pine.LNX.4.56.0706170116520.17732@zntcvr.ybpny.qbznva
State New

Commit Message

iain@bigserver.dnsalias.net June 17, 2007, 1:54 a.m. UTC
  Hi all.
Running vdr 1.3.43, yes I should probably upgrade, but it's mostly

Anyhow, the issue. Based in the UK, picking up DVB-t with reasonable
signal strength. Use vdradmin with a timer margin of 10 mins at the end.
Alas, sometimes timers get created that extend past the time a channel
goes off-air. VDR promptly video-data-stream-brokens repeatedly until the
timer ends, or is stopped/deleted manually.
Had a similar issue with timers for programs starting when the channel
goes on-air (Crystal Maze, f-tn), quickest fix was to reduce the
pre-padding from 2mins to 1 min. Can't really do that for the
post-padding; I've mostly seen programs ending late, not starting early...

The cause, seems to be that when certain channels go off-air, that PID
becomes disused, so no data arrives -> timeout.

The fix appears to be simple at least for this particular case. Providing
autopid is enabled. Get a message through syslog indicating the PIDs
have changed, followed by "stopping recording due to modification of
channel 15".
So, using the same technique as refusing to record with no disk space, the
attached patch refuses to record when all the PIDs are zero.

Shall have to wait for some channels to change state (might be able to use
ftn going off-air in about 4 hours) to verify how well this works, but
manually setting timers for off-air channels CBBC/Cbeebies/Five Life
behaves, when pre-patch a VDSB-restart would happen.

The logging could be better; it only logs for the first timer that
attempts to start/restart with no PIDs, and this will only resolve the
issue where the broadcaster transmits the PID updates, and autopid is
enabled. Should help in the cases Darren S and Dave P posted, uhm, a year
ago ("False \"video data stream broken\"", 15/Jun/2006). Shouldn't affect
VDSBs causes by bad signal/crashed firmware unless the PIDs changed to 0,
and stayed there as a result.

Attached are two files; one generated from 1.3.43, and one from 1.5.3
(some apparantly unrelated changes happened in menu.c). 1.5.3 appears to
behave the as 1.3.43 in this respect; VDSB 30 secs after setting a timer
on an off-air channel, but behaves with the patch.

Any feedback would be welcome...
If it helps prevent another ruined recording, that'd be even better...


--- menu.c.bak	Sun Jun 17 01:10:12 2007
+++ menu.c	Sun Jun 17 01:10:14 2007
@@ -45,6 +45,8 @@ 
 #define MINFREEDISK       300 // minimum free disk space (in MB) required to start recording
 #define NODISKSPACEDELTA  300 // seconds between "Not enough disk space to start recording!" messages
+#define NOPIDDELTA  30 // seconds between refusing to start a recording with no PIDs. Like off-air channels in the UK.
 #define CHNUMWIDTH  (numdigits(Channels.MaxNumber()) + 1)
 // --- cMenuEditCaItem -------------------------------------------------------
@@ -3715,6 +3717,7 @@ 
 bool cRecordControls::Start(cTimer *Timer, bool Pause)
   static time_t LastNoDiskSpaceMessage = 0;
+  static time_t LastNoPIDCheck = 0;
   int FreeMB = 0;
   if (Timer) {
      AssertFreeDiskSpace(Timer->Priority(), !Timer->Pending());
@@ -3736,6 +3739,17 @@ 
   cChannel *channel = Channels.GetByNumber(ch);
   if (channel) {
+     // Check that at least one of the PIDs is non-zero. Else we'll get VDSBs when attempting to record an off-air channel...
+     if (!(channel->Vpid()||*channel->Apids()||*channel->Dpids()||*channel->Spids())) {
+        if (time(NULL) - LastNoPIDCheck > NOPIDDELTA) {
+           isyslog("All PIDs zero starting recording%s%s", Timer ? " timer " : "", Timer ? *Timer->ToDescr() : "");
+           LastNoPIDCheck = time(NULL);
+           }
+        return false;
+        }
+     LastNoPIDCheck = 0;
      int Priority = Timer ? Timer->Priority() : Pause ? Setup.PausePriority : Setup.DefaultPriority;
      cDevice *device = cDevice::GetDevice(channel, Priority, false);
      if (device) {