VobBlanker 2.0.0.2 released

[2COOL]

Well, it is my intention to support "mock strip" in VB, (but not "in place"). I think the best way is to add an option which means to fix the pointers in keep mode.Hmmm...I can accept this proposal. Would we also have a global option in keep mode to mock strip instead of just a single PGC?

[blutach]

You'd need to be able to mock strip the whole titleset not just a PGC - for example, what if a 2nd PGC had reused cells from the first?

Regards

[jsoto]

You'd need to be able to mock strip the whole titleset not just a PGC - for example, what if a 2nd PGC had reused cells from the first?
Regards Not really a problem. There are two different parts in a mock strip:
A) IFO pointers adjustments (VOBU pointers, sectors in ADT tables, etc)
B) VOB internal pointer adjustments (Nav packs)

Part A) is always done by VobBlanker. It always redo from scratch many tables in the IFO (Menus and Titles ADT & ADMAP and TMAPTI)

Part B) is done cell by cell. You could adjust only one cell and do not adjust the other ones (if you think they are correct). Up to now, VB automatically mark the cells to be adjusted if:
- They are the starting or ending ones in a title cut
- They have been stripped. (all the cells in the PGC are marked in this case)

But, I agree that, for practical purposes, it should be very interesting to have a "global option" to fix all the pointers (part B) in the case of KEEPing PGCs/Cells. In this way, the only thing you have to do is:
- Open the DVD with VB.
- Select the output folder
- Be sure the global option is turned on. Be sure the other global options like "Remove PUOPs" are preset with the value you want.
- Hit process. All the DVD will be mock stripped (well, currently, only titles domain).

jsoto

[CoNS]

Well, it is my intention to support "mock strip" in VB, (but not "in place"). I think the best way is to add an option which means to fix the pointers in keep mode.

To support mock strip "in place" (completely different concept to the option "use the input folder") requires a modification in how VB works, so I'm not motivated to do it...But it IS possible to do a VobBlanker mock strip in the input folder, right? Like blutach and jeanl described in this thread (http://forum.doom9.org/showthread.php?p=666223#post666223) (in the later replies). However, it seems like blutach is doing it a little differently than you described:

just process in input folder. Select the VTS to mock strip (click on process for that one - or process all if you like) and then click on Process! No problems. You can actually strip and select all audio and cells, if you like but that takes longer.So it's not necessary to click Strip and keep all the streams? Marking the VTS for "Process" is enough?

What is the difference between a mock strip "in place" and "in the input folder", then? The mock strip in place/in the input folder using IfoEdit (I'm using your instructions here (http://forum.doom9.org/showthread.php?p=559166#post559166)) is really useful for both menus and titles, so it would be very nice to be able to do it in VobBlanker, too, and without the cell command bug in IfoEdit... :)

(just for future reference: jsoto has described the differences between mock strips in IfoEdit and VobBlanker respectively in this thread (http://forum.doom9.org/showthread.php?p=635924#post635924))

[jsoto]

But it IS possible to do a VobBlanker mock strip in the input folder, right?Yes, but it is faster if you use two different physical drives for the input and output files.

So it's not necessary to click Strip and keep all the streams? Marking the VTS for "Process" is enough?No, currently it is needed. Mock strip can be splitted in two parts:
A)IFO pointers adjustments
B)VOB internal pointer adjustments
Part A) is always done by VB (titles and menus), marking the VTS as process (processing titles and menus) is enough.
Part B) is done (currently) only if you mark the PGC as strip, (keeping all the sreams)

What is the difference between a mock strip "in place" and "in the input folder", then?
"in place":
Means to open the VOB, and modify directly in the input file. There is no backup. It is faster, because you only need to read/check/update some values in the nav packs. The rest of the packs are untouched (even more, you do not need to read them). As a drawback, you cannot recover the originals, because they are modified.
Well, actually you need to read all the packs, at least the first bytes, to classify the pack (video, audio,subs, stream number...). This info is needed to update the nav packs.
"in the input folder"
This is related with VB. VB moves the original VOB to a backup folder, so to generate the new file all the packs have to be read and written. At the end of the process you will have two file sets, the originals (in backup folder) and the modified ones.

it would be very nice to be able to do it in VobBlanker, too I'm going to add the feature.

jsoto

[CoNS]

Great, thanks! :) I bet it'll be widely appreciated!

[blutach]

@jsoto - for the final release is it possible to give a good rundown of what each option in the "More Options" screen does?

Many thanks.

Regards

[jsoto]

@jsoto - for the final release is it possible to give a good rundown of what each option in the "More Options" screen does? It is in the updated help file you should have. Is it not enough or not easy to understand? (My english is not too good)

@all,
I've found a major error in subs stripping feature, so I'll need some additional time to fix it before release the SW. So I'm not going to release it yet.

jsoto

[CoNS]

It is in the updated help file you should have. Is it not enough or not easy to understand?Maybe you could extend the explanations in the mouseover toolstips? I have to admit that I'm one of those scoundrels that hardly ever open a help file for an app... :o

[jsoto]

I do not know how to code a multiline tooltip. Currently I'm limited to only one row in a tooltip.

jsoto

[2COOL]

I do not know how to code a multiline tooltip. Currently I'm limited to only one row in a tooltip.I know you are using C++ but it can be done. http://www.codeguru.com/Cpp/controls/listview/tooltiptitletip/article.php/c4161/

Don't ask me about C++ because I'm more of VB6 kinda guy. ;)

[jsoto]

For sure I knew it can be done... but it is not "simple", needs some "investigation". Thanks for the link, it will be useful.

jsoto

[jeanl]

Thanks for the link 2C00L, I've been looking at doing that too. Amazing how M$ makes it hard to do even the most basic things (like change color on a button, or multiline displays)...
Jeanl

[jsoto]

After some investigation, it has been really easy... BTW, I'm using the class CToolTipDialog (author H. Devos), taken from ReJig sources.

To allow multiple line Tooltip
It is enough to add
m_wndToolTip.SetMaxTipWidth(TOOLTIPWIDTH);
before
m_wndToolTip.RelayEvent(&msg);
in
BOOL CToolTipDialog::PreTranslateMessage(MSG *pMsg)

that's all.

BTW, I do not see the 80 char limitation pointed in the article...

jsoto

[blutach]

Thanks jsoto - I did look at the help file, but the options are increasing at a rapid rate and a good explanation in the help file and/or tooltips might come in handy.

Regards

[jsoto]

Hi all,

Here you can find a new beta, including an updated help file and the changelog

http://www.vcdhelp.com/~jsoto/temp/VobBlanker_2010b6_exe.zip

please report back any bug...I'm going to release it in a few days.

jsoto

[CoNS]

Changelog Vers 2.0.1.0 (??-09-2005)
[...]
Added: Option to copy color palette when replacing PGC.
Added: Option to copy Audio/subs tables and status when replacing PGC.
[...] :thanks:

[CirTap]

@jsoto: sorry for not responding any earlier, I was offline.
the resize problem was gone with b5 (which you probably know by now), it's been weired as it really only happened in the main window, not the others as you suspected ...
anyway, thanx for the update!!

Have fun,
CirTap

[Taelon]

@jsoto,

I recently encountered MFC errors that would crash VB when Previewing ILV cells in VobBlanker_2002, also tested with 2003b2 which would also crash. I thought perhaps the fault would be resolved in v201, but checking beta6 and it still will crash eventually. I've tried to document the errors specific to v201.

Testing v201 b6, could not generate MFC error when Previewing a variety of ILV cells after fresh system boot, but at program exit received Application Error popup notice (see below). Restarted VB, Previewed an ILV cell & closed Previewer ok, but the second time Preview button is pressed causes MFC error (see below) doesn't matter if it's the first or second PGC entry (ILV). This behavior is repeatable until the system has been rebooted, it always crashes 2nd time a Preview window is opened for an ILV title.

Event Type: Information
Event Source: Application Popup
Description:
Application popup: VobBlanker.exe - Application Error : The instruction at "0x73dd292e" referenced memory at "0xede07778". The memory could not be "read".

Event Source: Application Error
Description:
Faulting application vobblanker.exe, version 2.0.1.0, faulting module mfc42.dll, version 6.2.4131.0, fault address 0x00001110.I should point out that I've only seen this problem with 1 DVD and when I processed it with v2002 I was still able to blank out the 2nd ILV PGC, and it worked fine. The crash only seems to occur when previewing, often when closing or opening the Preview window.

[r0lZ]

Have you tried to preview the same cells with PgcEdit's preview? PgcEdit uses the same preview library. So, this test could help identify if the problem comes from the preview engine, or from VobBlanker.

[jeanl]

I'm curious about this problem. I have seen 1 other instance where the preview code crashes (but not in vobblanker and not in pgcedit, because of the way these programs use the preview, I wouldn't expect them to crash, and I've never seen them crash - ever ;) ).
jeanl

[Taelon]

rolz,
I just now tried it and PgcEdit didn't crash or show any errors at all. Then tried VB again and eventually got it to crash, restarted it and verified it would crash 2nd time Preview was opened again. Then went back to PgcEdit and couldn't get it to crash no matter how many times I opened and closed the Preview.

The other difference I notice is by watching the Processes in Task Man, PgcEdit opens a seperate PgcEditPreview.exe process when previewing, VB seems to do everything including the preview in One Process.

I'll try to gather a little more info on that and post it soon.

[r0lZ]

The other difference I notice is by watching the Processes in Task Man, PgcEdit opens a seperate PgcEditPreview.exe process when previewing, VB seems to do everything including the preview in One Process.That's right. PgcEdit uses an external executable, called PgcEdit_preview.exe, stored in the 'bin' folder, and written by jeanl. So, PgcEdit should not crash, even if the Preview crashes. So, you should verify the behaviour of the preview window and process, not PgcEdit's main process.

[jsoto]

@Taelon
I've done a quick test with Alien1 and I was not able to crash VB...
Could you explain exacly what do you do in preview window?
Are you seeking with anyone of the scroll bars?
jsoto

[goonix]

@jsoto

If I replace a small cell with a big VOB, I get following log file:

Version 2.0.1.0 beta 6. Starting new process:


=========== STARTING VTS_01 ====================
VTS 01: Opening IFO
VTS 01: Processing VOB (Menus)
--------------MENU VOB PREPARING PHASE-
VTS 01: Cell Based Menu LU 01, PGC 01
Replacing Cell # 1, VID/CID=01/01
--------------MENU VOB WRITING PHASE STARTED-
VTS 01: (CB) Replacing Cell VID/CID: 01/01
WARNING: Number of Cells in replacing VOB higher than one. Continuing with same cell VID/CID
--------------MENU VOB WRITING FINISHED-
VTS 01: Cell data array filled (Menus)
VTS 01: Processing IFO (Menu)
Looping into Menu PGCs and cells
PGCN Pointer: Pointing Prev PGCN to itself in LU 1, PGC 1
Building VTSM_C_ADT table
Filling VTSM_VOBU_ADMAP table
VTS 01: Processing IFO (Ending and writting)
=========== VTS_01 FINISHED =====================

=========== STARTING VIDEO MANAGER ===========
VIDEO_TS: Opening IFO
VIDEO_TS: Processing IFO (Ending and writting)
=========== VIDEO MANAGER FINISHED ===========


Moving Files start
Moving File: VTS_01_0.IFO
Moving File: VTS_01_0.BUP
Moving File: VTS_01_0.VOB
Moving File: VIDEO_TS.IFO
Moving File: VIDEO_TS.BUP

Adjusting sectors
Done OK

PostCommands changed into Precommands in 0 PGCs of a total of 0

Finished. No Errors, 1 WarningsIf I try to open the processed DVD files again, VB crashes with an MFC application error.

If I open the processed files with PgcEdit v 0.6.1beta10, I get following error message:
Fatal error!
PgcEdit is trying to read data after the end of a table.
This means that a Lenght Of Table value is probably wrong.After a mock strip and manual setting of the audio status of the menu (containing the replaced cell) with IfoEdit, I can open the DVD files in PgcEdit and with VB too. Then it works as expected.

Seems there is still a problem with adjusting the tables in this version.
If it can't be fixed, can you add a error message to the log file at least?

goonix

[Taelon]

@rolz,
I didn't notice any problems with the preview in PgcEdit, except the stuttering and pixelization as it jumps between the ILV cells. The only thing I noticed was that other process in TaskMan.

@jsoto,
To recreate the problem in VB201b, after a fresh boot I've had to use the upper scroll bar to seek, and open and close the previewer on several different cells, before it will crash. After it's crashed once, I can make it crash again without using the seek bar, by just opening a cell, playing for a while, closing preview, open another cell. However I think it crashed sooner with VB2002 & 2003, but I can't say for sure.

I've never had any trouble with VB previewing ILV cells before, I even asked blutach about it a couple days ago because I was so surprised that VB crashed, I knew you would be releasing a new version soon, in part because of the MFC problems with window sizing. But when I found the problem still existed in VB201b I figured I should let you know.

Perhaps someone else can verify the problem, the title that is causing the crash is 'In the Bedroom' R1 (http://imdb.com/title/tt0247425).

I don't know if it would help but I have a program called 'process explorer' I've got a snapshot while previewing in VB and also immediately after the crash, it lists all the threads, mutants, keys etc.

[Taelon]

jsoto,

I may have narrowed down the problem a little, I can cause the crash with MFC Error in 7 steps, without ever actually playing the Preview.

1) Start VB, Browse to Input folder, select VIDEO_TS.IFO
a) Click OK on message box "There are at least one ILV Cell"

2) Select the VTS_02_*.VOB Title Set
3) Select PGC 02 Entry
4) Press Prev/Cut (I don't hit any other buttons in the Preview Window)
5) Close Preview window
6) Select PGC 01 Entry
7) Press Prev/Cut

Immediately occurs the * VB MFC Application error *

AppName: vobblanker.exe AppVer: 2.0.1.0 ModName: mfc42.dll
ModVer: 6.2.4131.0 Offset: 000011e6

[jsoto]

@goonix,
Err, you're right, The code to grow the IFO is only included in the titles domain.... I simply forgot to put it also in the menus domain, so, currently, if VTSM_VOBU_ADMAP table has to grow in sectors, unexpected results will happen.
I'll fix it.
@Taelon
Unable to reproduce... please check your PM

jsoto

[jsoto]

New beta:
http://www.vcdhelp.com/~jsoto/temp/VobBlanker_2010b8_exe.zip

Changes from beta6:
- Main window coordinates and size automaticaly saved/loaded (blutach)
- Larger fonts in Log (blutach)
- Bugfix in deleting last cells of last VOBIDs (the procedure was not deleting the last VOB-IDs if all cells were unreferenced).
- Completely new code to recreate the tables VTS_C_ADT VTS_VOBU_ADMAP VTSM_C_ADT VTSM_VOBU_ADMAP . Now the code supports ADT tables growing (in fact, it can currently happen blanking reused cells) and menu tables growing

Please note because I've changed a lot of code (the last point) there is some risk to additional new bugs...

Still unable to reproduce preview crash, even using ILV Cells in the first cell of the PGC, as in Taelon DVD... Do anyone more experience this problem?
BTW, I'm using exactly the same version of MFC42.dll (6.2.4131.0)

jsoto

[jeanl]

For what it is worth (probably not much), a while back I wrote a C++ class that is able to read IFOs, and access various parts in them. The class is able to grow any table.
If anybody is interested in using that class, I'm quite willing to share it. This isn't the right forum for that kind of offer, but several previous posts seem to have been on the subject of growing IFO tables.
As for the preview bug, in my experience, this is the kind of bug that's extremely difficult to reproduce in another machine. But until jsoto (or someone else with debug capabilities) are able to reproduce it, it will be hard to solve.

Jsoto, here's an idea: why don't you send taelon a debug version? He will need debug versions of a number of mfc dlls (but that's not really a problem), but this will enable him to tell you at which line, in which module the preview crashes. This might be a good starting point (in particular, you'll be able to see whether it crashes in your code, or in mine!!! ;) )
jeanl

[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]

@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 shortlyEvent 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.php?t=84097&highlight=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]

I've found something wrong in you IFOs: VTS_C_ADT table shows the same sectors for two different cellsokay, 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]

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]

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...

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.