dvd::rip does not complete ripping of disc via gui in karmic

Update, I've copied the rip commands out of the debug window and ran them via CLI. Mind you that the rip process completes there, however the title is incomplete and seems get chopped off at the same point as running with the GUI. I will do some more testing and post back the actual command string that is breaking. Perhaps my initial statement is wrong and it is indeed the rip command called upon that is dumping out. Will have more tomorrow.

It appears this is a problem with dvd::rip v0.98.10. If anyone else can confirm this, then I would recommend a regression back to dvd::rip v0.98.9 since this had minimal to no problems that I saw and at least I could actually rip a full DVD with v0.98.9. To date, I have not yet gotten on DVD to acquire a full rip using v0.98.10. :(

Update: I now believe it is an issue with transcode and not dvd::rip. I just made an attempt with dvd::rip v0.98.9 and it still failed. So I re-installed dvd::rip v0.98.10 and am now attempting with transcode v1.0.7 (Jaunty's version). I will update the bug to reflect my findings.

Ok, failed again ... :( At this point I am unsure as to what is causing this. My best guess is a library or something that transcode depends on. I am 99% sure dvd::rip is not the problem nor is transcode, but some dependency is causing this. I am stumped at this point and hope someone with knowledge on this topic will reply here soon. :( Until then, I am leaving this bug as affectin transcode since it is the 'tcextract' command that seems to be failing.

Changing back to 'dvdrip' since, well, it's obviously not performing as it should. :(

Attempting to rip a DVD via GUI dvd:rip will freeze, near the end of the transcoding no matter the pass #. Here is the log file associated with the rip. I tried canceling the transcode a few times, when I noticed it just hanging at the end, and restarted.

Ubuntu 9.10 x64 (Karmic)
Kernel:2.6.31-14-generic
CPU:AMD Turion(tm) II Ultra Dual-Core Mobile M600
Dvd:Rip: 0.98.10

Attempted this dvd rip again, with dvd:rip 0.98.9. The rip itself fails at 70%, yet dvd:rip states 'Job 'Rip - title #1' finished", which is false.

Ubuntu 9.10 x64 (Karmic)
Kernel:2.6.31-14-generic
CPU:AMD Turion(tm) II Ultra Dual-Core Mobile M600
Dvd:Rip: 0.98.9

IF more information is needed, please post required commands.

Marked this confirmed since PenquinCoder is experiencing the same problem. Was beginning to think I was alone ... :(

I am getting the same problem same disks ripped with no problems in Jaunty
Executing command: rm -f /home/jaimie/dvdrip-data/perfect-storm/vob/001//perfect-storm-???.vob && execflow -n 19 tccat -t dvd -T 1,-1,1 -i \/dev\/sr0 | dvdrip-splitpipe -f /home/jaimie/dvdrip-data/perfect-storm/tmp/perfect-storm-001-nav.log 1024 /home/jaimie/dvdrip-data/perfect-storm/vob/001//perfect-storm vob | tcextract -a 0 -x ac3 -t vob | tcdecode -x ac3 | tcscan -x pcm && echo EXECFLOW_OK
Mon Nov 16 15:38:09 2009 Rip - title #1: 10% done.
Mon Nov 16 15:39:47 2009 Rip - title #1: 20% done.
Mon Nov 16 15:41:20 2009 Rip - title #1: 30% done.
Mon Nov 16 15:42:41 2009 Rip - title #1: 40% done.
Mon Nov 16 15:44:15 2009 Rip - title #1: 50% done.
Mon Nov 16 15:45:45 2009 Rip - title #1: 60% done.
Mon Nov 16 15:47:18 2009 Rip - title #1: 70% done.
Mon Nov 16 15:49:00 2009 Executing command: execflow tcprobe -H 25 -i /home/jaimie/dvdrip-data/perfect-storm/vob/001/ && echo EXECFLOW_OK
Mon Nov 16 15:49:02 2009 Program stream units calculated
Mon Nov 16 15:49:02 2009 Enabled PSU core. Movie is NTSC and has more than one PSU.
Mon Nov 16 15:49:02 2009 Job 'Process title #1' finished
Mon Nov 16 15:49:02 2009 Job 'Rip - title #1' finished

Rip did not finish

Same problem here too, get to about 75% and just...stops cold

Dev team, is there anything we can do or anything we can provide you to assist in facilitating a fix for this issue?

I've done the math and the actual rip process bails out at ~95% of the title length resulting in a none complete rip. This also leads me to believe dvd::rip is getting a false progress rate echoed back to it from the sub command called upon to do the actual rip or dvd::rip itself cannot compute the progress accurately. Either way, this is irrelevant and arbitrary to the problem at hand. As stated before, running the command from CLI yields the same results. On a test, I get the following echoed back to me after a ~95% completed rip.

[ ... ]
 1 109415 10138 10137 3731729 13
 1 109416 10138 10138 3731772 2
 1 109417 10138 10138 3731772 3
 2 0 0 0 3731840 0
--splitpipe-finished--
[tcscan] audio frames=215176.00, estimated clip length=8607.04 seconds
[tcscan] (min/max) amplitude=(-0.993/0.954), suggested volume rescale=1.007
[tcscan] V: 215176 frames, 8607 sec @ 25.000 fps
[tcscan] A: 131.33 MB @ 128 kbps
USER CDSIZE: 650 MB | V: 518.7 MB @ 493.7 kbps
USER CDSIZE: 700 MB | V: 568.7 MB @ 541.2 kbps
USER CDSIZE: 1300 MB | V: 1168.7 MB @ 1112.3 kbps
USER CDSIZE: 1400 MB | V: 1268.7 MB @ 1207.5 kbps
EXECFLOW_OK

And that is after executing the following command.

rm -f /opt/dvdrip/[SOME TITLE]/vob/001//[SOME TITLE]-???.vob && execflow -n 19 tccat -t dvd -T 1,-1,1 -i \/dev\/sr0 | dvdrip-splitpipe -f /opt/dvdrip/[SOME TITLE]/tmp/[SOME TITLE]-001-nav.log 1024 /opt/dvdrip/[SOME TITLE]/vob/001//[SOME TITLE] vob | tcextract -a 0 -x ac3 -t vob | tcdecode -x ac3 | tcscan -x pcm && echo EXECFLOW_OK

Also, this is where my dependencies sit as far as installed versions.

  Program Version
  -------------------------------
  dvd::rip 0.98.10
  transcode 1.1.4
  ImageMagick 6.5.1
  ffmpeg SVN-r19352-4:0.5+svn20090706-2ubuntu2,
  xvid4conf not installed
  subtitle2pgm 0.3
  lsdvd 0.16
  rar 3.90
  mplayer 4.4.1
  ogmtools 1.5
  dvdxchap 1.5
  mjpegtools 1.9.0
  xine 0.99.6
  fping 2.4
  hal 0.5.13
  -------------------------------

It would be really nice to get a response from someone just to know you are aware that this is a problem and possibly assist us in redirecting this bug to another team if it is determined a transcode issue or other dependent package. Waiting in silence is sort of frustrating.

Just attempted with Lucid's version of transcode (1.1.5 -- latest) and it bombed out with the same results.

I think I may have found a plausible workaround for this issue by using CLI for just the rip process and the dvd::rip GUI for the rest of the project. Currently preforming a few tests to validate. I will post my findings if they prove to be accurate.

OK, here is my lost comment again: The two uploaded files (see before this comment) show a similar problem, but while transcoding (rip is OK, vob files work). I get a segfault, maybe that can help to determine the cause of the failure.
Thanks,
Martin

So far it seems transcode is working as it should for me. I have a few more tests to run on my workaround before I post it. I do however get those same seg fault errors, but the resulting encoded file seems to function properly. Could this possibly be another bug specific to transcode?

Ok scratch the workaround ... I've confirmed that dvd::rip is just not computing the progress right. See my initial reasoning for filing this bug. If you rip with it, when it locks up, save your project and the close it out. Then open up the first VOB and last VOB with VLC; you should have a complete rip. If not, you selected the wrong title. If all is well, open dvd::rip back up, open your project you saved, and now you can continue with the transcoding! I am fairly confident my initial statement is just and the problem is somewhere in dvd::rip's code. I've tested five titles on this theory and all confirm this statement.

I've been having this same problem here too... I'm trying the workaround as noted..

I have also noticed that the vob files do show up correctly when I browse to the folder.. So it looks like the workaround should work..

I also found something interesting as well while transcoding. Say your rip stops at 72.34%. When you transcode, it will complete a pass at 100% plus the delta missing from the rip. In other words (100-72.34)+100=127.66% which it the completion time for transcode on a single pass. This is more or less looking like a logic issue in dvd::rip rather than a rip/transcode flaw.

I've went to using K9copy... I think I may like it better than dvdrip.. Excellent GUI it has..

I recommend you check it out..

Also.. another good thing to do to ensure your multimedia is setup correctly...

To enable the majority of multimedia requirements and options to work in UBUNTU...

Go to: http://ubuntuforums.org/showthread.php?t=766683

Same problem here. Rip thinks it's done but the log file shows it only went to 70%.

Tue Nov 24 06:37:24 2009 Rip - title #1: 10% done.
Tue Nov 24 06:39:09 2009 Rip - title #1: 20% done.
Tue Nov 24 06:40:34 2009 Rip - title #1: 30% done.
Tue Nov 24 06:41:45 2009 Rip - title #1: 40% done.
Tue Nov 24 06:43:12 2009 Rip - title #1: 50% done.
Tue Nov 24 06:44:12 2009 Rip - title #1: 60% done.
Tue Nov 24 06:45:07 2009 Rip - title #1: 70% done.
.
.
.
Tue Nov 24 06:45:57 2009 Job 'Process title #1' finished
Tue Nov 24 06:45:57 2009 Job 'Rip - title #1' finished

this problem is also seen in Debian Lenny if that helps any.

This maybe a transcode bug on how it relays its progress back to dvd::rip. However, I'd need a perl expert to prove this.

Perhaps I'll file a bug with the dvd::rip maintainer...

Sent to upstream.

Thanks, although not critical, it would be nice to see a fix. It has to be something really simple.

Thanks for getting this fixed. I miss my DVD Rip. If you need me to test anything send me an email.

Just another comment: I was able to get the vob files onto the hard drive and in Totem the vid played from the beginning, however when dvdrip had finished encoding the avi file, the vid started at around 10 minutes into the vid.

gray, sounds like a PSU issue. Did/do you have PSU core enabled?

Hi Luke

Sorry, but could you elaborate a bit ? What does having PSU enabled mean in this context ? Where would I check for that ? I am not a total newbie in Linux, but this is my first laptop and first double processor.

I am running on a core 2 laptop (Ubuntu sees 2 CPUs as per the system monitor) with 2 GB of RAM which is plugged into mains when doing anything power hungry like this. The OS is 32 bit Ubuntu 9.10. I usually leave the machine undisturbed when running dvd::rip. On my old Pentium 4 with one CPU I always found dvd::rip very reliable, so am wondering if the double CPU is throwing the process off in some way ?

When ripping a vid, dvd::rip always seems to stop at around the 85 % - 95 % mark in the ripping progress bar. I then save the project and close dvd::rip, else I cannot go any further as the buttons related to the next steps in the process are greyed out. When i restart, the greyed out buttons are now usable. the point i am trying to make is that the rip of the vob files works fine, as tested in a vid player where both the beginning and the end of the vid are in place, but when encoded to avi format, it would appear that the 10% - 15% that dvd::rip thinks has not been ripped is somehow related to the missing bit in the beginning of the vid.

Thanks
Gray

Hi Luke

Just a quick query:

Would the fact that I am running a 32-bit OS on a machine that ideally should have a 64-bit OS make any difference ? I opted for 32-bit for program compatibility but maybe it does not run CPU intensive tasks quite as accurately ?

Gray

gray, send me an email. I don't want to turn this bug report into a forum thread ;). I'll be glad to help you, just email me,.. <email address hidden>

Alessio, bug still says it needs forwarding to upstream. Unless I am missing something.

Luke, I've already forwarded to Jörn Reder, the upstream's author.

I hope to hear from him soon.

Ok, yeah, I just found out from his website that he does not use launchpad to track bugs. Thanks.

Hiho,

at first, sorry that answering to this bug took some time, but I had
to upgrade one of my Ubuntu workstations to Karmic first and of
course had to take time to reproduce this bug somehow...

My diagnostics so far:

- I think what happens here, is that transcode can't copy all
  frames from the title to the harddisk, resp. the number of
  frames announced in the TOC (Table of Content) of the DVD
  differs too much from the number of frames grabbed by transcode.

- dvd::rip can't do anything against the short ripping itself,
  but there was a bug that this was not reported as an error,
  instead the job just appeared to be hanging.

  The short ripping could be a transcode / libdvdread issue,
  probably it depends on the DVD and may be some nasty copy
  protection which uses malformed information in the DVD TOC.
  Unfortunetaly dvd::rip relies on proper operation of transcode
  here and in particular has no code (and never will have) to
  circumvent any copy protection.

- The bug was not in dvd::rip itself, but in a Perl module used
  by dvd::rip (Event::ExecFlow). Happily enough both share the
  same author ;)

- Please use v0.64 of Event::ExecFlow which is available here:

  http://www.exit1.org/packages/Event-ExecFlow/dist/Event-ExecFlow-0.64.tar.gz

  I recommend installing it this way (to prevent conflicts with
  the version installed to your system directories), as a normal
  user - not root!

    % perl Makefile.PL INSTALL_BASE=~/myperl
    % make test
    % make install

  Then modify your environment this way:

    % export PATH=~/myperl/bin:$PATH
    % export PERL5LIB=~/myperl/lib/perl5

  And start dvd::rip from command line:

    % dvdrip

  Now you should get the "ripping short" error message, an
  immediately aborted job and a properly working dvd::rip
  afterwards (no hanging).

- As well I have made a preliminary build of dvd::rip, which
  turns the "ripping short" error into a warning, so the ripping
  process continues and the user can decide whether the missed
  frames are critical or not. Get it from here:

  http://www.exit1.org/dvdrip/dist/dvdrip-0.98.11_01.tar.gz

  (this is preliminary because 0.98.11 will contain more
   stuff which has accumulated on my harddisk and probably
   will be released during x-mas vacation)

  I recommend to install it as well to your home directory
  as with Event::ExecFLow:

    % perl Makefile.PL INSTALL_BASE=~/myperl
    % make test
    % make install

  Then always start dvd::rip this way:

    % export PATH=~/myperl/bin:$PATH
    % export PERL5LIB=~/myperl/lib/perl5
    % dvdrip

- If you want to get rid of this extra Event::ExecFlow and
  dvd::rip installation just remove the ~/myperl directory.

Please report here whether these diagnostics are true for your
cases and whether the newer versions now work as expected.

Jörn

Jörn, thanks for your response! I welcome your fix, although I still believe there is an underlying issue. Mainly because I have tested discs that worked fine in Jaunty however have the problems stated above when done in Karmic. Again, every test I have done thus far in Karmic still yields a complete rip. I, however, do agree with you that it could be an issue with reading the number of frames in the TOC. I also noticed that the libdvdread package was upgraded between the to releases. I am going to install the libdvdread package from Jaunty and see if that sheds any light on the subject. I'll report my findings once I get around to it. Also, this got me thinking,..could it be an issue with libdvdcss? Thanks again for helping us out!

Jörn, thanks for your reply!

event-execflow 0.64 is now available for Lucid.

Jörn Reder wrote:

Hi,

> I recommend to install it as well to your home directory
> as with Event::ExecFLow:
>
> % perl Makefile.PL INSTALL_BASE=~/myperl

I got to this step and got the error:

% perl Makefile.PL INSTALL_BASE=~/perl/dvdrip
Checking if your kit is complete...
Warning: the following files are missing in your kit:
         perl-modules/AnyEvent-1.02.tar.gz
         perl-modules/Event-ExecFlow-0.63.tar.gz
         perl-modules/Event-RPC-0.90.tar.gz
         perl-modules/Gtk2-Ex-FormFactory-0.65.tar.gz
Please inform the author.
Writing Makefile for Video::DVDRip

Note that it seems to be looking for Event-ExecFlow-0.63 instead
of 0.64.

% which execflow
/home/lmulcahy/perl/dvdrip/bin/execflow
% echo $PERL5LIB
/home/lmulcahy/perl/dvdrip/lib/perl5

However 'make test' and 'make install' succeed.

> % make test
> % make install
>
> Then always start dvd::rip this way:
>
> % export PATH=~/myperl/bin:$PATH
> % export PERL5LIB=~/myperl/lib/perl5
> % dvdrip
>
> - If you want to get rid of this extra Event::ExecFlow and
> dvd::rip installation just remove the ~/myperl directory.
>
> Please report here whether these diagnostics are true for your
> cases and whether the newer versions now work as expected.
>
> Jörn
>

So I did a rip of a unencrypted disc and it worked 100% fine -- no errors at all. Jörn, your patch helps in that we do not have to re-start dvd::rip. But after finding that an unencrypted disc works, this leads me to think you may be on to something about the TOC, CSS and the number of frames. By having this work with an unencrypted disc I am now wondering if this maybe an issue with libdvdcss? That or what you were saying about possible new methods of encryption on a disc. Regardless, I am happy to report with the patch to toss up the warning, I have not yet had any problems what so ever transcoding and backing up discs! :)

Black Trenchcoat, try this...

dpkg -l | grep execflow && wget http://mirrors.kernel.org/ubuntu/pool/universe/e/event-execflow/libevent-execflow-perl_0.64-0ubuntu1_all.deb && sudo dpkg -i libevent-execflow-perl_0.64-0ubuntu1_all.deb && dpkg -l | grep execflow

You should see v0.63 installed before hand and v0.64 afterwords. Note, a restart of dvd::rip is necessary to effect changes.

Thanks. I have actually been ripping DVDs mostly successfully with
Jörn's patch in spite of the error messages I mentioned. Maybe
about half of the time I get the 'short rip' error and have to
repeat the rip, but after that it runs to completion and produces
a good .avi.

Luke J Militello wrote:
> Black Trenchcoat, try this...
>
> dpkg -l | grep execflow && wget
> http://mirrors.kernel.org/ubuntu/pool/universe/e/event-execflow
> /libevent-execflow-perl_0.64-0ubuntu1_all.deb && sudo dpkg -i libevent-
> execflow-perl_0.64-0ubuntu1_all.deb && dpkg -l | grep execflow
>
> You should see v0.63 installed before hand and v0.64 afterwords. Note,
> a restart of dvd::rip is necessary to effect changes.
>

As libevent-execflow-perl has been entered in Lucid, can we consider this as "Fix Released" in Ubuntu+1?

I'm good with that. Since we have a patch and now have an idea of what the root cause maybe, if we choose to pursue this issue it will be in a package that dvd::rip depends on rather than in dvd::rip itself. Thanks Jörn and all!

I wrongly marked this as "Invalid", we need to bump-up the {build-}dep on libevent-execflow-perl.

This bug was fixed in the package dvdrip - 1:0.98.10-0.2ubuntu5

---------------
dvdrip (1:0.98.10-0.2ubuntu5) lucid; urgency=low

  * Bump-up build-dependency on libevent-execflow-perl (LP: #478710).
 -- Alessio Treglia <email address hidden> Wed, 30 Dec 2009 17:26:49 +0100

Hi Jörn,

On Sat, Dec 19, 2009 at 3:53 PM, Jörn Reder <email address hidden> wrote:
>
> - As well I have made a preliminary build of dvd::rip, which
>  turns the "ripping short" error into a warning, so the ripping
>  process continues and the user can decide whether the missed
>  frames are critical or not. Get it from here:
>
>  http://www.exit1.org/dvdrip/dist/dvdrip-0.98.11_01.tar.gz
>
>  (this is preliminary because 0.98.11 will contain more
>   stuff which has accumulated on my harddisk and probably
>   will be released during x-mas vacation)

There I can find the sources? Do you have a svn/git/bzr repository?

--
Alessio Treglia <email address hidden>
Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0

On Fri, Jan 15, 2010 at 8:54 AM, Alessio Treglia <email address hidden> wrote:
> There I can find the sources? Do you have a svn/git/bzr repository?
>

s/There/Where/

--
Alessio Treglia <email address hidden>
Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0

Just released 0.98.11. Download the source from here: http://www.exit1.org/dvdrip/dist/dvdrip-0.98.11.tar.gz

This bug is back:

Job 'Process title #1' failed with error message:
Job 'Rip - title #1' failed with error message:
It seems that transcode ripping stopped short.
The movie has 209611 frames, but only 167863
were ripped. This is most likely a problem with your
transcode/libdvdread installation, resp. a problem with
this specific DVD.

I, too, am affected by this GUI bug. (Oneiric over here.) -- v0.98.11

Status changed to 'Confirmed' because the bug affects multiple users.

I have found a workaround for this unknown-to-me-cause bug, however -- just ignore the warning, and go ahead to transcode. The process bar will go up to 125%, and produce a higher-than-target-size file, but the result will be fine.

I would appreciate getting to know more about the cause of this issue, though.

As far as I can tell, it's an incompatibility between the version of the
transcoder and the version of dvd::rip. Iirc, and it's been a while since
I got sick of dealing with it and moved to SuSE, the transcoder is a pretty
old version but a newer version can't be installed due to a couple other
dependencies.
On Jan 6, 2012 7:20 PM, "twipley" <email address hidden> wrote:

> I have found a workaround for this unknown-to-me-cause bug, however --
> just ignore the warning, and go ahead to transcode. The process bar will
> go up to 125%, and produce a higher-than-target-size file, but the
> result will be fine.
>
> I would appreciate getting to know more about the cause of this issue,
> though.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/478710
>
> Title:
> dvd::rip does not complete ripping of disc via gui in karmic
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dvdrip/+bug/478710/+subscriptions
>

Alright. Thanks for the feedback.

For an improvement over the above-mentioned workaround, after having ripped, consider reloading the program on a new project of the same name, this time without ripping, for the correct frame count to be taken into consideration. Another, even-simpler avenue might consist of just re-reading the table of contents, again for the correct frame count to be taken into account.

I am not sure if that fixes everything, but I believe it is at least worth a try.

karmic has seen the end of its life and is no longer receiving any updates. Marking the karmic task for this ticket as "Won't Fix".