[mythtv-users] .25 mythtranscode copy over in .26 failing after upgrade

[Rich Freeman]

On Fri, Mar 15, 2013 at 11:17 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> FWIW, the current design says that anything in Watch Recordings is
> "temporary holding space" for new recordings, kept short term until you've
> watched and deleted them or until you've decided to archive them.

That's what I'm using Watch Recordings for.  I don't plan to keep
stuff after it has been watched, and for the most part I want things
to auto-expire if they're just sitting around.  I am not transcoding
for archivial - I'm transcoding so that my video doesn't consume
6GB/hr (FIOS is pretty generous with bitrates) when I'm watching it on
a 720p TV on a system that should be perfectly capable of something
more efficient than MPEG-2.

Sometimes things do sit around for a few months before they get
watched, but when you have multiple television viewers in the home
with different preferences you tend to record a LOT of video.  If
somebody wants to check every episode of a daily program that airs on
an OTA channel in 1080p you can burn through 30-40GB/week if they fall
behind a little.

I don't expect miracles as far as disk space goes, but transcoding
anything that hasn't been deleted after a few days really cuts down on
storage requirements, even if in the end it is all destined for
/dev/null.

The other option is to upgrade my RAID from 1TB to 2TB drives, but
that seems a bit wasteful (I'd prefer to wait until I could jump to
something closer to 4-8TB/drive since hard drives don't really have
any resale value).

I recall in the past the seek table used to index keyframe in fixed
multiples (ie instead of saying frame 150 was at byte n, the table
would say that keyframe 10 was at byte n, and the player assumed that
the keyframes were every 15 frames, or something to that effect).
That meant that if you used a video format that did not have fixed
keyframe intervals you couldn't seek correctly.

Rich