PgcEdit 0.6.3.1

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

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

[CirTap]

Originally Posted by r0lZ

The only way to remove it is to delete or move the backup folders before launching MkISOFS.

that's part of the idea: if users know that on their system, things are fishy, or they tend to add certain folders near the DVD folder PhcEdit has to deal with, lettings them add this stuff to their .BAT template would save you from tweaking your code. It's probably easier to teach non-CLI savvy users what to add to their template, on their (messed up) system, than trying to program A.I. into PgcEdit
Heaven knows what could cause this, maye one of the folders in the path is a Junction point or contains special characters.

[OT] I found Firefox lately to complain about Umlauts in directory/files names when I dbl-click on .html files in Explorer -- drag'n'drop works %-/ probably some stupid extension I installed recently. Thats one of these "suddenly it stops working" bug one can't smash[/OT]

CirTap

[erdoke]

Originally Posted by 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.

As I wrote above, I got the same warnings and backup folder included in the final image file using 0.6.2 and 0.6.3.beta4.
I don't know what can be special about my system. It's an AMD A64 X2 based system with an nF4 board and 2 GB of memory. I have 3 to 5 DVD burners and 4 to 6 HDDs installed and also the maximum number of Daemon Tools virtual drives (that means four). Windows XP SP2 English version.
According to an earlier issue mkisofs related files are located in a simply named directory.

[r0lZ]

OK. I don't think a config must have something special. The -m bug happens never on my PC, but very often on blutach's PC, and apparently you have a similar problem. Who knows why?!

[erdoke]

Well...
I moved location of PgcEdit and its Plugins directory. First I tried with 0.6.1 and it was OK as I expected. Then overwritten with 0.6.3.beta4 and tried again. ISO was created without any warnings and no backup folder inside...
I can blame two things, one of them is possibly the cause of this misery:
1. PgcEdit exe was in a directory with characters other than English.
2. I forgot to move the "Bin" folder.
r0lZ?

[r0lZ]

I doubt the bin folder is related to the problem. Anyway, when you launch PgcEdit, it verifies if the bin folder contains the correct version of the executables, and overwrite them if needed.

Point 1 might be a problem, though the -m bug happens also when all paths are "standard".

Thanks for your help.

[spyhawk]

I ran the mkisofs in CLI with both versions, 2.01 and 2.01.01a03 X, with -m (then -exclude) option, resulting in no backup folders and no errors.

I tried -nobak/-no-bak option for the fun of it, and it spits out the error that erdoke encountered, and it creates the iso successfully with the backup folders included.

With just "PgcEdit_backup" folder:
mkisofs: No such file or directory. Can't stat d:\test/VIDEO_TS/PgcEdi
mkisofs: Can't open device 'd:\test/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 4000
1176 extents written (2 MB)

With just "backup" folder:
mkisofs: No such file or directory. Can't stat d:\test/VIDEO_T
mkisofs: Can't open device 'd:\test/VIDEO_T'
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): 56
Max brk space used 4000
1176 extents written (2 MB)

Not sure what criteria -nobak is looking for. Probably not related to the -m strange behavior in some systems.

[Ja32]

Sorry, that I cut into your discussion.

r0lZ, when you fix some major/minor bugs I have some wish for you.

I dream about some functionality. When I am in Trace mode while Menu navigation, very often I need zero access to edit it. Now I have to break Trace mode and then back to proper line and choose Edit Menu Button mode. It is whatever uncomfortable.

PS. Sorry for my english

[r0lZ]

Well, that's because if you edit something in the current PGC, the trace cannot continue safely. For the same reason, you cannot use the main window when the menu viewer is opened in trace mode. For internal reasons, the cursor (highlighted line) must stay on the "post commands" label.
However, you can break the trace whevever you want, and quit trace mode, then edit the DVD, and go back to trace mode. If the current command has not changed, the trace mode will be restarted where you left it, and you can continue.
I can't do more.

[Ja32]

Originally Posted by r0lZ

Well, that's because if you edit something in the current PGC, the trace cannot continue safely. For the same reason, you cannot use the main window when the menu viewer is opened in trace mode.

I understand this, but why trace willbe continue? Changing to "edit menu" mode can automatically stop any continues of trace.

For internal reasons, the cursor (highlighted line) must stay on the "post commands" label.

It is not possible to move cursor automatically to "post commands"?

However, you can break the trace whevever you want, and quit trace mode, then edit the DVD, and go back to trace mode. If the current command has not changed, the trace mode will be restarted where you left it, and you can continue.

But very often, when I break trace on Menu navigation, it move to "Target button" and have to be very careful to know where was before.

I am aware, that my post can be not understanding, but I am still lern English

[r0lZ]

Originally Posted by Ja32

I understand this, but why trace willbe continue? Changing to "edit menu" mode can automatically stop any continues of trace.

Difficult to do.

It is not possible to move cursor automatically to "post commands"?

Again, difficult. Moving the cursor is not sufficient. I have to restore a lot of internal variables.
Also, I did it this way, because the user can manually select another line, and/or change the GPRM or SPRM values, and continue to trace. This way, it is possible to test the behaviour of a modified command without having to modify the PGC. Though this method is for experienced users, I want to keep it. I use it a lot! Doing what you want requires to verify that nothing has changed, or to automatically quit trace mode whenever a change is made.

But very often, when I break trace on Menu navigation, it move to "Target button" and have to be very careful to know where was before.

You can use the trace menu -> State -> Return to -> Last PGC. You will come back to the beginning of the last visited PGC, where you can modify it, including, if you wish, the menu buttons. Then use again the same menu or be sure to select the "pre commands" label, and you can safely continue the trace. Your menu will be entered again, so the changes you have done will be executed.

I am aware, that my post can be not understanding, but I am still lern English

Don't worry. I understand you very well.