PgcEdit 0.6.3.1

[frank]

Ok, thanks :D

[frank]

I have got a new burner LiteOn SHW-16H5S. So I could test DVD-R DL media from Verbatim.

The result:
The size of layer L0 is unchangeable and stays on max. regardless of what LB setting. In this case no LB setting is possible! The laser changes at the end of L0, and proceeds on L1. Then the leadout fills up to the inner radius, the burner has to write fully 8.5 GB.
DVD-R DL is not suitable for DVD-Video! I have spent 4 coasters for this knowledge! :(
Great suites like Nero have the same issue!!
Look at my last posting in the DVD burning section.

So we should disable the DVD-R DL option in PgcEdit and output a warning if you want to use a DVD-R DL (Dual Layer).

[r0lZ]

See my reply here (http://forum.doom9.org/showthread.php?p=744164#post744164).

[r0lZ]

PgcEdit v0.6.2 (December 2, 2005) E. PGC Editor's cells flags: The Access Restricted and the VOBU Still flags are now availables in the Cells Type Flags editor, rather than directly in the cells list. Previously, only the VOBU Still was available. The Type Flags button contains now two values, one for each byte. Also, some of the flags labels have been changed to reflect more closely the official terminology.
E. PGC Editor: Added tooltips on the cell command number fields to display the current cell command. The cell commands numbers higher than the number of cell commands currently defined are now highlighted in pink. Similarily, the Prev/Next/GoUpPGCN link values are highlighted in pink if the target PGC doesn't exist.
E. Enable All Operations now prompts the user if he wants to remove also the Access Restricted flags on the cells of the current PGC, when this flag is set on some cells. Warning: the Access Restricted flag is especially used by the Sony ARccOS protection. In this case, it should not be removed.
E. Changed the listbox/entry default color to use the Windows default. Added Option -> User Interface -> White Listbox Background also under Windows and Mac OSX.
E. Burn DVD: a new selector button has been added to select the DL media type from the main dialog. The Sectors in L0 value in the Burn Setup window is now ignored when burning a DL+R.
E. Since ImgBurn is now stable and doesn't require the layer break sector number in his settings anymore, the dialog asking if the user wants to copy the layer break value in the clipboard has been removed when ImgBurn is used, and when a DL DVD-R is used.
E. Burn DVD: when the log is displayed, the Save button uses now by default the same filename as the ISO, but with a _log.txt extension.
A. A new menu "Options -> Install -> Install a plugin" has been added to help the novice user to install a PgcEdit plugin.
E/F. The standalone version of PgcEdit now uses freeWrap version 6.1. This solves the problem of the mouse double-clicks being passed through the file open/save or folder selection dialogs to the underlying window.
F. The Kill PGC playback function now appends a LinkPGCN command at the end of the pre-commands when the NextPGC link is non-zero and doesn't point to itself. Without this command, the PGC was sometimes played.
F. Fixed the bug in Remove Cells function of the PGC Editor that caused the function to silently fail in some occasions.
F. The Prohibited User Operations window was sometimes pushed below the main window when the Input Value button was used.
F. Import Title Closing Clip crashed if the current PGC was a PGC without a Title number.
F. Fixed a problem on some Windows systems where the web browser executable was wrongly considered as not executable by TCL/TK.
F. Burn DVD: Workaround for a problem with mkisofs on some systems: Mkisofs reports sometimes an "Invalid node - -m" error when the backup folders are not deleted. Now, when this error occur, a dialog pops-up, asking if you want to delete the backups, continue w/o deleting the backups, or cancel.


DVD Shrink plugin v1.3 Added function to clear the Analysis cache of DVDShrink, to force it to recompute the analysis of the already processed DVDs, or to preserve disc space.

[Rippraff]

Thanks a lot Roland! :)
But could you please put a 0.6.2.zip on the versions site? Can't find the shrink plugin, there's still 1.2 listed.

Cu Rippraff

[r0lZ]

Hum, right. Version mismatch!
V1.2 of the DVDShrink plugin is still listed, but 1.3 is in the archive!
I will fix this problem immediately.
Thanks.

[Rippraff]

V1.2 of the DVDShrink plugin is still listed, but 1.3 is in the rachive!
You're right, just found the update and the .tcl has the same timestamp as you said. ;)

Cu Rippraff

[r0lZ]

Anyway, it's fixed now.

[CirTap]

wow, yet another release. xlnt!

some thoughts about versioning: you should consider to bump the version number of PgcEdit, with 0.6.1 already being such a feature rich "update" and its partially revamped interface, it would have been worth receiving a larger incrementent: 0.7.0 :-)
I guess some people thought of 0.6.1 just being a bug-fix release because of the tiny version no. increase -- 0.6.2 could have been 0.7.1 :)
Don't what you think of how "PgcEdit 1.0" is supposed to look like or what (more) features it should provide, but to me, PgcEdit is pretty much a 1.0 <g>

Keep up your great work!

CirTap

[r0lZ]

Yes, I know. The version numbering scheme I use is not very consistant.
I increase the version number only when something very important is added, or when a major part of the program was rewritten.
Since PgcEdit is free, I don't need to wait before adding a new feature. This is why a new release often includes a mix of new features and bug fixes. It's difficult to increase the version number each time.

And, yes, PgcEdit has still a major version number of 0, because, honestly, I think there are still bugs in the code, and things that might not be very well documented, or even still yet not discovered in the DVD standard.
I hope, one day, I will be confident enough to release v1.0! ;)

[jinjin_jp]

Thanks very much for new version release.
Pease upload the file linked from "all versions" click, there is the file of ver.0.6.1.

[r0lZ]

Oh, yes, another problem. I must be very tired!
Will add v0.6.2 in the all versions folder.
Thanks!

[jinjin_jp]

Thanks very much. I prefer the file from all versions folder, because easy to confirm version from the folder name.

[CirTap]

I increase the version number only when something very important is added, or when a major part of the program was rewritten.which was my impression for 0.6.1: lots of things changed (visually) in the GUI and you added quite a few great new features, I think it's not about how much code you added, edited, moved, but how the app shows to the user. Anyway, I woudn't mind to "avoid" a 1.0 just because this is supposed to be "bug free" - I never found any x.0 release that was :-) like the stuff from Redmond ...

Have fun,
CirTap

[r0lZ]

Oh, yes, v1.0 will certainly not be completely bug free. But, IMO, it should be a "stable" and complete version.
Anyway, I've also used the 0.X versioning, because it's the habit in open source programs. Not very important, though.

I hate those nasty very tiny programs doing a very simple task, but with grandiose version numbers such as v3.1 Professional, and sold for $30 or more! If you are curious enough, you discover easily that it's only a matter of writing a couple of lines of code. And often, a program doing exactly the same thing is included in Windows, or at least a freeware, more powerful version, can be found easily.
For example, have you noticed the number of more or less expensive programs to shrink a DVD? IMO, DVDShrink is still the best, and it is free!

[Rippraff]

Will add v0.6.2 in the all versions folder.
Thanks!
As I asked already here. (http://forum.doom9.org/showthread.php?p=745826#post745826) ;)
But never mind I'm also very tired today. :)

Cu Rippraff

[CirTap]

But, IMO, it should be a "stable" and complete version.well, I think it's pretty stable and bugfree; it may have "annoyances" which are (I think) "Tk" related, like the stuff with the File Open dialogs: it did never crash for me, though :-) but I admit, I don't use every single feature of it.
I've also used the 0.X versioning, because it's the habit in open source programshmm, hence I mentioned it. Isn't a "typical" version more of a "major.minor.release[.revision]" schema, with major.minor introducing "features" (only) and the remaining two (or one) just fixes and cleanups?
Anyway, I just thought 0.6.1 "deserved" a higher version number for it's many changes and improvements. It's your baby: you can call it want you want, or course :-)

CirTap

[r0lZ]

it may have "annoyances" which are (I think) "Tk" related, like the stuff with the File Open dialogs
V0.6.2 should have fixed this problem! It was related to something in freeWrap, used to build the standalone executable. V0.6.2 uses freeWrap 6.1, which has not this problem anymore.

[CirTap]

yes, I know, don't panic! :-)
I said "like the stuff...", but that's among the things I don't consider a "bug" (in PgcEdit). I never encountered any of the troubles you "F"ixed in 0.6.2 simply because I had no use (yet) for that feature, and I presume I never double-klicked on a filename either: I usually navigate with the keyboard <g>

[arsmori]

r0lZ - all hail v0.6.2 btw :D - , after I let PgcEdit move the files in preparation for a burn, I now get this error:

http://img170.imageshack.us/img170/7472/01errorrenaming8kv.png (http://imageshack.us)


It's new to v0.6.2 and appear consistent. This error msg is harmless since PgcEdit already moved this dir up, just a lil FYI here ;).

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

@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 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.3beta1.zip) 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 (http://www.videohelp.com/~r0lZ/pgcedit/beta/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 (http://www.amazon.com/gp/product/B0003JAO8Q/).

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

[r0lZ]

Hum, that's really strange.
Could you please keep your backup folders somewhere? I will do a test version, with debugging output. If you can reproduce the problem, I will be interested to read the debug output. Thanks.
I'll PM you when it will be ready.
(If you have already deleted the backups manually, don't worrk. I'll try here also.)

[r0lZ]

Oh, yeah! Stupid bug!

This version (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.3beta4.zip) fixes it.
I have also changed the way the "Cancel" button works. It opens the DVD folder automatically, and abort the burn. So, you should be able to easily delete the backup files manually if you want.

[Drinken]

Works fine now, great work. :thanks:

Dr.

[erdoke]

Usually I burn my images with ImgBurn well after creation, so I use PgcEdit (and mkisofs.exe) just to create the ISO file and don't burn it right away.
From 0.6.2 PgcEdit backup folder is included in the image. No matter if I choose this directory to be placed inside or outside the VIDEO_TS folder. The only difference will be the final place of the backup in the image. Version 0.6.3.beta4 does not resolve this problem.
I have not modified any other settings just replaced PgcEdit.exe (0.6.1 and later 0.6.2) with the fresh one.

Warning of the ISO creation:
mkisofs 2.01x (i686-pc-cygwin)
mkisofs: No such file or directory. Can't stat L:\Working/VIDEO_TS/PgcEdi
mkisofs: Can't open device 'L:\Working/VIDEO_TS/PgcEdi'
mkisofs: Unable to parse DVD-Video structures.
Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 6296 Path table size(bytes): 58 Max brk space used 8000 2208305 extents written (4313 MB)
ISO created, WITH WARNINGS!

Just rolled back to 0.6.1 and it creates ISO files OK.

[blutach]

Looks to be funny truncation of file names and backslash/forwardslash confusion :(

Regards

[r0lZ]

Thanks erdoke.
I have tried again to generate an ISO of a DVD with a lot of backup folders, with 0.6.3 beta4, without problem.
Seems it's another MkISOFS problem, similar to the "-m" bug. The strange thing is that this kind of problem happens only from time to time, and only on some systems.

Erdoke, could you try to create the ISO with 0.6.3 beta4 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.3beta4.zip)? I have worked again on the burn function in this beta, and changed a bit the command line issued to MkISOFS. Maybe it's sufficient to fix your problem? Also, be sure to use the latest MkISOFS v2.01.01a03 X (available with the ImgTool Classic current package.)

If it doesn'work, maybe I have to automatically delete the backups, or at least move them in a temp folder on the same disc during the ISO creation. This method should solve those issues, but it's not easy to do on Linux/MaxOSX platforms, where a "normal" user has not the rights to write anywhere.
What do you think?

About the strange filenames:
MkISOFS is a Linux program, compiled for windows, but it uses Linux routines in cygwin1.dll. Internally, the path separator character can be either a / or a \, so it doesn't matter. The truncated filename is strange, and might be the cause of the problem. Anyway, it cannot be truncated when it is passed by PgcEdit to MkISOFS via the command line, because PgcEdit passes only wildcards arguments ("*[Bb]ackup*"). So, it's probably a bug in MkISOFS. Might be fixed in the latest version, though.

[Carpo]

i have used 0.6.3 beta4 to make about 10 + isos and they have all turned out fine - no backup folder in any of them or any truncation (xp sp2)

[r0lZ]

Thanks for the feedback, Carpo. But as I said, the problem is intermittent, and present only on some systems. I need to know if the new beta fixes it on erdoke system.

[CirTap]

Hi,

@r0lZ, just a thought or two: woudn't it make sense to put the MKISOFS command line into PgcEdit's config file ("burn.cfg" for that matter), using %placeholders% for the sources and paths PgcEdit knows about and handles, e.g. the same patterns you use for Tools could be valid for the commandline.
That would possibly save you to compile a new release only to solve command line issues with external applications.

Maybe it could help if the "MakeISO.bat" (on Win) is editable and treated as a template with the aformentioned %foobar% variables inside, this way everyone could add/patch this batch file to their needs; PgcEdit then loads this "batch template" (or shell script(?) on Linux), replaces the variables, and proceeds as usual, running a copy of the batch file from the temp folder.

CirTap

[r0lZ]

Well, it's possible, but I don't think it will help to solve the bugs. I have tried several syntaxes w/o success, and my conclusion is that there is something wrong with the -m argument of MkISOFS. The only way to remove it is to delete or move the backup folders before launching MkISOFS. Otherwise, you need it to exclude the backup from the compilation, and if the user removes it, the backup will be burned as well. If is is in VIDEO_TS, a coaster will be produced.