[mythtv] Mythvideo DVD ripping

[Robert McNamara]

On Mon, May 9, 2011 at 1:42 PM, Lawrence Rust <lvr at softsystem.co.uk> wrote:
>> I would be more inclined to return it if it ripped discs to Storage
>> groups.
>
> That isn't too difficult

Cool.  That would be a definite prerequisite for me to consider
restoring DVD ripping in any fashion.

>
> 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.
>

Nothing you've done has been ignored-- I'm sure you're aware that
we're all working on our spare time, and that we have hundreds of
tickets-- Speaking for myself, I work first and foremost on tasks
which are fun and interesting to me, and that goes double for
tickets-- and even then, only when I have enough spare time to get to
them.  Rest assured that all of your tickets and patches will be
evaluated eventually, but we are sorely undermanned and most of us can
only work as hard and as long as real life and our limited attention
spans allow.  The above is the main reason I've tried to be
encouraging about your work-- so that you knew that even if things
weren't as quick as you would like, that you at least got the
impression that the contribution was noted.

Also, some of us are hesitant to delve too far into code which is
maintained by a currently active developer for fear of stepping on
their toes-- MythMusic is in flux right now as its maintainer is
working privately on a total rewrite.  With that in mind it's
(hopefully) easy to see why some of us might not choose such patches
as our first (or fifth, or tenth) priority.

>> 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 ;-)

I'm not against an external daemon.  I'm against an external daemon
which is merely a wrapper for a bunch of command line tools whose
arguments change with the direction of the wind.  We already have to
compensate for a number of "transcode" versions and their command
lines, I'm not eager to reinstate such a thing.

>
> 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.
>

I think this misses the original point.

>
> 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?
>

We've spoken about this in IRC and agreed that it's not an approach we
are comfortable with.  Thus it's a complicated programming exercise
(albeit not an impossible one).

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

Lots of things are possible.  Given that's not likely to happen any
time soon, all I can do is say that I hope you take some interest in
helping us complete the migration to Storage Groups, and wish you all
my best.

Robert