From patchwork Sun Jun 17 01:54:50 2007 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: iain@bigserver.dnsalias.net X-Patchwork-Id: 12478 Received: from 82-68-6-61.dsl.in-addr.zen.co.uk ([82.68.6.61] helo=bigserver.dnsalias.net ident=mail) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from ) id 1Hzjyq-0000HE-6e for vdr@linuxtv.org; Sun, 17 Jun 2007 03:55:04 +0200 Received: from magpie ([10.0.0.50] helo=magpie.local.domain) by bigserver.dnsalias.net with esmtp (Exim 3.36 #1) id 1Hzjyg-0000N6-00 for vdr@linuxtv.org; Sun, 17 Jun 2007 02:54:54 +0100 Received: from localhost (localhost.local.domain [127.0.0.1]) by magpie.local.domain (8.9.3/8.8.7) with ESMTP id CAA23204 for ; Sun, 17 Jun 2007 02:54:50 +0100 From: iain@bigserver.dnsalias.net Date: Sun, 17 Jun 2007 02:54:50 +0100 (BST) X-X-Sender: iain@magpie.local.domain To: vdr@linuxtv.org Message-ID: MIME-Version: 1.0 Subject: [vdr] VDSB due to timer on off-air channel... X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2007 01:55:05 -0000 Status: O X-Status: X-Keywords: X-UID: 13265 Hi all. Running vdr 1.3.43, yes I should probably upgrade, but it's mostly working... 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) {