[mythtv] Mythvideo DVD ripping

[Lawrence Rust]

On Mon, 2011-05-09 at 10:27 -0700, Robert McNamara wrote:
> On Mon, May 9, 2011 at 9:15 AM, Lawrence Rust <lvr at softsystem.co.uk> wrote:
> >
> > I would very much like to see this feature re-integrated into 0.25 or
> > later.  What do other users and developers think?
> 
> I would be more inclined to return it if it ripped discs to Storage
> groups.

That isn't too difficult

>   A lot of effort is being expended on kludging along local
> playback/rip methods and little to none is being spent to complete the
> transition to SGs, which is the way we're ultimately going.  This is
> the reason I have resisted patches to enhance or modify local file
> playback in the past, and the source of my unease with restoring local
> DVD ripping.

I sense a degree of reluctance about any form of 'ripping' since my
contributions to mythmusic ripping and CD lookup seem to have been
largely ignored.

> I also have long been unhappy with the "spawn all sorts of external
> command line utilities" method of DVD ripping, and had hoped to
> restore DVD ripping with a much simpler approach that used a
> library/API-based method, but haven't been satisfied with what I've
> seen there either.

There is one great advantage with an external daemon for ripping -
parallelism.  Without that, when a user exits mythvideo (as is the case
with mythmusic) then the ripper thread is deleted.  Using an external
process allows the overlap of ripping (which can take minutes) with more
rewarding activities - TV/video, browsing, slide show, screen saver
visuals etc.  And on return, the latest rip status is shown.  It is a
moot point if/when mythfrontend exits then the ripper daemon should also
exit too, crashes excluded ;-)

Conversion to use an in-process transcoding library (like ffmpeg) isn't
that difficult, but given that a number of utilities already exist to
convert one file format to another then why bother?   The overhead of
process creation/destruction is insignificant compared with the
transcoding.

> >
> > The following small patch to the video directory scan logic ensures that
> > a file which is accessible via both methods is only accessed by the file
> > path:
> >
> > http://www.softsystem.co.uk/download/mythtv/libmythmetadata-Prefer-local-pathnames-to-myth-URLs.patch
> 
> I'll think about incorporating this, but as mentioned above, I'm not
> comfortable implementing any new functionality for local playback/rip
> of videos-- it is to be removed and the effort is better spent
> polishing SG-only playback-- I would very *very* much appreciate
> patches to knock down the sole remaining limitation of videos-via-SG:
> encrypted playback of DVDs.

At present, this is only sensibly achieved by incorporating and adapting
the libdvdcss sources for use with the myth protocol.  Not in itself too
difficult but what are the advantages?

>   Then the above wouldn't be necessary and
> we could complete the transition to SG-only videos.

Let's turn this on its head - why can't the myth: protocol become a
proper OS device?  Then libdvdcss would support it directly.

If you can provide some guarantees then I might be encouraged to explore
one of these routes.

-- 
Lawrence