[mythtv] recordedmarkup table, commercial flagging,

[Chris Pinkham]

> Well, that  is a royal pain in the ass.  My system is used for more
> than myth, and writing special methods for backing up myth as opposed
> to everything else is not something I really want to do.

It's a piece of cake actually. :)

#!/bin/sh

DOW=`date +%w
/usr/bin/mysqldump -u mythtv -pmythtv --add-drop-table mythconverg \
	| gzip -c \
	> /path/to/backup/dir/mythconverg.${DOW}.sql.gz

Then just backup /path/to/backup/dir and exclude /var/lib/mysql/mythconverg/

> > If you absolutely want to start changing things in your DB, you could
> > remove all MARK_KEYFRAME records for transcoded programs and for programs
> > that you know recorded correctly and have a positionmap in the .nuv file.
> > The MARK_KEYFRAME entries are only used for software-encoded videos and are
> > there as a backup for videos that are terminated early because of a problem
> > or because of file corruption.
> 
> As I said, mythtranscode already does this.

And as I mentioned, we could probably also do this for software encoded
programs after making sure the seektable is written to the .nuv file.  I guess
you're using mpeg2 files and transcoding them, so this wouldn't apply to
you, but it is something to keep the size of the recordedmarkup table down.

> transcoded to mpeg4.   The question is, I guess, are these left-over
> vestiges of the original mpeg2 recroding?  Or does avformat decoder
> generate MARK_GOP_FRAME for nuv's too? (the mpeg2 GOP is bascially
> equivalent to a key-frame in nuv..I know the GOP contains header info
> too...)  Since the number of MARK_GOP_START frames increased once I
> commercial-flagged my (already  transcoded) mpeg4 nuv streams, I
> assumed that avformat decoder was generating them.

avformatdecoder isn't used for nuppel format files, only mpeg2 files, so
if there are GOP entries in the DB for a file after the file has been
transcoded, then the transcoder isn't cleaning up the table properly.

If you turned on auto-flagging and restarted the master backend, then Myth
would have automatically flagged the 5 newest recordings so it could have
added in GOP records into recordedmarkup for those recordings if they
were still in mpeg2 format.

> Yes I know all about KEYFRAMES, I am wondering why MARK_GOP_START is
> getting generated for mpeg4 nuvs when I run the commercial flagger

It shouldn't be.  Are you sure they aren't left over from flagging the
original file?  nuppeldecoder.cpp is used to decode the nuppel/mpeg4 file
and that saves a KEYFRAME positionmap to the DB if the file doesn't have
a seektable/positionmap already.

> Okay, thiis makes sense.  As I said, it is less than 1% of the db, no
> reason to deal with it now.  I may need to think aout it more
> carefully though.  After transcoding I'm not 100% sure the blank-frame
> list will be correct if it was really generated durinng recording.  It
> should be, but if it ends up off by a couple frames, that'd be kinda
> bad.

I think most info (if not all) info in the recordedmarkup table for a
recording should be removed after transcoding except possibly for the
commercial skip info if the cutlist was not applied and it is a straight
transcode frame-by-frame.  As you say, blank frames and scene change info
could be off by a frame or two potentially and they aren't really needed
anyway if a commercial skip list is present.  The commercial skip list can
be off by a couple frames and not be a big deal.

-- 

Chris