Page 1 of 1

Handbrake quits with no message as soon as it starts convert

Posted: Fri Sep 21, 2007 6:20 pm
by chromeboy
Handbrake automatically closes without a message as soon as the movie starts to convert. The program worked fine yesterday but when I booted my computer up this morning, the program no longer works. I've even tried the same DVDs as yesterday and they don't even work anymore. Any ideas?


I discovered that the problem was putting the target size at 800 MB for a full movie. However this worked yesterday with no problem

same here

Posted: Sat Sep 22, 2007 9:08 pm
by willzone1
same here. i've been trying to get some help, but nobody has helped me either

Posted: Sat Sep 22, 2007 10:21 pm
by hawkman
willzone1: You were asked to post a crash log in this thread - and I told you how - but you haven't done, yet. So saying that noone has helped you is stretching the truth a little. :)

chromeboy: I'm afraid I'm not sure what's going on. We've had a couple of reports of problems with target size, but not the torrent of abuse one would expect if there were a widespread problem. It's been noted, though. HB 0.9.1 will be out relatively soon, we'll see if that changes things.

Posted: Mon Sep 24, 2007 5:32 am
by chromeboy
OK so the problems are nonstop. I rip a movie with target size at a gig and it works fine. then i tried the same movie again and it didnt work. When I do 2 passes (turbo 1st or not) it finishes first pass then "unexpectedly quits" as soon as pass 2 begins. If i try one pass, the file ends up being 180 MB or so even though i'd have target size at 800-2000MB. The quality is deplorable. I didn't have these problems for the first like 8 or so movies but now it's non stop. I waste all this time ripping the first pass, just for it to quit. When will there be a fix? When will the update come out?

*edit* now the program just dies. Started ripping a new DVD to test it and it died within 2 minutes of it

Posted: Mon Sep 24, 2007 5:01 pm
by dynaflash
There is a known problem with target size using the macgui for 0.9.0. Try your encodes using abr or constant quality until the next version comes out.

As for when it will be. Likely in a few weeks as we are currently bug testing, etc. You will know when it is out.

Posted: Mon Sep 24, 2007 6:13 pm
by chromeboy
Thanks for the response. Do you think I should just downgrade to an older version?

Posted: Mon Sep 24, 2007 8:05 pm
by eddyg
chromeboy wrote:Thanks for the response. Do you think I should just downgrade to an older version?
That's your decision really isn't it?

Is there anything in 0.9.0 that you need more than fixed size encoding?

Posted: Mon Sep 24, 2007 8:16 pm
by chromeboy
I dont really know the difference between this one and the older versions so i dont know what the new versions have. I'm just trying to make it so everything i rip is around 800 MB so I dont waste a lot of space.

downgrade

Posted: Mon Sep 24, 2007 10:48 pm
by willzone1
downgrading fixed my issue with this. and 0.8.5 b1 has all the things that I need like de-interlacing (although it works better in 0.9.0 i think?)

sorry for being impatient up above, but it had been like 3 weeks and i even made my own topic and nobody answered to anything. but still, i was rude and i'm sorry.

Posted: Mon Sep 24, 2007 10:53 pm
by hawkman
chromeboy wrote:I dont really know the difference between this one and the older versions so i dont know what the new versions have.
Sounds like you may as well downgrade for now, then. Or wait for 0.9.1, if there's nothing you urgently need to rip.

willzone1: Don't worry. And yes, deinterlacing is much better in 0.9.0 - if you choose "Slow" or similar. The "Fast" option is the same deinterlacing present in previous versions; it sucks pretty hard in comparison, it has to be said. You may want to hold off on ripping interlaced material till 0.9.1 if that's going to be a problem.

Posted: Mon Sep 24, 2007 10:57 pm
by willzone1
eh, i'm not a quality freak... and in 0.9 i was using fast deinterlace because i have a 800 Mhz ibook......... i already wait overnight for an encode, and using slow deinterlace wouldn't help