MediaFork Quitting, or Failing To Complete Cued Episodes

[drusus]

Hi,

I have been using the last version of Handbrake 0.7.1 for the past couple of months and it has been great.

I have done loads of films and TV programs, which have turned out much better than I could ever have hoped for.. Only one or two small niggles which were sorted out here on this forum.

The other day I downloaded the new MediaFork Beta 1 release, and managed to rip a coupe of normal DVD's without any problems. But today, I have spent the best part of 10 hours trying to get MediaFork to work properly when doing a series of episodes from a DVD.

I have done the following including the same settings I would normally use in Handbrake for a standard UK 4:3 broadcast/DVD.

I read the DVD into MF which as it is doing this says it is reading the Chapters on the disc.

In SOURCE Select the first track
Select File Format: MP4 file
Codec: MPEG-4 video/AAC Audio

Framerate: Same As Source
Encoder: FFmpeg
Av Bit Size: 700
2 Pass Encode SELECTED

Subtitles: None
Language English (No Other Available on this disc)

Audio Sample Rate: 44100
Bitrate: 160

Picture Settings

640 * 480
Aspect Ratio Turned OFF

Cropped to T 6 B 6 R 12 L 20

This is the usual settings I use for a normal UK TV transmission Non Widescreen (4:3)

Used The Que setting, and added each episode, checked all the above settings and changed the file name for each one as it was added to the Que.

So for a 7 episode disc I have 14 items in the Que. as they are all on 2 Pass encoding.

Each time MF carries the encoding out, up to and including episode 5 ( which I can see on my desktop) and then quits.

Now apart from not doing the last two episodes, which is a real bind, when they have been imported into my iTunes movie folder and added to the Library, Itunes throws up an alert when I sync my ipod stating that the files cannot be transferred to my iPod.

If I check the file type of them in iTunes it says that they are 'MPEG-4 video files' ~ which is exactly the same as all my others I have done in Handbrake which work perfectly on my ipod.

I can open them in iTunes and play them, and edit them in iMovie and MPEG Streamclip, and of course Quicktime Pro, but they will not move to the iPod

Now the only time I have ever previously encountered the problem of them not transferring to the ipod has been when they have been encoded as 'Quicktime Movie Files' and they have had to be converted in iTunes. [This sometimes happens when I use Snap Pro Z to catch a streaming video clips off the Internet and it saved them in that format] I have even tried converting them in iTunes, but the files which have now been 'converted' by iTunes, still will not transfer over to the iPod!

I hope I am making this as clear as possible, because it is driving me absolutely nuts, and my eyes are spinning out of their sockets staring at this screen!!

The problem occurs with whichever title of DVD I use that has episodes on. Yet I can do them without any problems at all in Handbrake, including this particular title ("Yes Minister Series One" in PAL format

I don't use the H.264 Encoding as it takes far to long to encode any movie. I only use it for Music videos which are very short.

Can anyone suggest a reason/remedy or just hold my hand ?

Well maybe not the last one, but you get my drift. I am puzzled and would like to know what you people think.


I am running OS X 10.4.8 on a 20" G5 iMac (iSight) PowerPC with 1.5 Gb Ram

Thanks

Drusus

[jbrjake]

I just reproduced this. Crashes silently.

Will definitely make a note to add this to the Trac.

In the mean time, all I can suggest is not batching up so many episodes at once. Sorry, I know that's a lame answer.

It's totally a bug.

[helixomnimedia]

Hello,

I know that this is slightly off-topic, but what is the difference between H.264 and MPEG-4 files? and which ones should i be using?...

As MediaFork crashes just as it finishes encoding a MPEG-4 Files, and the files is on the desktop but it can't be opened in iTunes or Quicktime.
I thought i done something wrong yesterday, so I let it run over night and the same thing has happened.

I don't use the H.264 Encoding as it takes far to long to encode any movie.

This is why I've only used H.264 settings once, as it took 9hours to encode an 42min episode.

Thanks for any information.

[drusus]

I just reproduced this. Crashes silently.

Well thats a relief, at least its not just me.

Will definitely make a note to add this to the Trac.

Thanks
In the mean time, all I can suggest is not batching up so many episodes at once. Sorry, I know that's a lame answer.

I would but I try do do them when I am not using my system, and over night is the best way, so that's why I like to do the lot in one session. ~ I think I will go back to Handbrake for now, and keep and eye on this forum.

Thanks anyhow.
It's totally a bug.

[jbrjake]

drusus: another possibility is the cli.

You could set up a long command line like this, with each rip separated by a semi-colon:

Code: Select all

./MediaForkCLI -i dvd -c 1-4 -o episode1.mp4 ; ./MediaForkCLI -i dvd -c 5-8 -o episode2.mp4

etc.

That way you'd be calling the program separately for each rip, avoiding this bug. I know it's not optimal, but it'd be a way you could take advantage of the updated, slightly faster codecs the latest beta uses.

Some bad news about tracking down the source of this: it doesn't seem to leave a crash report. The program dies suddenly, silently. No "MediaFork crashed unexpectedly" window or anything. I checked all my console logs, it didn't say a word. The uncompleted rip resides in the /tmp folder.

The CLI has a debug log it can output (verbose mode) but it has no queue, so I can't reproduce the behavior. I tried with a long 2-pass encode, one that took longer than encoding 7 episodes in 2-pass, but the problem didn't crop up.

Based on that, I'm going to say this bug is isolated to the queuing system, and not a general buffer overflow or anything like that. But since the queue only exists in the Mac GUI, and the GUI has no debug log...this is going to be tough to pin down.