[mythtv-users] No SD Update and SD Episode Numbers do notmatchprevious recordings

[Cottrell, Eric]

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org 
> [mailto:mythtv-users-bounces at mythtv.org] On Behalf Of Michael T. Dean
> Sent: Tuesday, September 18, 2007 8:36 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] No SD Update and SD Episode 
> Numbers do notmatchprevious recordings
> 
> 
> On 09/18/2007 10:25 AM, Cottrell, Eric wrote:
> >> OK.  It sounds like you may be using the "Run
> >> mythfilldatabase at time suggested by grabber" but the time 
> >> that was last suggested (i.e. by a "manual" execution of 
> >> mythfilldatabase) is not in the window during which 
> >> mythfilldatabase is allowed to run.  To fix it, change the 
> >> "mythfilldatabase Execution Start/End" times to 0 and 24, 
> >> respectively.
> >>
> >> In 0.20.2 (and 0.20-fixes), the window is "moved" to a period
> >> of a couple of hours around the suggested time by the backend 
> >> when the backend runs mythfilldatabase.  So, if 
> >> mythfilldatabase is run manually, no one is updating the 
> >> window and it may or may not line up with the last-updated 
> >> window.  In SVN trunk (and, in 0.21, when it's released), the 
> >> window isn't changed, rather it's ignored.  See 
> >> 
> http://www.gossamer-threads.com/lists/mythtv/commits/263447#263447 .
> >>     
> > I did notice the min and max times shifting around when the "time 
> > suggested by grabber" option was checked.  My box was not 
> turned off 
> > during update times.  I unchecked the "time suggested by grabber" 
> > option a couple of days ago and it still does nothing.  Do 
> I have to 
> > wait two or three days after a manual run to see if the 
> autorun works?
> >
> > I am going to check the 0.20-fixes branch and see if there are any 
> > updates after the packman packager did the mythtv packages. 
>  It seems 
> > a few other people are having the problem as well.  Maybe a recent 
> > change broke something.  I would hate to have to go back to 
> compiling 
> > mythtv again.
> 
> You'd have to wait until a time after the suggested time 
> that's within the window specified.  Depending on specifics, 
> that may mean waiting more than a day.  However, changing the 
> mfdb execution start/end times to 0 and 24 should allow it to 
> run "right away" after the suggested time.
> 
> Mike

Hello,

I did change the window to 0 and 24 and still nothing. But I found the
problem.

I was looking at the housekeeper.cpp code to see if there was a bad
setting for mfdb.  I used the mysql query tool to look at the database
settings.  I looked at the MythFillEnabled entry in the settings table
of the database.  There were three of them.  I noticed there is a
hostname field and the three hostnames for those records are linux,
mythtv, and p28gSuSE.  In looking around the table I noticed some
settings did have scpvr, which is the current name of the host. p28gSuSE
was the old host name under SuSE 9.2.  I inserted a MythFillEnabled
record with data of 1 and hostname of scpvr.  I then reran the
mythfrontend and went through the general settings.  The mfdb data had
not changed.  In several minutes I noticed a log entry for MFDB and it
ran automatically.  So it is working now.

It appears that the problem maybe due to the wrong hostname being used
in the settings.  The multiple hostnames may be confusing the code.  I
did notice some settings have the right hostname.

I am going to check my backup to see if the linux hostname was there.  I
changed the hostname after install but before setup so linux may have
been the hostname before scpvr.  The RPM may have run a script that used
the old hostname.  I also want to check what records in the settings
table change when I disable mfdb in the frontend settings menu.

It is likely that if I kept the same hostname that I would not have a
problem.  It changed because I did not remember the old one when I
installed SuSE 10.2.

Thanks for all your help.  If I find out some more information I will
post it in the Running mythfilldatabase thread.

73 Eric