[mythtv] mythcommflag possible bug?

[Søren Dalsgaard]

Hi,

On 26/02/07, Rick Bassham <brodrick.bassham at gmail.com> wrote:
>
> On Mon, 2007-02-26 at 12:56 +0100, Søren Dalsgaard wrote:
> > But the result is more or less useless. A ~1h show shows as being +2h
> > and when fast-forwarding at x3 - x5 makes a sudden jump from approx
> > 1-2m to 17m.
>
> I had this same problem when I accidentally ran a front-end (.20) that
> used a newer schema than the back-end (.19) was using, I removed the new
> front-end, and my other, old front-end (.19) had this issue.  I can't
> remember what I did to fix it, but I do remember I found the answer in
> the forums.  Just search the forums for issues related to
> downgrading/reverting the database to a previous schema.


I have no reason to believe that I've been mixing versions(!). Frontend &
backend are the same version, schema is 1160 but a rebuild still messes up
the seektable (but it *does* create one).

Months ago I had a similar problem with an earlier version of 0.20 and I was
told that the RebuildSeekTable code in mythcommflag had been updated and was
possibly buggy. I wouldn't mind debugging this problem but I need some
understanding of which frames result in an entry in the recordedseek and how
it is determined if the frame is a 'keyframe'(?) and how to keep track of
the time - which is why the table is there in the first place as far as I
can tell from what I was able to dig up on the net.

Søren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20070226/9157fe0f/attachment.htm