VobBlanker 2.0.0.2 released

[jsoto]

@jeanl,
Thanks for the offer, but seems it is too late for being used in VB..., may be in other proggie.

I've just sent a VB debug version to Taelon.

jsoto

[jeanl]

Originally Posted by jsoto

@jeanl,
Thanks for the offer, but seems it is too late for being used in VB..., may be in other proggie.

I didn't think you'd be interested! I'm sure you have your own version of that!

I've just sent a VB debug version to Taelon.
jsoto

you might have to send him debug versions of a number of mfc dlls (I remember having to do that for blutach...). Unless you compiled the dlls as statically linked (that's the best solution!)
jeanl

[goonix]

First test result of VB 2.0.1.0. beta 8:

Now replacing a blank cell in menu domain with a big VOB is working.
But even if I have checked all boxes under "replacing" in More Settings, the audio status in the destination PGC that contains the replaced cell is'nt correct. (It had no audio before and should have audio now.)
I have to set the audio status of the menu with IfoEdit manually. Then it works.

Are my settings (check all) in VB wrong?

goonix

[Taelon]

@jeanl and all,

jsoto indicated that the VB-debug version did have MFC42 statically linked.

The very first time I ran it, trying to preview the ILV'd VTS, VB crashed with an MFC Error. But I can't find any debug log? Where should I be looking? I've checked the local /Temp directory, the VB-debug directory, root of boot drive, etc.

Where should I be looking?

@jsoto, PM sent

[jsoto]

@goonix,
When replacing cells VB does not modify audio/subs attributes. You have to do it manually.
In your case the PGC is a single-cell, so, if you were in titles domain, you could replace a PGC. Only in this case (replacing PGCs, supported in titles, but not in Menus) VB modifies audio/subs attributes.
BTW, in more options, all the options are related to replacing a PGC, except the first one which is the only one related to replacing cells.
As a last note, you shouldn't check all the options. Last one is not recommended if you are using the option to copying the audio/subs stream control status from the replacing PGC

@all
This is what Taelon reported:

I installed the VB debug version, the very first time I tried to preview the ILV'd VTS, VB crashed with a MFC failure.

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 9/14/2005
Time: 1:49:56 AM
User: N/A
Computer: DB-AK79D
Description:
Faulting application vobblanker.exe, version 2.0.1.0, faulting module vobblanker.exe, version 2.0.1.0, fault address 0x0005d766.

The bad news is I can't seem to find any debug info, anywhere?

Could anyone help about how to get the crashing info?

jsoto

[Taelon]

jsoto, wait a sec. I just restarted VB and got an assertion failure..
blah, blah
Press retry to debug the application...
Pressing retry immediately shows an MFC error, will report back shortly

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 9/14/2005
Time: 2:40:02 AM
User: N/A
Computer: DB-AK79D
Description:
Faulting application vobblanker.exe, version 2.0.1.0, faulting module vobblanker.exe, version 2.0.1.0, fault address 0x00101c17.

Sorry I must be a moron, I can't find anything other than another entry in the Event Viewer.

[Taelon]

Update,

Think I found the debug info in
Drive\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson

I'll sort the old garbage from the VB stuff and Email it to you jsoto.

Edit- This stuff isn't unique to the debug version, I'm seeing info for the other versions as well. However I see in the last entry it pinpoints the Error, so hopefully it will be useful.

[jsoto]

I forgot to mention the two assertion failures when opening the IFO, in dlgfile.cpp
This is not a problem, just press ignore.

jsoto

[jsoto]

I'm wondering if the crash is happening due a bad pointer in the IFO, used to access the VOB when open the preview..

Could you run a mock strip in titles domain in your VTS_02?
http://forum.doom9.org/showthread.ph...ght=mock+strip

jsoto

[Taelon]

jsoto, yes I did ignore that. I believe the -debug worked properly and this info will prove useful.

mail sent

[Taelon]

I tried something similar yesterday (chopped a short piece of VTS_02_1.VOB) created IFO's and mock stripped it, but couldn't recreate the error in VB, so that could very well be the case.

I will try a full mock strip and report back.

[jsoto]

I've found something wrong in you IFOs: VTS_C_ADT table shows the same sectors for two different cells

[000015f8] 	  469. Cell: VOB ID	2	[0002]
[000015fa] 	  469. Cell: Cell ID	1	[01]
[000015fc] 	  469. Cell: Start sect	307339	[0004b08b]
[00001600] 	  469. Cell: End sector	308069	[0004b365]
[00001604] 	  470. Cell: VOB ID	2	[0002]
[00001606] 	  470. Cell: Cell ID	2	[02]
[00001608] 	  470. Cell: Start sect	307339	[0004b08b]
[0000160c] 	  470. Cell: End sector	308069	[0004b365]

jsoto

[Taelon]

Originally Posted by jsoto

I've found something wrong in you IFOs: VTS_C_ADT table shows the same sectors for two different cells

okay, i see it but don't know what that means exactly.

I tried a mock strip but I"m not sure about the results, I can't get the same settings 2COOL has in his guide (if I'm reading it right) anyway I tried to preview it in 201b (not the debug version) and got the same MFC Error as earlier. I also checked the area of the code you just posted, and it looks like it was fixed by the mock strip.

[000015f8] 	  469. Cell: VOB ID	2	[0002]
[000015fa] 	  469. Cell: Cell ID	1	[01]
[000015fc] 	  469. Cell: Start sector	307339	[0004b08b]
[00001600] 	  469. Cell: End sector	307648	[0004b1c0]
[00001604] 	  470. Cell: VOB ID	2	[0002]
[00001606] 	  470. Cell: Cell ID	2	[02]
[00001608] 	  470. Cell: Start sector	307649	[0004b1c1]
[0000160c] 	  470. Cell: End sector	308069	[0004b365]

Edit -Disregard the results after the mock strip, I didn't have the correct settings, gonna bug 2COOL to change the guide in the original post. Will attempt to mock strip it again and post the results later.

[Taelon]

Originally Posted by jsoto

I forgot to mention the two assertion failures when opening the IFO, in dlgfile.cpp
This is not a problem, just press ignore.

Sorry, you were of course correct, I ignored them the first time, but for some reason I thought it was relevant the second time.

I'm wondering if the crash is happening due a bad pointer in the IFO, used to access the VOB when open the preview..

Could you run a mock strip in titles domain in your VTS_02?

Completed the mock strip (correctly this time I hope), and verified the MFC fails when the Preview window is closed. I'm emailing you a log of everything I did; mock strip procedure I used, the exact sequence and button presses that were made in VB, and the new DrWatson .log and .dmp files.

The debug assertion error at the MFC fault was

Program: E:\Program Files\_DVDtools\VobBlanker_debug\VobBlanker.exe
File: dbgheap.c
Line: 1044
Expression: _CrtIsValidHeapPointer(pUserData)

Sorry about the previous confusion on my part, hope this helps

[jeanl]

From my experience (but I'm not an expert) this error indicates a problem when freeing an array, for example because the array was previously freed (probably not the case here) or because the program wrote outside of the array boundaries (that could very well be). The annoying thing is that it does not indicate where exactly this happened.
Jsoto, short of reproducing this problem yourself, the next best thing is to write into a file at various places in your code, to indicate that that part of the code executed OK. This can help you pinpoint where exactly the problem occurs. For example, you can print into a file before and after every call to delete in the code that closes the preview. Don't forget to put a fflush() right after every fwrite() so what you write appears in the file immediately.
I suspect something is happening when you delete an object (the preview? or one of the arrays you've used?).
jeanl

[jsoto]

The main problem is that seems there are at least two different issues:

A) In previous posts, Taelon has reported the crash when trying to open the preview window (just when press preview button). Seems this has been fixed with the mock strip, but I'd like to know why a bad pointer makes VB crash. In any case I'm pretty sure this bug is in my code, because this part (seeking in the VOB) is actually a very dirty code... So I'm not interested to find this bug if a mock strip solves the problem. What I should do is to rewrite this code from scratch...

B) In the last post the crash happens when closing the preview... and seems only tested with the debug version.... Taelon, does it happen in the non-debug compiled one?
If yes, I'll do what jeanl suggest.

Well, other possibility is that the error is only one, when closing the preview, but it (for whichever reason) does not crash the release version, but something is corrupted in the memory, so the proggie crashes when opening the second time the preview...

jsoto

[Taelon]

Originally Posted by jsoto

Taelon, does it happen in the non-debug compiled one?
If yes, I'll do what jeanl suggest.

jsoto,
I tested the mock stripped backup in 2003 and 201b, it doesn't crash with the MFC error when I close the preview window, but it does crash immediately after I press the prev/cut button the second time.

To repeat what I said earlier, I'm not doing any seeking, just prev/cut -> play for 10 to 30 secs., stop, close preview. 2nd time prev/cut is pressed = crash.

[jsoto]

Due the low failure rate and the difficulties to find the bug, I'm going to release VB whithout fixing this bug, but in the future I'll check carefully each ILV material I get...

Originally Posted by Taelon

I didn't remember ever having VB crash on me, and I've done at least 10 ILV titles. But looking thru the event viewer logs there have been a few. Starting from March when I first started backing up DVDs, I have my PgcEdit & VB logs so I can guess which movie I was working on at the time.

This is interesting, I wonder if it's related:

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 6/10/2005
Time: 1:35:36 PM
User: N/A
Computer: DB-AK79D
Description:
Faulting application pgceditpreview.exe, version 1.1.0.0, faulting module pgceditpreview.exe, version 1.1.0.0, fault address 0x000222ee.

Checking the PgcEdit logs that was "Cinema Paradiso"

Here are my first ever VB crashes, both on the same night:

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 8/16/2005
Time: 1:17:36 AM
User: N/A
Computer: DB-AK79D
Description:
Faulting application vobblanker.exe, version 2.0.0.2, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00010f29.

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 8/16/2005
Time: 3:01:07 AM
User: N/A
Computer: DB-AK79D
Description:
Faulting application vobblanker.exe, version 2.0.0.2, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00010f29.

Must have been "American Psycho", I remember that one, I ran it thru VB 5 times that night

No others until this 3 errors with "In the Bedroom" on Sept 8 with v2002, then after I told blutach about it, 2 errors with v2003 on Sept 11.

Then of course tons of them starting on the 12th after I posted in the forums, and started testing.

[manono]

Hi-

I've got a problem to report using the latest version 2.0.1.0.b8. I checked with a friend and he had the same problem. I was doing the usual stuff, blanking some PGCs and replacing 2 of them with my reencodes, muxed with MuxMan. It wrote out the vobs, and near the very end it aborted with a message, "No enough room for IFO growing". The drive had plenty of space (although I don't guess the message had anything to do with the space on the drive). I tried again to a different drive, and same message.

I reverted back to the May 2005 v2.0.0.2 and the blanking/replacing went fine.

[jsoto]

@manono (& blutach)

Err, yes, I've also found the error just yesterday. Now fixed!

I've added a check to avoid to write out of memory space in case of IFOs growing. The maximum available space for IFOs growing is 32K

The check is:
if (New ADT/ADMAP tables space - Previous ADT/ADMAP tables space > 32 K) --> Error. Abort.

And the bug was in the Previous ADT/ADMAP space calculation, which was not evaluated correctly (it always returned 2 K)

Previous versions did not have the check.

jsoto.