Broadcast (over-the-air) schedule refresh incomplete or absent

[deadletterfile@…]

Broadcast (over-the-air) schedule normally runs out 8 to 12 hours. With github fork, schedule updates incompletely or not at all unless "Watch TV" selected and the desired channel viewed. Program schedule then populates as expected but does not update automatically. The desired channel must again be viewed via "Watch TV" to repopulate schedule. I reverted to Mythtv compiled from 0.26-0 tarball and display of schedule is as expected.

[sphery]

Please verify that you have "Use DVB card for active EIT scan" enabled in mythtv-setup.

[ronhumble@…]

"Use DVB card for active EIT scan" is enabled.

[deadletterfile@…]

Commit 12c443eb1cd22cecd257ea61984fa2dfb31d4992 on the fixes/0.26 branch is what broke over-the-air broadcast scheduling updates for me. Specifically the additions to DVBSignalMonitor::UpdateValues?(void)

diff --git a/mythtv/libs/libmythtv/dvbsignalmonitor.cpp b/mythtv/libs/libmythtv/dvbsignalmonitor.cpp index 1fa010e..75cc94a 100644 --- a/mythtv/libs/libmythtv/dvbsignalmonitor.cpp +++ b/mythtv/libs/libmythtv/dvbsignalmonitor.cpp @@ -52,7 +52,8 @@ DVBSignalMonitor::DVBSignalMonitor(int db_cardnum, DVBChannel* _channel,

rotorPosition (QObject::tr("Rotor Progress"), "pos",

100, true, 0, 100, 0),

streamHandlerStarted(false),

• streamHandler(NULL)

+ streamHandler(NULL), + lock_timeout(1000 * 60 * 2 /* 2 minutes */)

{

These two values should probably come from the database... int wait = 3000; timeout when waiting on signal

@@ -208,6 +209,9 @@ DVBChannel *DVBSignalMonitor::GetDVBChannel(void)

*/

void DVBSignalMonitor::UpdateValues?(void) {

+ if (lock_timer.elapsed() > lock_timeout)
+ error = "Timed out.";
+

if (!running

exit)

return;

I commented out the added lines and this compiled commit worked as hoped, with over-the-air scheduling updating as expected. I learned in testing that all station schedules update at a minimum every three hours, and extend out at least ten hours.

I did a “git checkout 7f71e02467f52d1e3336b8badeee31d3235bb42f“ and “git status”
Author: Chris Pinkham <cpinkham@…>
Date: Thu Jun 13 22:25:14 2013 -0700

HTTPLiveStream::GetLiveStreamInfo? fixups.

The above DVBSignalMonitor::UpdateValues?(void) lines were again commented out and I am testing. I expect success.

On the master branch, I did a “git checkout 7f71e02467” and “git status” then compiled. Over-the-air broadcast schedule updating still fails for me. I am using Fedora 19 for the master branch. /dev/dvb/adapter0 is a HD-5500 card; adapter<1 2> is a HVR-2250 card. The above compiles and tests were on Fedora 18 with the same machine.

Below is a cut/paste with date added to a SQL query of my test results on the master branch:
mythbackend version: master [v0.27-pre2-1358-g7ffae0d]
Mon Jun 17 08:27:23 EDT 2013
613 rows in set (0.01 sec)
MariaDB [mythconverg]> select * from program where endtime > '2013-06-16 20:00:00';

Mon Jun 17 08:29:31 EDT 2013
708 rows in set

Mon Jun 17 08:30:26 EDT 2013
745 rows in set

Mon Jun 17 08:33:04 EDT 2013
871 rows in set

Mon Jun 17 08:49:54 EDT 2013
952 rows in set

Mon Jun 17 08:53:01 EDT 2013
955 rows in set Only WRAL not populated

Mon Jun 17 08:55:19 EDT 2013
959 rows in set

Mon Jun 17 09:06:10 EDT 2013
1058 rows in set

Mon Jun 17 11:47:09 EDT 2013
Mon Jun 17 13:16:26 EDT 2013
Mon Jun 17 15:03:19 EDT 2013
1058 rows in set

As you can see the station schedules appear to initially update ( I checked the program guide on mythfrontend), but then no updates over a six hour period. The code I altered in fixes/0.26 is not in master, and I have not yet attempted to find where my breakage occurs in the master branch.

I hope you might be able to look at fixes/0.26 based on my analysis. If I can be of assistance, let me know.

[deadletterfile@…]

Sample patch to tv_rec.cpp

[deadletterfile@…]

I have a possible solution to my problem. Below is a sample patch (and as attachment) to libs/libmythtv/tv_rec.cpp that was created against commit bc9cc198e5 in the master branch, of which only the adjustment to .addSecs is important.

1265a1266 > LOG(VB_GENERAL, LOG_ERR, LOC + "tv_rec.cpp Adjusted Scan start " + eitScanStartTime.toString()); 1267a1269 > { 1268a1271,1272 > LOG(VB_GENERAL, LOG_ERR, LOC + "tv_rec.cpp DISABLED " + eitScanStartTime.toString()); > } 1414a1419 > LOG(VB_GENERAL, LOG_ERR, LOC + "tv_rec.cpp StartActiveScan"); 1417c1422 < eitScanStartTime = MythDate::current().addYears(1); --- > eitScanStartTime = MythDate::current().addSecs(8192);

My analysis below is ignorant and perhaps comical. It appears I have six instances of TVRec::run created at start up of mythbackend. 1, 3, and 5 are active and 2, 4, 6 are immediately disabled. I have three television tuners, all set to initiate EIT scans. Currently, after StartActiveScan for an active instance is executed, eitScanStartTime for that instance is set to a time one year in the future. An EIT scan will potentially not occur for a year in that instance unless the TVRec:run instance changes state (./docs/doxygen-architecture-document.cpp).

If one watches television or makes a recording, a StartActiveScan will be done. However most channels extend their EIT information no more than twelve hours, so if an instance does not change state within 12 hours, future scheduled recordings would potentially be lost. I made a five minute manual recording, and StartActiveScan was executed for one instance, confirming to me a recording will activate StartActiveScan.

I have run the above patch on commit bc9cc198e5 and am pleased with the performance. 8192 is a good binary number, working out to about two hours and sixteen minutes between StartActiveScan executions on an otherwise inert mythbackend.

Similar code exists in the fixes/0.26 branch. I have had unexplained missed recordings on this branch and the above problem was likely the cause. I hope the above (or similar) might be a viable solution, or that some other suitable fix might make it to the master and fixes/0.26 branches. - RoyBoy626

[deadletterfile@…]

I have reverted the eitScanStartTime = MythDate::current().addSecs(8192) back to addYears(1) EIT scans continued to fail to complete the run through my ten multiplexes and the random start positions of scans eventually caused EIT data loss.

I have one channel (and on occasion others) for which TVRec::TuningSignalCheck(void) would fail with: TuningSignalCheck: SignalMonitor timed out.

Looking at the function, the above is part of the "else if" of an if/else if/else code segment. The "else if" does not produce a return within the "else if" and instead drops down to the "return streamData" at the end of the function. I am guessing that with no signal, the "else if" should return NULL. In addition, scanner->StopActiveScan() is potentially executed, which I believe kills the TVRec instance of EITScan, and channel scanning for this instance is stopped. If one has only one tuner card, and mythbackend is relatively inert, EIT program data is lost.

I have substituted below in the "else if" portion of TuningSignalCheck:

return NULL;

// if (scanner && HasFlags(kFlagEITScannerRunning)) // { // scanner->StopActiveScan(); // ClearFlags(kFlagEITScannerRunning); // }

So far, EIT scans run to completion and continuously loops through the multiplex list as the original programmers intended. - RoyBoy626

[deadletterfile@…]

I have submitted libmythtv.140128.patch to bug 11739 which includes my proposed fix for this issue, but this patch is against commit f19d9f8062 (Jan 27, 2014). There are no new additions regarding this issue since my post in the summer of 2013. Much of the patch concerns bug 11739, or were attempts by me to keep the scheduler running prior to my discovery of the missing 'return NULL' in function MPEGStreamData *TVRec::TuningSignalCheck(void) of tv_rec.cpp.

As stated in prior posts my scheduler could become incomplete or absent during periods when Mythtv was inert for many hours as the EIT scanner crashed and did not restart. Since implementing my fix, my schedule has always been fully populated to the extend possible by the EI and ET tables. The patch has proven stable for me these past months, and this bug is no longer an issue for me. I look forward to a fix entering the master branch code in the future. - RoyBoy626

[deadletterfile@…]

Patch to tv_rec.cpp to reduce/eliminate EIT scanner crash

[deadletterfile@…]

My removal of check on EIT scanner running in libmythtv.140430.patch, modifying tv_rec.cpp perhaps in error. This patch simply adds "return NULL;" to part of the TuningSignalCheck(void) function. This change may eliminate some/all crashes in the EIT scanner. I have seen no loss of EIT data during periods of Mythtv inactivity using the April patch. I will locally adjust the April patch and test.

Patch 151110.tv_rec.patch placed in libmythtv and execute: patch -p0 tv_rec.cpp < 151110.tv_rec.patch

[deadletterfile@…]

Patch to tv_rec.cpp to reduce/eliminate EIT scanner crash

[deadletterfile@…]

patch 151112.tv_rec.patch replaces 141110.tv_rec.patch. The patch is against Mythtv 0.27.5.

In my build at least, allowing function TuningSignalCheck to kill the EIT scanner leads to loss of program data. Patch applied similar to as stated in comment 9.

[Stuart Auchterlonie]

Moving remaining open 0.28.1 tickets to 0.28.2

[Stuart Auchterlonie]

Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master