PgcEdit 0.6.3.1

[r0lZ]

Hum, I don't understand. I have not changed the way the beckup folder is handled when you burn the DVD. But I'll have a look. Thanks.

[blutach]

@asmori and r0lZ

Notice the extra "_" after VIDEO_TS. This is the problem, yes?

Regards

[r0lZ]

Hum, I haven't noticed the _, and I don't understand why it is there.
But no, that's not the problem.

Explanation: because of the -m syntax problem you (blutach) have experienced, I have modified the command line used to launch MkISOFS to use only one -m argument for all backup folders. So, instead of excluding explicitely each backup folder, I uses wildcards to exclude *backup* and *Backup*. As you can see, I still use two -m arguments to exclude all backup folders under linux and MacOSX (where backup and Backup are different words.) But under Windows, this has the effect that the files are matched twice, and when I rename the backup folders to move them in the VIDEO_TS folder, the first time it works normally, but the second time, the original backup folder is not there any more. Hence the error.

I have now changed the syntax again, to use -m *[Bb]ackup*, which is a sophisticated wildcard syntax not available under Window$ (of course!), but available in Tcl and mkisofs. This has the effect of excluding all backup folders in one argument, so the error is now fixed. Works fine under Linux, too.

BTW, blutach, please report if the first change I've made in the syntax has solved the -m issue. Thanks.

[arsmori]

Originally Posted by blutach

@asmori and r0lZ

Notice the extra "_" after VIDEO_TS. This is the problem, yes?

That was me, needed that for PgcEdit to propose the move so I could get a screenshot of the error .

[r0lZ]

OK! Good to know. Thanks.

[blutach]

I have tested that change and so far so good r0lZ. It is an intermittant one though and hard to nail down. Will report if I experience it again. Thank you for working so hard on what is really just an annoyance.

Regards

[Drinken]

I allways get the mkisofs related error when there's incremental backup folders present, never otherwise. Haven't tested 0.6.2 yet though, but will soon.

Dr.

[blutach]

Drinken - I thought I was the only one and was mad!

Regards

[Drinken]

Blutach you're not alone, but sorry to say I can't tell you that you're not mad. I'm as crazy as they come. Not that it bothers me. :P

Unfortunately I still get the error with 0.6.2.

Log:

Number of VTS: 7
Output file: "D:\Burn\TEST.ISO"
Volume label: "TEST"

mkisofs 2.01.01a03 X (i686-pc-cygwin)
mkisofs: No such file or directory. Invalid node - '-m'.


Error creating ISO:
child process exited abnormally

Test command was:

"C:\Program Files\IMGtools\mkisofs.exe" -dvd-video -print-size -no-pad -V "TEST" -p "PgcEdit" -m "*backup*" -m "*Backup*" -m .DS_Store -m "Copy of *" "C:\Burn\TEST".

When I delete (or move) the incremental backup folder it works right away.

[blutach]

Maybe it has to do with naming of the IB folder? I've has this one for months and it must be the hardest bug to track down in PgcEdit. I pity r0lZ, but in any event, we can burn.

Regards

[r0lZ]

Well, I've tried to fix this nasty bug, bet seems it's a problem in MkISOFS and/or Windoze, not in PgcEdit.
I have added a workaround to this problem in v0.6.2, but there was a bug in the bugfix!
PgcEdit 0.6.3beta1 should work now. Now, when the -m bug happens, you should be prompted to delete the backup files automatically.

In this beta, I have also changed some things in the burn function, including the way a DL DVD-R is handled. The burn GUI has also been modified, and support for the new /CLOSESUCCESS and /WAITFORMEDIA ImgBurn options added.
Could you test this beta? Thanks!
You need ImgBurn 1.1 or the "Close ImgBurn when done" option will not work.

@everybody: Note that only the burn function has been modified. If you don't use it, it is useless to download this beta.

[jinjin_jp]

When use ver.0.6.3beta1,
even if set -R/DL, GUI is same as +R/DL(L0 data capacity is 0(N/A)), and below two lines are not displayed).
But when ver.0.6.2,
if set -R/DL, GUI display "L0 data capacity=2092896" and below two lines.
Sorry if my operation is incorrect.

[r0lZ]

Thanks. I will verify that...

[r0lZ]

OK, was a stupid bug.
It is fixed now.

PgcEdit_winexe_0.6.3beta2.zip

[jinjin_jp]

@r0lZ
Thanks very much. I comfirmed to be fixed.

[arsmori]

r0lZ, donno if this is common, but I had 'Kill PGC Playback' fail for the first time, here's before:

********** pre commands:
[71 00 00 06 00 00 00 00]   1  Set gprm(6) =(mov) 0 
[00 B1 00 01 00 00 00 04]   2  if ( gprm(1) != 0 ) then { Goto line 4 } 
[30 08 00 01 01 C0 00 00]   3  (CallSS) Call the VMGM PGC 1, resume cell 1 
[71 06 00 01 00 00 00 01]   4  Set gprm(1) =(mov) 0 ; LinkPGN Program 1 
********** post commands:
[30 08 00 01 01 C0 00 00]   1  (CallSS) Call the VMGM PGC 1, resume cell 1

...and after:

********** pre commands:
[71 00 00 06 00 00 00 00]   1  Set gprm(6) =(mov) 0 
[00 B1 00 01 00 00 00 04]   2  if ( gprm(1) != 0 ) then { Goto line 4 } 
[30 08 00 01 01 C0 00 00]   3  (CallSS) Call the VMGM PGC 1, resume cell 1 
[71 06 00 01 00 00 00 01]   4  Set gprm(1) =(mov) 0 ; LinkPGN Program 1 
[00 00 00 00 00 00 00 00]   5  NOP 
[30 08 00 01 01 C0 00 00]   6  (CallSS) Call the VMGM PGC 1, resume cell 1 
********** post commands:
[30 08 00 01 01 C0 00 00]   1  (CallSS) Call the VMGM PGC 1, resume cell 1

The kill routine doesn't catch the LinkPGN in pre command 4 for some reason. This is not a menu and there's no BOV or cell command. As a reference: VTST 3, 1 of this release.

[r0lZ]

Thanks for the info.
Normally, Kill PB should catch the LinkCN and LinkPGN commands, but here it's a Set command with an additional Link. It's probably the reason. Will fix it.

[Drinken]

0.6.3beta2 fails to delete the backup folders for me after it prompts.

[r0lZ]

What do you mean by fails? Is it an error message?

[Drinken]

It prompts if I want to delete and continue, continue without deleting or cancel(IIRC). When I click yes it opens the same error log as with the older builds with the -m error. When i go into the source folder to check the backup folders are still present.