[mythtv] Mythvideo DVD ripping

Raymond Wagner raymond at wagnerrp.com
Mon May 9 21:20:17 UTC 2011

On 5/9/2011 16:42, Lawrence Rust wrote:
> On Mon, 2011-05-09 at 10:27 -0700, Robert McNamara wrote:
>> 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.

Several months ago, another user was interested in re-introducing the 
DVD ripping capability.  The suggestion for what would be accepted would 
be a very simple utility that did nothing but rip the DVD directly to a 
decrypted ISO, and insert it into the MythVideo tables as-is.  The 
utility would have to be backgrounded, either with a widget displaying 
the progress, or with a popup that notified a user upon completion.

The ripping process would not take more than a few minutes, and the user 
would only have to keep mythfrontend open.  In that event, there would 
be no advantage of using an external daemon.  Transcoding would not be 
part of the ripping process at all, but the user could optionally run a 
user job through the jobqueue to transcode as they saw fit.

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

One of the devs worked up something similar to this a few years back.  
He had a Sony DVD turntable hooked up to his backend, and added some 
protocol commands to select the proper disk, and share it using NBD.  
The block device was subsequently mounted on the frontend, and played 
just as a local optical disk.  The problem is mounting.  Doing so 
requires root privileges, or sudo set up with the password requirements 
removed.  If we want to use the existing myth:// protocol, we either 
need to write a FUSE implementation, or a new kernel module, to support 
the device.

While the code itself may be simpler, it would result in a significantly 
more complex setup on the part of the user to get the system working, 
which goes against the entire purpose of storage groups and streamed videos.

More information about the mythtv-dev mailing list