[mythtv-users] Frontend cannot see seektable/cutlist

[Matt Clifton]

That was the problem, even though my system clock had the right time, it was for whatever reason set on the wrong time zone. Everything seems to be working great now!

Thanks!
-Matt

----------------------------------------> Date: Wed, 26 Sep 2007 13:48:13 -0400> From: rbsteffes at gmail.com> To: lynx44 at u.washington.edu; mythtv-users at mythtv.org> Subject: Re: [mythtv-users] Frontend cannot see seektable/cutlist>> Does 'date' return the current time with the correct locale (ie time> zone and daylight savings time)?>> On 9/26/07, Matt Clifton  wrote:>>>> Thanks for the confirmation. Any ideas on why my remote frontend is>> reporting incorrect times and how to fix it?>>>> Thanks,>> -Matt>>>> ________________________________>> Subject: Re: [mythtv-users] Frontend cannot see seektable/cutlist>> From: rossco at whyza.net>> To: lynx44 at u.washington.edu; mythtv-users at mythtv.org>> Date: Wed, 26 Sep 2007 22:35:51 +1000>>>>>> the seek table is obtained from the mysql table recordedseek.>>>> recordedseek seems based of start times, so yes, it sounds like your time>> problem could cause the seek table to have issues.>>>> On Wed, 2007-09-26 at 06:48 +0000, Matt Clifton wrote:>> The machine which runs my backend is able to skip commercials just fine,>> but when I run a separate frontend it is unable to see the seektable or>> cutlist. When I press "e", it says "No Seektable," and when I press "z" it>> says "Not Flagged." I tried rebuilding one of my recordings both on my>> frontend machine and my backend machine with mythcommflag, and it>> successfully completed, but the frontend still reports the same status and>> the commercials cannot be skipped. I also tried running mysqlrepair, but it>> reported no errors. I was previously running one of the "bleeding" (21)>> releases from ATRPMs, but I am now running 20.2.>>>> I think a related issue may have to do with the fact that my separate>> frontend reports my recording times as being off by 3 hours; for example, a>> recording that started at 4:00 is reported as being recorded at 7:00. The>> machine that runs my backend reports the correct times, and so does the>> database. I only am wondering if this is the problem since I read a post I>> found on google that was somewhat related, although he caused the error>> himself by modifying his /etc/localtime file. My time is correct, however.>>>> Otherwise, I'm wondering if the database schema from the bleeding release I>> was running is somehow causing problems.>>>> -Matt>> _________________________________________________________________>> Can you find the hidden words? Take a break and play Seekadoo!>> http://club.live.com/seekadoo.aspx?icid=seek_wlmailtextlink>> _______________________________________________>> mythtv-users mailing list>> mythtv-users at mythtv.org>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users>>>>>> ________________________________>> Discover the new Windows Vista Learn more!>> _______________________________________________>> mythtv-users mailing list>> mythtv-users at mythtv.org>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users>>>>> _______________________________________________> mythtv-users mailing list> mythtv-users at mythtv.org> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE