Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

corrupted time table

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


stef.coene at docum

Nov 16, 2009, 1:14 PM

Post #1 of 13 (1245 views)
Permalink
corrupted time table

Hi,

I don't know how to explain, but I have the feeling that the timing is corrupt
when something is recorded.

When there is a commercial, I jump with the arrow keys back and forward to
skip all the commercials. The first jump is normally a 1 minute jump but it
jumps jump much more, like 2 minutes. All following jumps are normal. So
only the first jump is more than 1 minute. This is also after watching the
show for a while, say 20 minutes. The strange thing is that the timing
information that is showed with the info button is correct. It shows a 1
minute jump, but in 'video' timing, it jumps more.

Also, at the end of a recording there is also something wrong with timing.
When 2 recordings are scheduled after each other and only 1 tuner is used,
some video is missing. When looking at the logs from the backend, the second
recording starts right after the first recording ends.

It's not so easy to explain, but I hope someone says 'hey, I have the same
issues.'

Running ubuntu 9.10 with ubuntu updates from
http://ppa.launchpad.net/mythbuntu/trunk-0.22/ubuntu
(0.22.0+fixes22840-0ubuntu0+mythbuntu3)


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 16, 2009, 1:57 PM

Post #2 of 13 (1210 views)
Permalink
Re: corrupted time table [In reply to]

On 11/16/2009 04:14 PM, Stef Coene wrote:
> I don't know how to explain, but I have the feeling that the timing is corrupt
> when something is recorded.
>
> When there is a commercial, I jump with the arrow keys back and forward to
> skip all the commercials. The first jump is normally a 1 minute jump but it
> jumps jump much more, like 2 minutes. All following jumps are normal. So
> only the first jump is more than 1 minute. This is also after watching the
> show for a while, say 20 minutes. The strange thing is that the timing
> information that is showed with the info button is correct. It shows a 1
> minute jump, but in 'video' timing, it jumps more.
>

The time displayed in the OSD is an estimate and it's not always correct
(some of my 60-minute recordings show as being about 52 minutes long,
but they're actually about 60 minutes of playback).

Also, the seektable may not be correct during LiveTV or recordings in
progress. If you enter playback after the recording finished, you
should get a valid seektable (again, note that the OSD times are
estimates). If you don't, please see
http://www.mythtv.org/wiki/Repairing_the_Seektable /

> Also, at the end of a recording there is also something wrong with timing.
> When 2 recordings are scheduled after each other and only 1 tuner is used,
> some video is missing. When looking at the logs from the backend, the second
> recording starts right after the first recording ends.
That's the time taken to shut down the old recorder and then start the
new recorder (including all its initialization, such as changing the
channel). Note that this is always done--even for back-to-back
recordings on the same tuner and same channel.

Mike

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 16, 2009, 11:23 PM

Post #3 of 13 (1194 views)
Permalink
Re: corrupted time table [In reply to]

> The time displayed in the OSD is an estimate and it's not always correct
> (some of my 60-minute recordings show as being about 52 minutes long,
> but they're actually about 60 minutes of playback).
>
> Also, the seektable may not be correct during LiveTV or recordings in
> progress. If you enter playback after the recording finished, you
> should get a valid seektable (again, note that the OSD times are
> estimates). If you don't, please see
> http://www.mythtv.org/wiki/Repairing_the_Seektable /
I also have this when the recording is finished recording (pff, what a
sentence).
But I don't have this on recordings recorded before the upgrade to 0.22. So
it has something to do with the new 0.22 backend.
I will try to repair the seektable to see if that makes any difference.

> > Also, at the end of a recording there is also something wrong with
> > timing. When 2 recordings are scheduled after each other and only 1 tuner
> > is used, some video is missing. When looking at the logs from the
> > backend, the second recording starts right after the first recording
> > ends.
>
> That's the time taken to shut down the old recorder and then start the
> new recorder (including all its initialization, such as changing the
> channel). Note that this is always done--even for back-to-back
> recordings on the same tuner and same channel.
And this can be a few minutes???? And I didn't had this before the 0.22
upgrade. Starting livetv requires also that the tuner tunes in and it takes 4
seconds before the video starts playing. Far less then the video that I miss
between 2 recordings.


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 16, 2009, 11:47 PM

Post #4 of 13 (1190 views)
Permalink
Re: corrupted time table [In reply to]

On 11/17/2009 02:23 AM, Stef Coene wrote:
>> The time displayed in the OSD is an estimate and it's not always correct
>> (some of my 60-minute recordings show as being about 52 minutes long,
>> but they're actually about 60 minutes of playback).
>>
>> Also, the seektable may not be correct during LiveTV or recordings in
>> progress. If you enter playback after the recording finished, you
>> should get a valid seektable (again, note that the OSD times are
>> estimates). If you don't, please see
>> http://www.mythtv.org/wiki/Repairing_the_Seektable /
>>
> I also have this when the recording is finished recording (pff, what a
> sentence).
> But I don't have this on recordings recorded before the upgrade to 0.22. So
> it has something to do with the new 0.22 backend.
> I will try to repair the seektable to see if that makes any difference.
>

There's likely something else going on if it's more than just the
"estimate is not accurate" display issue, so fixing the seektable won't
help.

>>> Also, at the end of a recording there is also something wrong with
>>> timing. When 2 recordings are scheduled after each other and only 1 tuner
>>> is used, some video is missing. When looking at the logs from the
>>> backend, the second recording starts right after the first recording
>>> ends.
>>>
>> That's the time taken to shut down the old recorder and then start the
>> new recorder (including all its initialization, such as changing the
>> channel). Note that this is always done--even for back-to-back
>> recordings on the same tuner and same channel.
>>
> And this can be a few minutes???? And I didn't had this before the 0.22
> upgrade. Starting livetv requires also that the tuner tunes in and it takes 4
> seconds before the video starts playing. Far less then the video that I miss
> between 2 recordings.

Should be only a few seconds.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 18, 2009, 2:55 PM

Post #5 of 13 (1164 views)
Permalink
Re: corrupted time table [In reply to]

On Tuesday 17 November 2009, Michael T. Dean wrote:
> There's likely something else going on if it's more than just the
> "estimate is not accurate" display issue, so fixing the seektable won't
> help.
I just did some tests. After running
mythcommflag --file <file> --rebuild
the jumping problem is solved. So it has something to do with the seektable
that's not correct. Any idea how I can debug this?


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 18, 2009, 2:58 PM

Post #6 of 13 (1162 views)
Permalink
Re: corrupted time table [In reply to]

On Wednesday 18 November 2009, you wrote:
> On Tuesday 17 November 2009, Michael T. Dean wrote:
> > There's likely something else going on if it's more than just the
> > "estimate is not accurate" display issue, so fixing the seektable won't
> > help.
>
> I just did some tests. After running
> mythcommflag --file <file> --rebuild
> the jumping problem is solved. So it has something to do with the
> seektable that's not correct. Any idea how I can debug this?
What I forgot: the total time of the recording went from 2:14:25 to 2:36:58
after running mythcommflag......


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


andy at squeakycode

Nov 18, 2009, 3:00 PM

Post #7 of 13 (1165 views)
Permalink
Re: corrupted time table [In reply to]

Stef Coene wrote:
> On Wednesday 18 November 2009, you wrote:
>> On Tuesday 17 November 2009, Michael T. Dean wrote:
>>> There's likely something else going on if it's more than just the
>>> "estimate is not accurate" display issue, so fixing the seektable won't
>>> help.
>> I just did some tests. After running
>> mythcommflag --file <file> --rebuild
>> the jumping problem is solved. So it has something to do with the
>> seektable that's not correct. Any idea how I can debug this?
> What I forgot: the total time of the recording went from 2:14:25 to 2:36:58
> after running mythcommflag......
>
>
> Stef
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Have you checked mysql to make sure the tables are ok? I had some weird
problems and found out some of my tables "had been marked as crashed" or
whatever that message is.

-Andy
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 18, 2009, 3:00 PM

Post #8 of 13 (1170 views)
Permalink
Re: corrupted time table [In reply to]

On 11/18/2009 05:55 PM, Stef Coene wrote:
> On Tuesday 17 November 2009, Michael T. Dean wrote:
>
>> There's likely something else going on if it's more than just the
>> "estimate is not accurate" display issue, so fixing the seektable won't
>> help.
>>
> I just did some tests. After running
> mythcommflag --file <file> --rebuild
> the jumping problem is solved. So it has something to do with the seektable
> that's not correct. Any idea how I can debug this?

That means the database table that stores seek information was crashed
when the show was recorded, so the seektable data was corrupt/missing.

If you've repaired the database, then all future recordings will get
valid seektables (barring another table crash). Since rebuilding the
seektable seems to have fixed the recording's seektable, then you (or
some cron job) must have repaired the database (i.e. by running
optmize_mythdb.pl, which is usually done in a daily cron).

Now you just have to rebuild the seektable data for any other recordings
with invalid seektable data. Generally easiest to do on an "as needed"
basis--i.e. when you notice an issue, fix that recording.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 19, 2009, 1:11 PM

Post #9 of 13 (1158 views)
Permalink
Re: corrupted time table [In reply to]

On Thursday 19 November 2009, Michael T. Dean wrote:
> That means the database table that stores seek information was crashed
> when the show was recorded, so the seektable data was corrupt/missing.
>
> If you've repaired the database, then all future recordings will get
> valid seektables (barring another table crash). Since rebuilding the
> seektable seems to have fixed the recording's seektable, then you (or
> some cron job) must have repaired the database (i.e. by running
> optmize_mythdb.pl, which is usually done in a daily cron).
>
> Now you just have to rebuild the seektable data for any other recordings
> with invalid seektable data. Generally easiest to do on an "as needed"
> basis--i.e. when you notice an issue, fix that recording.
I checked for crashed tables, but I found none. I also run the
optimize_mythdb.pl each night and this gives no errors.
Seeking is still a problem on new recordings.

Running mythcommflag fixes the seektable.

Any idea?


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 19, 2009, 1:33 PM

Post #10 of 13 (1156 views)
Permalink
Re: corrupted time table [In reply to]

On 11/19/2009 04:11 PM, Stef Coene wrote:
> I checked for crashed tables, but I found none. I also run the
> optimize_mythdb.pl each night and this gives no errors.
> Seeking is still a problem on new recordings.
>
> Running mythcommflag fixes the seektable.

Some people have said they get the same issue with certain streams from
some broadcasters/rebroadcasters. (I'm guessing you're using DVB or
ATSC/QAM and not analog capture, right?)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 19, 2009, 1:47 PM

Post #11 of 13 (1157 views)
Permalink
Re: corrupted time table [In reply to]

On Thursday 19 November 2009, Michael T. Dean wrote:
> On 11/19/2009 04:11 PM, Stef Coene wrote:
> > I checked for crashed tables, but I found none. I also run the
> > optimize_mythdb.pl each night and this gives no errors.
> > Seeking is still a problem on new recordings.
> >
> > Running mythcommflag fixes the seektable.
>
> Some people have said they get the same issue with certain streams from
> some broadcasters/rebroadcasters. (I'm guessing you're using DVB or
> ATSC/QAM and not analog capture, right?)
PVR500, so analog capture.


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 20, 2009, 3:13 PM

Post #12 of 13 (1106 views)
Permalink
Re: corrupted time table [In reply to]

On Thursday 19 November 2009, you wrote:
> On Thursday 19 November 2009, Michael T. Dean wrote:
> > On 11/19/2009 04:11 PM, Stef Coene wrote:
> > > I checked for crashed tables, but I found none. I also run the
> > > optimize_mythdb.pl each night and this gives no errors.
> > > Seeking is still a problem on new recordings.
> > >
> > > Running mythcommflag fixes the seektable.
> >
> > Some people have said they get the same issue with certain streams from
> > some broadcasters/rebroadcasters. (I'm guessing you're using DVB or
> > ATSC/QAM and not analog capture, right?)
>
> PVR500, so analog capture.
I checked the mysql database and found no corrupt tables. I even cleared all
records in the recordedseek table. No luck, I still have seek problems on
fresh recordings. After running "mythcommflag --file <file> --rebuild", seeking
is ok.

I use a PVR500, but I don't do any commercial flagging. I also don't transcode
the recordings.

Any ideas ?


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


stef.coene at docum

Nov 22, 2009, 6:44 AM

Post #13 of 13 (1058 views)
Permalink
Re: corrupted time table [In reply to]

On Saturday 21 November 2009, you wrote:
> On Thursday 19 November 2009, you wrote:
> > On Thursday 19 November 2009, Michael T. Dean wrote:
> > > On 11/19/2009 04:11 PM, Stef Coene wrote:
> > > > I checked for crashed tables, but I found none. I also run the
> > > > optimize_mythdb.pl each night and this gives no errors.
> > > > Seeking is still a problem on new recordings.
> > > >
> > > > Running mythcommflag fixes the seektable.
> > >
> > > Some people have said they get the same issue with certain streams from
> > > some broadcasters/rebroadcasters. (I'm guessing you're using DVB or
> > > ATSC/QAM and not analog capture, right?)
> >
> > PVR500, so analog capture.
>
> I checked the mysql database and found no corrupt tables. I even cleared
> all records in the recordedseek table. No luck, I still have seek
> problems on fresh recordings. After running "mythcommflag --file <file>
> --rebuild", seeking is ok.
>
> I use a PVR500, but I don't do any commercial flagging. I also don't
> transcode the recordings.
>
> Any ideas ?
I did some tests. I started with an empty mysql database (I only copied some
tables with information about my recordings).

I disabled commflagging and recording something: seeking was not ok.
Then, I started commflagging, but seeking was still not ok. I found lots of
errors in the mythtv-backend log (1 message / millisecond), but I don't know
if they are related to my seeking problem:

2009-11-22 15:25:53.370 [mpeg2video @ 0x129a6c0]Missing picture start code

When I transcode to MPEG4. the seek problem is gone.

Any idea why transcoding is not working without transcoding to mpeg4? And why
this was not a problem before my 0.22 upgrade?

Shall I open a bug report on this issue ?


Stef
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.