[mythtv] recordedmarkup table, commercial flagging,
cpinkham at bc2va.org
Sun Jul 25 17:23:40 EDT 2004
> 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. :)
/usr/bin/mysqldump -u mythtv -pmythtv --add-drop-table mythconverg \
| gzip -c \
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
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.
More information about the mythtv-dev