Mailing List Archive

> > Given that you are referring to seeing these problems after
> > the recording has finished, you're right, that hasn't been
> > addressed.
>
> The most likely thing is that the commercial finding thread hasn't finished,
> or wasn't allowed to finish for some reason.

The backend would have had to have died since the blank frame map is written inside of
tv_rec.cpp before the commercial flagging thread gets fired off. I think the problem
is a missing seektable, but don't think enough info has been given to answer that.

Can anyone experiencing this problem please verify whether normal fast-forward
and rewind work correctly/quickly? I mean both the 5 & 30 second ffwd/rewind as
well as the 10-minute jumps. If these are slow as well that points to the seektable
right? If they are not slow but commercial skipping still is, then check the
recordedmarkup table to see if any rows exist for the chanid and starttime of
the affected program. There should be lots of '3' rows and a small equal number of
'4' and '5' rows. '3' indicates blank frame, '4' indicates commercial break start, and
'5' indicates commercial break end.

If regular fast-forward and rewind is also slow, then you can start looking into the
code to try to determine why you don't have a seektable.

Chris

On Sunday 11 May 2003 05:30 pm, Chris Pinkham wrote:
> > > Given that you are referring to seeing these problems after
> > > the recording has finished, you're right, that hasn't been
> > > addressed.
> >
> > The most likely thing is that the commercial finding thread hasn't
> > finished, or wasn't allowed to finish for some reason.
>
> The backend would have had to have died since the blank frame map is
> written inside of tv_rec.cpp before the commercial flagging thread gets
> fired off. I think the problem is a missing seektable, but don't think
> enough info has been given to answer that.

Not for hardware-based encoding, which he's using.

Isaac

> On Sunday 11 May 2003 05:30 pm, Chris Pinkham wrote:
> > > > Given that you are referring to seeing these problems after
> > > > the recording has finished, you're right, that hasn't been
> > > > addressed.
> > >
> > > The most likely thing is that the commercial finding thread hasn't
> > > finished, or wasn't allowed to finish for some reason.
> >
> > The backend would have had to have died since the blank frame map is
> > written inside of tv_rec.cpp before the commercial flagging thread gets
> > fired off. I think the problem is a missing seektable, but don't think
> > enough info has been given to answer that.
>
> Not for hardware-based encoding, which he's using.

Oops, :) Must have missed that. This thread is longer than my memory right
now....

Well problem should be solved then by Bruce's forecoming patch. Then I
just need to get it so that the blank frame information is written to
the DB at record time for those with software encoding. Already have
something coded up, just need to test/tweak it some.

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If there _isn't_ a seektable, then can some of these issues be
rectified by firing off a background thread that scans through
existing recordings, checks them for a valid seektable signature and
then generates the seektable based on the existing .nuv file? I've
got some files where commercial skip/FF, REW appear to be very slow,
and it's most likely because there isn't a seektable. And since the
frontend is a P3/733, it's even slower.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPr++Hfc1NpCTlP0JEQKy5QCdHlRx0c1pMnMr15FW92QLhXIW3LEAmQEl
aPdId1MA/9NDBx5xhXJYM6xc
=geS4
-----END PGP SIGNATURE-----