PGCedit: msg -- can't read "::pgcs(0,1,TTN)": no such element in array

[JMThomas]

When I registered, I realized that development seemed to have stopped a couple of years ago. But I'm hoping some forum reader might have an idea about what's happening to me.

The DVD is Indiana Jones and the Last Crusade, processed on a Mac using Ripit and the DVDmedia folder networked over to my PC.

I strongly suspect some "nonstandard" IFOs were distributed as a form of copy discouragement. Opening the VIDEO_TS folder with PGCedit gets several warnings about VOB tables, starting with "VMGM_C_ADT of the VMG has a wrong end byte address! Value in IFO: 55, computed value: 79. Please save the DVD to fix it!".

VTS_02_0 and VTS_04_0 also have more warnings, and some have words about DVDshrink being known to create such errors. BUT this is not what I'm asking about.

After the initial warnings, a TCL (WISH shell) console windows opens displaying this message:

unable to open key: The system cannot find the file specified.
Error sourcing /Tcl/work/PGCEDIT/PgcEdit.tcl: can't read "::pgcs(0,1,TTN)": no such element in array

The status bar still says "Reading VTS 04 IFO".

I'm stuck trying to think what PgcEdit is working on. If I knew, I might find another "copy discouragement" bit of mucking, which might be addressable with IFOedit or VOBedit.

(Of course, if the author is still taking bug reports, perhaps he could see what's going on and add a bit more sanity checking...)

Any idea what else is screwed up on this CD?

Has anyone run PgcEdit against their copy of the "Last Crusade" DVD?

[ggtop]

Hi,

I use PGCEdit on every DVD and also did on "Last Crusade" (a few years ago). I would remember if I had an error...

The message that the addresses don't fit clearly indicate that the disc is defective or the rip was bad.

Do you have the chance to redo the rip using RipIt4Me on a PC?

I did not encounter any special copy protection on that title.

ggtop

[JMThomas]

@ggtop -- Thanks for your memory. "Last Crusade" almost certainly isn't a problem DVD.

:thanks:

Looking at other DVDs processed by RipIt (plus confirmation re the DVD authoring), I now suspect that the source of the inconsistencies is RipIt trying to remove things like warnings.

In one sense, GIGO certainly applies here! Of course, the defects introduced by RipIt apparently don't bother most players -- a compliment to their firmware programmers.

We're now down to the question of how defensive/paranoid PgcEdit wants to be when ask to process garbage. The author has contacted me for the IFOs, and mumbled something about PgcEdit not yet dead. I'll pass them on.

I finally just grabbed the VOBs and re-authored, so I don't need anything further for this DVD.

Thanks!

[r0lZ]

We're now down to the question of how defensive/paranoid PgcEdit wants to be when ask to process garbage.PgcEdit must at least be able to load the DVD. If there is garbage and intentional errors, it's not its job to automatically remove them unless that errors make it impossible to load the DVD. And I think it is better to inform the user of the problems, so he can fix it them he wish.

Unfortunately, it will always be impossible to handle all kind of errors. A severely damaged DVD cannot be read. But it's not the case of your DVD, and the current beta (still to be released) can load it, although there is still a lot of errors to fix manually.

[JMThomas]

I appreciate very much how well PgcEdit navigates the minefields. Fixing well know problems created by other common programs (such as DVDshrink) is an extra added value.

I don't think of PgcEdit as a repair program -- IFOedit and VOBedit can perform that function, after I figure out what needs correcting. I agree that it is impossible to elegantly handle all errors, and loading a severely damaged DVD is never going to be possible.

I do believe that programs should issue meaningful diagnostics when encountering problems. So far, all of the message boxes from PgcEdit have been extra informative and are very much appreciated. Give PgcEdit an A+ for educating users!

Since the PgcEdit message was actually from TCL run-time, I understand that Pgcedit itself isn't speaking, and therefore it isn't giving assistance to figure out how my DVD was screwed up.

---------------

When my IFOs cause PgcEdit to wander off into a program exception, it would be helpful to know what (generally) PgcEdit was trying to do. I just wondered if such information was available.

I was hoping, given the high quality of PgcEdit, that PgcEdit might have been able to get a word in after the run-time (perhaps in a log file?) telling which phase was processing what -- leave bread crumbs for a clue.

The relative value of extended run-time error processing is a judgment call in trade-offs. A programmer can't implement everything or the program would never ship.

I wasn't complaining. I recognize that r0lZ decides where to draw the line on diagnosis and fix-up. I think s/he made great choices for all the very useful features, diagnostics, and fix-ups packed into PgcEdit.

Please accept my comments as appreciation, not criticism.

[r0lZ]

Yes, the standard error messages dialog are Tcl run-time exceptions. Tcl traps some run-time errors, such as use of uninitialised variables, or when a command tries to read data after the end of a table. The message contains a backtrace, useful to debug the program (in case of an error in the code) and to find the cause of the crash (if the error is caused by an intentional or unintentional bad DVD structure). Unfortunately, it is difficult to automatically display the exact cause of the problem, as that would require a program that can analyse the backtrace, and find the bad data that caused the crash.

I have already programmed some simple functions that do that. For example, when PgcEdit tries to read data after the end of a table, that means that a pointer is wrong in the IFO. PgcEdit traps that case often (but not always), as it is often caused by intentional errors in the IFOs, and it's a pity to have to stop loading the DVD. So, instead of simply displaying the error message, it offers to truncate the table, or fill the missing part of the table with null bytes, and then it tries to continue (at your risk!) But that function cannot know exactly from where the error is coming from. It can come from the general function that reads the DVD, from the one that reads a specific IFO, the one that parse a specific table in the IFO, or even from a function that handles certain data from the table. Furthermore, the Tcl trap is independent of any function, and therefore it cannot know the values of the local variables of the function that has crashed. That means, for example, that it is impossible to know what VTS, domain or PGC was parsed when the error was trapped. So, unfortunately, the message can only be extremely vague, and I can't inform the user of the origin of the problem.

When you see a precise error message, such as "The pointer to the end of the VTSI_MAT table of VTS 3 is wrong", that means that a function that verifies the pointer before trying to use it has discovered the error, and that the Tcl trap has not been called. I did my best to intercept as many errors as possible, but as you wrote, it's not always possible.

Currently, there is a log. You can access it by double-clicking the status bar (or use View -> Show log). It is not complete, as I can't log everything, but it can at least show you what VTS or PGC is currently parsed when an error occurs. The log is never automatically saved on disc, but you can save it from the log window.

Thanks for your positive appreciation of my work.
Oh, btw, I'm a "he", not a "she". ;-)