The Runtime Error 9 thread - reply with yours

[jdobbs]

Ok... Here's what I've found out about the Error 9 as it happens during rebuild. It seems that occasionally something can happen in CCE during the encoding phase that will make one of the output .M2V files be corrupt and incomplete. That fact then, during rebuild, creates either the Error #0004 (Buffer Overrun) or Runtime Error 9 depending upon where it happens.

A workaround follows: You have to reencode the one .M2V that is causing the problem. Look at the LOG, get the name of the file, then copy that files section of description out of the REBUILDER.ECL file into ITEM.ECL, load it into CCE and execute, and then run the rebuild phase again.

The problem is that CCE doesn't seem to give DVD-RB any indication that anything is amiss during the encode phase. I'm going to look at the code and see what I can do.

[Toranaga]

Originally posted by jdobbs
Ok... Here's what I've found out about the Error 9 as it happens during rebuild. It seems that occasionally something can happen in CCE during the encoding phase that will make one of the output .M2V files be corrupt and incomplete. That fact then, during rebuild, creates either the Error #0004 (Buffer Overrun) or Runtime Error 9 depending upon where it happens.

A workaround follows: You have to reencode the one .M2V that is causing the problem. Look at the LOG, get the name of the file, then copy that files section of description out of the REBUILDER.ECL file into ITEM.ECL, load it into CCE and execute, and then run the rebuild phase again.

The problem is that CCE doesn't seem to give DVD-RB any indication that anything is amiss during the encode phase. I'm going to look at the code and see what I can do.

The problem I am talking about is that CCE crashes during encode, and you cannot re-encode the file. If you just close the error message from the crash then RB continues with the next encode, but then you cannot rebuild the files because of the missing encode that crashed.

[NobbyNobbs]

@Toranaga

Have you read the post you quoted at all ?

[b1ackmai1er]

@jdobbs

Love your new tag line.

"Contrary to conspiracy theories -- DVD-RB was not seen meandering around the grassy knoll just before the Kennedy assassination. DVD-RB was questioned and judged as "coincidentally present" by the Warren Commission."

Regards b1m1

[jkcheng122]

i do wanna add that it was cce 2.67.0.9 that i'm having trouble with. since there are other builds of 2.67 i thought i give u the specific one i have.

[wrxblaze]

Hi I tried uninstalling and reinstalling everything to do with rebuilder. I had done quite a few backups before the runtime error 9 began happening, which made me very frustrated. So I always seemed to switch between 2.5 and 2.66 and one or the other might possibly work or it might not. But than none of them worked, I was doing Die Hard 3 (die with a vengeance) region 1 and was using 2.5 and it failed near the beginning of the rebuild stage (where it usually happens).

So I tried 2.66 and started the whole process over again. But this time I remembered that when I first installed rebuilder a long time ago I used Mpeg2dec3dg.dll and not dgdecode so I switched them since than I've done 3 movies and no problems well I did the Matrix and I got some buffer overflow or something but thats another matter. So whether this means anything I don't or maybe I'm lucking with 2.66 as the flav encoder of the month I don't know, but I'd be glad to help I think rebuilder is a great program, thanks.

[dannyv]

I also get run time error 9 as well as buffer overflow 3's and 4's and always in the rebuild stage and never at the same point in the rebuild process. I don't get these problems when I use cce 2.50se only with 2.67. My tag line has all my machine info. I've gotten this on Star Trek the original series season 2 and on Law and order 2004 season. I have not gotten a successful build yet and went back to 2.50. I am going to fool around with it a little more now that the holidays are over and I have some spare time. Any helpful hints would be welcome.

<<EDIT>> also wanted to mention that I do no pre-processing.

Intresting statement in the above post (I first installed rebuilder a long time ago I used Mpeg2dec3dg.dll ).

I'll try it with mpeg2dec3dg and report back.

[dannyv]

Well I'm at my whits end. I tried it with mpeg2dec3dg and it gave me an error 9 on the last m2v file during the rebuild process just like it does with dgdecode. I tried selecting the file section of the last m2v file to rebuild it as jdobbs suggested in an earler post and when I move the item.ecl file into cce I get a message that it can't read the ecl file. At this point I have ran out of things to try. If anyone can help I would sure appreciate it.

@jdobbs

I'm trying to re-encode the last m2v file.
Can you give me an example of what a single segment item.ecl file should look like maybe I just didn't cut and paste the correct information into it.

Here is the end of the log file

- Rebuilding segment 14 VOBID: 4 CELLID: 3
- Rebuilding segment 15 VOBID: 4 CELLID: 4
- Updating NAVPACKS for VOBID_04
- Rebuilding segment 16 VOBID: 5 CELLID: 1

[dannyv]

Originally posted by jptheripper
the problem seems to be the generation on the single frame cells. Seems as if 2.67 makes a 2.6mb m2v file out of these, and on the rebuild something goes wrong. I am baffled as to how a single frame can generate a file that big regardless of bitrate, i actually think its a problem in cce but unfortunately i have no idea how to explain it.

I just confirmed the same thing the last m2v file is a single fraim and the file is 2.6 megs. This is on law and order special victoms unit 2004. This happens on any disk in the series.

[dannyv]

Originally posted by jdobbs
Ok... Here's what I've found out about the Error 9 as it happens during rebuild. It seems that occasionally something can happen in CCE during the encoding phase that will make one of the output .M2V files be corrupt and incomplete. That fact then, during rebuild, creates either the Error #0004 (Buffer Overrun) or Runtime Error 9 depending upon where it happens.


@jdobbs

Could the error 9's at the end of the rebuild as it starts the navpack be due to the single frame VOBID's as described by jdtheripper in a previous post?

Lets recap this error 9 problem

1. Seems to only happen at the end of the rebuild.
2. Seems to only happen with cce 2.67, cce 2.50 seems to work fine.
3. Seems to happen at a vobid that has a still frame (makes m2v file 2.6 megs) I've proved this on 3 seperate disks from the set.

4. Seems to happen just as it starts the navpack for the still frame.
5. If you play the processed dvd the nav pointers are all screwed up.

Jdobbs when you look into this and if you make any changes to the code. I will be happy to test it just PM me. I have several disks saved to my hard drive that I can test on. As of now I've tested this on 068 - 070 and I get the same results.


Hope my observations help.

[Sir Didymus]

Hi dannyv, :)

1. No point IMHO to test the older decoder release: DGdecode is supported from release 064, and I never heard about anybody reporting problems with it, just some guys making confusion with renaming and other crazy manipulations, trying to support some funny hypotheses that may just lead to troubles on their own...

2. As pointed out by Jdobbs, it seems, [even if I am still curious: maybe I missed something; has it been clearily and explicitely reported ? I mean is it a fact ?], that in some circumstances (what ? when ?) CCE may produce crappy m2v files (truncated ? corrupted ?)...

3. For manually reencoding a specific segment, you just need to use a text editor and extract a segment like this from the rebuilder.ecl file:


[item]
title=V01000000001001
aud_out=0
vaf_file=C:\TEMP\D2VAVS\V01000000001001.vaf
aud_file=C:\TEMP\D2VAVS\V01000000001001.mpa
file_focused=0
packet_size=2048
width=720
height=576
frame_rate_idx=3

...
skip
...

vid_file0=C:\TEMP\D2VAVS\V01000000001001.m2v
vid_file1=C:\TEMP\D2VAVS\V01000000001001.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=8552
vbr_bias=25
vbr_pass=2
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1

[file]
name=C:\TEMP\D2VAVS\V01000000001001.avs
frame_first=0
frame_last=5275
encode_first=0
encode_last=5275


4. You should feed this segment to CCE, through ECLCCE, so manually start ECLCCE, and drag&drop the segment into the CCE window...

Regards,
SD

Edit: forgot to mention... You should paste the segment into the item.ecl, or in a new temp.ecl file, in order to drag&drop this file into the CCE window, started using ECLCCE... :rolleyes: OK. Impossible to provide a more obscure and complicated description of such a simple thing... Hope it is helpful anyway...

[dannyv]

Originally posted by Sir Didymus
Hi dannyv, :)

1. No point IMHO to test the older decoder release: DGdecode is supported from release 064, and I never heard about anybody reporting problems with it, just some guys making confusion with renaming and other crazy manipulations, trying to support some funny hypotheses that may just lead to troubles on their own...



I agree as stated in my previous post that the error 9 I get is produced with eather Mpeg2dec3dg.dll or dgdecode.dll so I have since ruled out the decoder as a problem.


[QUOTE]Originally posted by Sir Didymus
2. As pointed out by Jdobbs, it seems, [even if I am still curious: maybe I missed something; has it been clearily and explicitely reported ? I mean is it a fact ?], that in some circumstances (what ? when ?) CCE may produce crappy m2v files (truncated ? corrupted ?)...



I'm not so sure its corrupt m2v files as it may me segments with still frames. I was able to prove this from 3 seprate disks in this set.


[QUOTE]Originally posted by Sir Didymus
3. For manually reencoding a specific segment, you just need to use a text editor and extract a segment like this from the rebuilder.ecl file:

4. You should feed this segment to CCE, through ECLCCE, so manually start ECLCCE, and drag&drop the segment into the CCE window...



Thank you for the clearification I will try this tonight and report back.

[jdobbs]

The ones I have personally experienced were not single frames. They were standard segments. There was no indication that any error had occurred in the encode -- except the fact that the .M2V file was obviously way too small (I looked at it after the rebuild failure). I just reencoded that segment (using the data from the .ECL file5) and then did a rebuild and everything was ok.

In checking out the error I noticed that the DGDECODE.DLL was not the most current. I have not experienced the error since upgrading it.

[dannyv]

Originally posted by jdobbs
The ones I have personally experienced were not single frames. They were standard segments. There was no indication that any error had occurred in the encode -- except the fact that the .M2V file was obviously way too small (I looked at it after the rebuild failure). I just reencoded that segment (using the data from the .ECL file5) and then did a rebuild and everything was ok.

In checking out the error I noticed that the DGDECODE.DLL was not the most current. I have not experienced the error since upgrading it.

I created an item.ecl and manually re-encoded the m2v file.

CCE indicates its 1 frame with a duration of .01 sec.
The new m2v file created was 2.5 megs which seems large for 1 frame.

the entire segment consist of 1 cell - Rebuilding segment 16 VOBID: 5 CELLID: 1

I did a rebuild after re-encoding the above segment and again at the end of the rebuild at 99.99% when it went to do the navpack for segment 16 it came up with error 9.

Note: Segment 16 is the last segment in the rebuilder.ecl file consisting of 1 cell.

So where do I go from here?

[jptheripper]

exactly the problem i have

encode that one cell with 2.50 instead of 2.67.. it should work

[dannyv]

Originally posted by jptheripper
exactly the problem i have

encode that one cell with 2.50 instead of 2.67.. it should work

Tried 2.50 for that cell but 2.50 complains that the .ecl is not valid for that version. Is there somthing I need to change in the ecl for that cell?

[item]
title=V01001600005001
aud_out=0
vaf_file=E:\LO\4\D2VAVS\V01001600005001.vaf
aud_file=E:\LO\4\D2VAVS\V01001600005001.mpa
file_focused=0
packet_size=2048
width=720
height=480
frame_rate_idx=1
cbr_brate=6000
vbr_brate_avg=393
vbr_brate_min=0
vbr_brate_max=7046
seq_endcode=1
dvd=0
half_width=0
half_height=0
lum_level=0
aspect_ratio=2
gop_m=3
gop_nm=4
gop_hdr=12
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
samples_per_sec=44100
stereo=2
brate_idx=7
crc=1
progressive=0
alternate_scan=1
intra_dc_prec=2
aud_mode=0
tc_ref_frm=0
drop_frame=0
fix_vbv_delay=0
letter_box=0
pulldown_detect=0
offset_line=0
create_new_vaf=1
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
dither=0
dither_max=8
qmat_idx=0
quality_prec=4
timecode=0x0000000
video_type=1
vid_file0=E:\LO\4\D2VAVS\V01001600005001.m2v
vid_file1=E:\LO\4\D2VAVS\V01001600005001.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=7046
vbr_bias=10
vbr_pass=1
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1

[file]
name=E:\LO\4\D2VAVS\V01001600005001.avs
frame_first=0
frame_last=1
encode_first=0
encode_last=1

[Trahald]

i wonder if it could just be ripped in dvddecrypter via ifo-mode demux (split by cell) and dropped in any problem cells with the correct filename. (specifically this single frame stuff that wont have a size impact)

[dannyv]

Originally posted by Trahald
i wonder if it could just be ripped in dvddecrypter via ifo-mode demux (split by cell) and dropped in any problem cells with the correct filename. (specifically this single frame stuff that wont have a size impact)

That's an idea or I can prepare under 2.50 and build the cell info.ecl from that, encode it then try the rebuild again. These could be viable work arounds but it defeats the simplicity of rebuilder if you need all these work arounds. I hope jdobbs can work this problem out.

@djobbs

Note in my previouse post

[file]
name=E:\LO\4\D2VAVS\V01001600005001.avs
frame_first=0
frame_last=1
encode_first=0
encode_last=1


The first and last frames this indicates its a 1 frame file. If played in power dvd it gives and unknown file type error. The previous m2v file plays fine. Could this be some sort of protection?

[Sir Didymus]

Originally posted by dannyv
That's an idea or I can prepare under 2.50 and build the cell info.ecl from that, encode it then try the rebuild again. These could be viable work arounds but it defeats the simplicity of rebuilder if you need all these work arounds.

...

Could this be some sort of protection?

If I understand correctly, suggestion given by Trahal is more intended as a testing option in order to be totally sure the problem is in that specific 1 frame cell. If you extract the m2v from the original VOB file and the title rebuild correctly that would lead to a very bad conclusion (i.e. that in some circumstances also the CBR @ 6000 Kbit/s encoding of still frames is not killing all of the still frame issues...). On the other hand, if you are not able to rebuild the title, even using the original m2v file that indicates the problem is elsewhere...

As an alternative to the suggested way, I sometimes am using VobEdit, --> demux by cell id...

Cheers,
SD

P.S. Don't think it a sort of protection: if the cell is playable on a standalone, it should be possible to decrypt it, to re-encode, and to rebuild...

[dannyv]

Originally posted by Sir Didymus
If I understand correctly, suggestion given by Trahal is more intended as a testing option in order to be totally sure the problem is in that specific 1 frame cell.
As an alternative to the suggested way, I sometimes am using VobEdit, --> demux by cell id...


Ahh now I understand. I'll give it a try this evening and report back. I am not an expert on the inner workings of encoding so if I seem to be missing the point on something, leaving out any vital information or going about troubleshooting incorrectly please let me know. My only goal here is to assist in problem solving to make RB a great program.

[dannyv]

Originally posted by Sir Didymus

As an alternative to the suggested way, I sometimes am using VobEdit, --> demux by cell id...


@Sir Didymus

I took a look at VobEdit and have a few questions.

Please note: I'm at work and don't have access to the actual project that has the problem so I'm trying vobedit on any title I had available just so I can get fimilure with the vobedit program.

I demuxed the last vob in the set by cell id as you instructed above and noticed it saved each cell as a vob file. I played one of the cells in power dvd and noticed it has audio so I guess my question is what do I do with it from here? Do I rename the vob to m2v and drop it in place or do I need to strip the audio out? Sorry if this is an elementry question but I haven't worked with these tools before.

[Sir Didymus]

No, no...

Now you have the cells of the last VOB separated, but they are still muxed...

Please consider the very initial cell you get may be wrongly demuxed,
(since it may be across to a VOB boundary), but you need the last cell
of your VOB, if I understand well, so the method should be safe...

Well at the point you are, just open again the single last cell with VobEdit and this time:

Demux --> Mpeg Stream

You will produce an additional single file with the m2v extension, that should be exactely the one of the cell you want to work with...

Check with some Media Player, to be sure, and rename it to the proper m2v filename before rebuilding...

And keep us informed about the result...

:)

Cheers,
SD

[dannyv]

Originally posted by Sir Didymus
No, no...
Well, just open again the single last cell with VobEdit and this time
Demux --> Mpeg Stream. You will produce a file with the m2v extension...

Check with some Media Player, and rename it properly before rebuilding...

And keep us informed about the result...

:)

Cheers,
SD

Now I understand perfectly. I just tried it on my test file and it worked perfectly. Thank you for clearing that up for me. I will try it on the problem file when I get home and report back.

Just to recap what I'm doing.

1. I demux the last vob in the set via cellid
2. I then demux the problem cell from the above result via mpeg stream to produce the m2v file and play it to make sure its good.
3. rename it to the problem cell name.
4 drop it into the d2vavs directory and try the rebuild again.

[dannyv]

@Sir Didymus

I tried to reply to your PM but your mailbox is full. Just thought I'd let you know.

[dannyv]

I extracted the original source blank cell as outlined previously.
I inserted the original blank cell as V01001600005001.m2v into the d2vavs directory and it completed the build with no problem. Funny thing is the original blank frame is only 5.34kb where the one that RB produced is 2.5mb. How is this possible? And why is this happening.

<<EDIT>>
The m2v file that dvd-rb created which is 2.5 megabytes will not play in powerdvd it gives an error invalid file type which leads me to believe the file is being corrupted in someway during the encode process. I've done 3 disks in the set that all had this same problem with the same 1 frame file. I also reencoded disk 4 which this test was based on 3 seperate times with the same results. I've also manually re-encoded the cell and had the same results.

[Sir Didymus]

2.5 MB :confused:

I wonder how may CCE create such a monster...

It is two order of magnitude bigger than what is reasonable to expect for a single frame CBR encoded @ 6000 Kbit/s...

It's really a bad situation, since a very basic assumption for the proper working of Rebuilder is to thrust in the controlled applications (Avisynth, DGIndex, CCE, ...)...

Maybe something peculiar is present in the configuration of your PC ?
Maybe some seriuos bug is really present in these applications ?

Anyway troubles on the Jdobbs path...

All the best,
SD

[dannyv]

Originally posted by Sir Didymus

Maybe something peculiar is present in the configuration of your PC ?
Maybe some seriuos bug is really present in these applications ?

Anyway troubles on the Jdobbs path...

All the best,
SD

Trouble is not with the PC I was able to produce this on 2 seperate PC's. As we speak I'm backing up star trek original season 3 and star trek voyager season 7. Lets see what happens to those.

[dannyv]

Just did Star trek voyager season 7 and this came out fine. Did star Trek the original series season 3 and the error 9 happened on 3 of the disks I've done so far and all at the end of the rebuild. I will check tonight to see if its the blank cell problem again.

<<Edit>> I just want to add that this also happened on star trek the original series season 2 which I did about 2 weeks ago. It must have somthing to do with the way these disks are mastered. It seems the voyager series processes fine but the original series has problems and they both come from the same studio. Also the law and order svu season 5 series has the same problem. I've done all the law and order series that are availabe with cce 2.50 and they all were fine but this last one with 2.67 has the error 9 problem. I would expect that if I went back and re-did the law and order's that I did with cce 2.50, with 2.67 they would produce the same error but I am not in possession of the originals at this time so I can't test it.

<<EDIT 2>>

I was premature on star trek voyager season 7. It seems disk 7 error 9'ed. Read further down in this thread for my test results.

[jdobbs]

Which set of the STOS are you doing -- the original ones that came out on DVD, or the "Complete Season" discs?

[dannyv]

Originally posted by jdobbs
Which set of the STOS are you doing -- the original ones that came out on DVD, or the "Complete Season" discs?

The complete season sets that just started releasing in 2004, not the original ones released several years ago that were released by volumes.

[dannyv]

The error 9's were caused again by corrupt single frame m2v files. They were 2.5 megs just like the one I found in law and order. This time there were 4 corrupt m2v files. The disk has four episodes and a preview for each episode. The corrupt m2v file was found at the end of each preview. I got tired of doing the rebuild for each failure so I sorted the d2vavi directory by file size and tested all the m2v files I found that were 2.5megs and none would play in powerdvd. I then copied the same blank cell from the original rip to each of the corrupt files. It then rebuilt correctly with no errors.

It seems that the corrupt m2v file is always 2.5megs regardless of the lenth of the single cell whether its a 1 second cell or a .01 second cell.


<<EDIT>>
Checked the second disk in the set and the same 4 m2v files were corrupt. I imagine the rest of the disks in the set will produce the same 4 corrupt files.

<<EDIT 2>>

I just finished star trek voyager season 7 and disks 1 - 6 went fine with no errors.

Disk 7 finished with an error 9

I sorted the d2vavc directory and found 10 2.5meg m2v files. With the exception of 1 file 9 of them were corrupt. I fixed these files in the same manor as above and it did the rebuild with no errors. This disk has 10 special features on it and the corrupt blank cells were placed at the end of the first 9 features.

Note: this was done on a different computer then the star trek original series disks which rule out a problem with the computer or its configuration.

[dannyv]

Finished the rest of the disks and all the disks had the same 4 bad cells with the exception of disk 7 which has the extra features this had 12 bad cells.

@Jdobbs

Whats next as far as you addressing the problem and is there anything I can do to help?

[jdobbs]

What date is on the DGDECODE.DLL file you are using? This sounds familiar...

Also... try playing back the .AVS files with WMP... how do they look?

[wrxblaze]

.........I've done all the law and order series that are availabe with cce 2.50 and they all were fine but this last one with 2.67 has the error 9 problem. I would expect that if I went back and re-did the law and order's that I did with cce 2.50, with 2.67 they would produce the same error but I am not in possession of the originals at this time so I can't test it.

Dannyv which encoder through the 4 bad cells and the 12 bad cells?

[jdobbs]

Hmmm... I typically use v2.50 so maybe that's why I haven't seen these??? I'll start doing more encodes with v2.67 to see what happens.

[dannyv]

Originally posted by jdobbs
What date is on the DGDECODE.DLL file you are using? This sounds familiar...

Also... try playing back the .AVS files with WMP... how do they look?

My dgdecode is dated 06/07/04 its the newest version that I'm aware of. You can see my complete configuration at the bottem of the post.

When playing the AVS through mplayer it plays 10 seconds of blank (black) frames. This is a little weird since the original source cell is only .07 sec.

[dannyv]

Originally posted by wrxblaze
.........I've done all the law and order series that are availabe with cce 2.50 and they all were fine but this last one with 2.67 has the error 9 problem. I would expect that if I went back and re-did the law and order's that I did with cce 2.50, with 2.67 they would produce the same error but I am not in possession of the originals at this time so I can't test it.

Dannyv which encoder through the 4 bad cells and the 12 bad cells?

I did the entire Law and order with 2.67 and all the disks get the error 9 caused by a single cell corrupt m2v file at the end of each disk. I still have one of the disk's I'm saving for testing purposes.

The series that has 4 bad cells is disks 1-6 of star trek the original series year 3 the 7th disk has 12 bad cells.

The series star trek voyager year 7, disks 1-6 finish with no problems but disk 7 has 9 bad cells.

It seems these cells are put at the very end of eather an episode or special feature.

I will be saving one disk from each set for further testing as jdobbs works out the problem.

[dannyv]

Originally posted by jdobbs
Hmmm... I typically use v2.50 so maybe that's why I haven't seen these??? I'll start doing more encodes with v2.67 to see what happens.

CCE 2.50 works fine on these problematic disks. The problem is with 2.67. I only just switched from 2.50 to 2.67 in the last 2 weeks to take advantage of the superior quality of interlace materal that 2.67 gives and this is when the problems started. I have a feeling any episodic interlaced materal will produce this problem. I have not gotten a whole episodic set to work yet.

[Craz]

My experience on this runtime error:

http://forum.doom9.org/showthread.php?s=&threadid=89322

[Rockas]

Correct me if I'm wrong but it seems like this error only happens on NTSC sources?!?!?!

[Craz]

wrong, the DVD that gives me problems is R2 PAL DVD9 ;)

[Craz]

Originally posted by dannyv
CCE 2.50 works fine on these problematic disks. The problem is with 2.67. I only just switched from 2.50 to 2.67 in the last 2 weeks to take advantage of the superior quality of interlace materal that 2.67 gives and this is when the problems started. I have a feeling any episodic interlaced materal will produce this problem. I have not gotten a whole episodic set to work yet.

My problematic DVD is also an Episode DVD, the CCE i'm using is 2.66.

[Methanoid]

and I was using 2.50 with problem before I gave up :D

[dannyv]

Originally posted by Rockas
Correct me if I'm wrong but it seems like this error only happens on NTSC sources?!?!?!

In my case it only happens on eposodic ntsc sources.

[glassvial]

Happening here when trying to open the source, RB v0.75. Episodic, NTSC, R1.

[2nd_Gunman]

I received the dreaded "runtime error 9" during the rebuilding stage of "Equilibrium" using CCE 2.67 and DVD Rebuilder .71.

Rather than use the "Big 3" method as usual I set up Rebuilder to work with Procoder2 and EclPRO v0.25a beta and this encoded "Equilibrium" without incident

[EnDeR_PL]

S.W.A.T R1 PAL

[dannyv]

I haven't tested the last few releases of RB so I desided to test 076 with my 3 usual test titles and I'm still getting the error 9's during rebuild as described in this thread starting from page 6 on.

[2nd_Gunman]

Originally posted by 2nd_Gunman
I received the dreaded "runtime error 9" during the rebuilding stage of "Equilibrium" using CCE 2.67 and DVD Rebuilder .71.

Rather than use the "Big 3" method as usual I set up Rebuilder to work with Procoder2 and EclPRO v0.25a beta and this encoded "Equilibrium" without incident


Same problem and solution executed by me again, this time with "The Motorcycle Diaries".

[wmansir]

I just received a Error 9 at the end of a batch job. Luckily it had completely finished the jobs. The last thing in the status box was:


Done.
Batch Job #1 finished in 00194 minutes.
- HIGH/LOW/AVERAGE Cell Bitrates: 3,717/393/3,366 Kbs

Batch Job #2 finished in 00180 minutes.
- HIGH/LOW/AVERAGE Cell Bitrates: 3,449/393/3,315 Kbs

Batch Job #3 finished in 00201 minutes.
- HIGH/LOW/AVERAGE Cell Bitrates: 3,497/393/3,318 Kbs

Batch Job #4 finished in 00235 minutes.
- HIGH/LOW/AVERAGE Cell Bitrates: 3,559/393/3,343 Kbs



I don't know what it would be doing after that to cause this error, but it's the first error 9 I've seen in a long time. Although I don't use batch processing often.

I just thought of something, could it be because I deleted the source directories of the first couple of batch jobs after they finished, but before the batch process was complete? Also, I was reusing the working directory if that matters.