Anyway, I'm now ripping DVD's to the core and some of them fail. I notice that it only occurs on newer movies and I've seen a reference somewhere to dummy sectors as a ripping protection method on some DVD's.

where finsdown uses windows tool Ripit4me to rip the DVD with the similar issues. And please read my comment below regarding the using folderlocks when copying the ripped DVD folders to LinuxMCE to prevent UpdateMedia from scanning half-copied folder.

best thing to do is go into the kde desktop and install wine (sudo apt-get install wine) which will let you run windows programs on linux. then d/l a dvd ripping program (dvdshrink is good and free but sometimes does have problems ripping some encryption.. dvdfab is one of the best ones and has no trouble and has many features, but dos cost money for a full version) and use that to rip the dvds to an iso file, then simply rename the .iso file to a .dvd file and youre good to go... you will need to go into the pluto admin page and manual add the attributes though

You don't need to update libdvdcss. It decrypts them well. It is a ripper that is failing. Different program, different place.

I'm yet again confused. What do you mean "ripper"? What exactly do I need to look for as a seemless solution?

OK, I'll try to shed some light here:- when you have issues with new disks (copying them to Core AKA ripping), the separate tool is called that copies DVDs sectory by sector into a .dvd file. This is where it fails, according to your description (because of new protection with dummy sectors). I am calling this tool "ripper".

- when you are _playing_ the DVDs or .dvd files (ripped DVDs), the libdvdcss is used to decrypt the DVD for the playback

So, on the stage of copying (where it fails for you), libdvdcss is not used. Therefore it is no sense to look for libdvdcss updates, you should either use different ripper tool (which will not be seamless, but can work) or work on updating the current ripper to handle errors.

I would suggest you to try copying one of the failing DVDs from the commandline usingdd if=/dev/cdrom1 of=/home/linuxmce/testDisk.dvd conv=noerrorto see if it is possible to copy it at all, by suppressing errors (the "conv=noerror" should do this). It is for a start.

This is a C&P from a little script I wrote to rip my DVDs. One little oddity, on occasion the vlc window that pops up will either hang or loop instead of exiting at the end of the movie. If it hangs, no big deal, just kill it. If it loops, better catch it quick 'cause it's likely in an infinite loop continually adding the intro menu to the end of the movie.

I'm a complete newbie to LMCE, but the fact that vlc requires a small gui window to pop up (as far as I can tell) leads me to believe this is not something that would work well with LMCE. Window focus, closing the window if it hangs/loops, etc. If someone knows how to launch an arbitrary script and control a window that pops up I'd be very interested. This would allow me to use vlc to rip, which for me is far more reliable than the integrated LMCE/MythTV methods, then transcode the VOB into a smaller H.264 format. If it were somehow integrated into the current DVD ripping method that picks up the movie info and cover that would be everything I want in DVD ripping functionality.

I'm sure there is a way to do this via manual database update if nothing else, I just don't know how it would handle the vlc window. It also likely would not be able to run as a background task. If someone knows a way to ensure vlc stops at the end of the movie, and perhaps how to hide or not open the window, it should be possible.

OK, after some investigation (please remember that I'm new to LMCE and Linux in general), I've discovered that it seems that the ripping function is performed by the command /usr/pluto/bin/disk_copy which is being called from /usr/pluto/bin/ripDiskWrapper.sh.

In the source code, there is src/Disk_Drive/disk_copy.c which looks to be a plain vanilla 64 bit disk copy program. Basically on any read error, the disk_copy intentionally fails.

What it looks like we need to do is to modify disk_copy.c to ignore bad sector errors. This will probably mean reading just one sector (2048 bytes) at a time, checking the errno if the read returns 0, and checking that position is not EOF. It's going to be much slower. It might be possible to regain some performance by threading the loop.