[mythtv-users] scheduling issue after recent rpm update - scheduled recordings aren't recording

[Bruce Markey]

dead wrote:
> When I go to Upcoming Recordings, it tells me I have no recordings
> scheduled. When I try to reschedule something I've previously had
> scheduled, it doesn't appear to save the schedule.

A bit unclear how you came to that conclusion. Try adding a new
rule for a different show title from within mythfrontend then go
the Recording Priorities to see if it appears in the list. If it
doesn't, there may be something wrong with your "record" table.

> Now here's the weird
> part: If I look at my "Recording Schedules" in Mythweb, it shows all the
> program schedules just fine and clicking "Find showings of this program"
> for any of the recording schedules does display upcoming episodes.
> However, if I go to "Scheduled Recordings", the list is blank. Somehow
> it's no longer making the leap to having a show programmed to be
> recorded and actually scheduling the recording of the program. I
> verified that it's not an issue with duplicates from previous
> recordings. I verified that mythfrontend is suid, though this seems to
> be a backend issue. Then I checked to see what mythbackend would tell
> me. When I run 'mythbackend --testsched', it appears to properly
> conclude what programs to record, but when I use '--printsched', the
> list is empty. Also, when I used '--resched' with '--verbose all' it
> gives me the following, which doesn't seem to make any difference at all:

Resched signals the master to redo the schedule from scratch and
won't give any interesting output itself but I'll assume that the
schedule wasn't fixed after the resched. What's noteworthy here is
that testsched gives results. Check the master backend log to see
that it includes recent lines like:

2005-06-23 23:31:20.043 Reschedule requested for id 0.
2005-06-23 23:31:20.860 Scheduled 308 items in 0.8 = 0.00 match + 0.80 place

If it doesn't have these since the problem started happening it
would mean that the scheduler never completed its run. I saw this
behavior recently when a slave system overheated and needed a reboot
for the linux system to be well behaved again. So, if you have any
slaves, stop then and start the master by itself to see if it can
schedule with just the local tuners.

Run "mythbackend -v schedule". This prints messages for all the
steps it takes along the way. If it doesn't result in listing
scheduled shows, attach the output.

> I also verified that my input connections show "(Tuner 0) -> cable",
> connecting my 'cable' video source to the tuner0 input on my pvr-350.

Since live TV works, your cards/inputs/channels are probably okay
but there could still be some sort of confusion. The verbose
schedule output may give some hints of it isn't finding any
valid inputs. One possibility is if you recreated your "cable"
source and it now has id 2 and the inputs are for sourceid 1
or something like that.

> My best guess is that the database didn't get properly updated or got
> corrupted somehow, but I didn't spot any differences between my table
> schemas and what the 'dbcheck.cpp' file from the source code says they
> should be.

It could be a corrupted table. For good measure, run:

$ mysqlcheck -r -u mythtv -pmythtv mythconverg

In this past we've had problems caused by bogus record rules but
this hasn't come up in many months. Try:

$ mysql -u mythtv -pmythtv mythconverg
mysql> select recordid,type,title from record order by recordid;

and look for a blank title or a type other than 1-10 like "0" or
something and remove the offending rule. If that's not it, try
removing the most recently added rules (highest recordid). You
should be able to do this from the Recording Priorities page. Find
the title, press Enter and set "Do not record this program" then
Save.

--  bjm