[mythtv-users] discarding original file after transcoding

[Josh Mastronarde]

On Mon, Mar 2, 2009 at 12:54 PM, Stephen Shelton
<stephen at stephenashelton.com> wrote:
> I've got some shell script wrappers that do some transcoding. While they work
> well, they still do not overwrite the original file or touch the myth database.
> I'd like to incorporate that into my scripts, but have a couple questions:
>
> 1) What all is required here? Of the fields on the 'recorded' table, I'll
> obviously need to modify filesize, and basename if I rename the file. I'm
> guessing the video length is (endtime - starttime), so I either need to have
> those times not reflect the air times, or have the length not reflect the final
> video length. Not a big deal. Do I want to clear the cutlist or commercial flags
> (will they cause me pains otherwise?)

I've spent some time playing with this too:

- 'basename' and 'filesize' look like the only fields that are
specific to the actual recording file in the 'recorded' table

- If you're transcoding to mp4 (which has a built-in seek table that
Myth uses, which mpeg2 doesn't have), you'll want to delete all
entries in 'recordedseek' for that show (get 'chanid' and 'starttime'
from the 'recorded table' to use for selecting).  There doesn't appear
to be a need to rebuild the seektable for mp4, and it broke things
worse when I tried.

- As far as I can tell, leaving the edit points and commercial flags
in place seems to work, as long as you transcode to the same framerate
as the original (the entries in 'recordedmarkup' are frame numbers).
Depending on your keyframe rate, the actual seek may go to a slightly
different point, but should be close.

>
> 2) The basename doesn't really let me put my transcoded files into a separate
> directory. To accomplish this, do I want to change storage groups?

I haven't tried this yet, but it looks like you can define an
additional storage group (e.g. "transcoded"), put your files there,
and change the 'storagegroup' field in the database.  As long as you
don't define scheduled recording jobs to have that storagegroup,
nothing else should get dropped in there.

>
> 3) Will I run into trouble by running ad-hoc sql statements to accomplish the
> above?

Probably, but that's half the fun!  Seriously, it'd be a good idea to
tread very carefully after any upgrade that changes the database.  I
have a daily mysqldump run to save snapshots that I can restore if I
screw things up too badly.

Josh