MTR 6 ANNOUNCEMENTS - READ FIRST!

[geezerbuttz]

The solution is:

Clean the disk.


Note to all , building the structure needs clean , scratch free disks..
If you don't clean them , or if they are damaged , you will get an incomplete structural file.

G

[geezerbuttz]

So This disk is a bit of a issue to map.

Its not that the app fails , its is just it is very 'user centric' and requires a lot of navigation to move around it..
Couple that with 3 languages ... and you can imagine the possible navigation paths we need to chase.

Its the biggest toughest test yet , with 122 individual navigation nodes that need to be sampled , each node carries a max of 12 states at any one time..

So far , its doing a stella job.

647 identified aligned sectors on pass one , pass two is now doing an update to see if we capture anymore before the early exit condition is set.

Remember , as a sate is executed , it is removed from the current nodes state storage. Later , any nodes that navigates to this node , will add a new state ( provided the registers are not already recorded from a previous entry). This way every state is unique.

Seems ok so far..
G

[geezerbuttz]

Ok , another layer of code in...

Let me explain.

While testing , I found another disk that exhibited an internal lockup.
What happened was that the menu was linking to the next PGC , that intern played its cells , and at the end linked back to the same menu..

therefore we got in infinite loop while checking for the next exit.
Fixed by tracking the navigation in the exit phase , recording the cells/vts/domain etc , and exiting when a condition that indicates an internal recursion is met.

A new preference has been added that sets the upper limit ( maximum count ) of repeat loops before it decides to exit.
Defaults to 10.

G

[geezerbuttz]

Another disk , another alteration.

I noticed that the last Bup of the disk was being padded to the load_out.
Not correct,

fixed.

I have now opened the deep storage box of older titles to start going through...
There are a lot , but , its better to test as much as humanly possible , as this app is the backbone to MTR now.

G

[geezerbuttz]

got an older title here that is really putting it through its paces..
Very deep embedded navigation paths..
Curremtly on pass 12 and still finding new data due to register changes finding new menus..

Its doing its job , rather well..
Like a dog with a bone... its will not let go until it finds no more sectors to map...

G

An update on this..
What it is doing is thus..

When it find a new Menu/Node , it runs its navigation paths and at the destination of those paths stores a state in the relative node.

These nodes could be at the start of the disk in an earlier node.
When the app records new sector ( not nodes ) for output , it marks the app as needing a new pass.
This pass then navigates the paths set in the new states added from the last pass.
This of course can cause new navigation paths to be exposed , thus repeating the whole process.

Its rather complex to map every single path that the navigation engine can take.
This of course is compounded by the use of multiple language tracks and angles.

Update 2: that disk took 17 passes to get all the data...
The longest yet , but a success never the less.

[geezerbuttz]

cosmetic update:

I was bothered that i was only indicating the Base number of each Vob , and its menu , video state.
I updated , the code by replacing the domain check , and matching the exact vob name in the structure.
We now have a fully fledged list indicating exactly what VOB the cell belongs to..

Makes it easier to read.

[geezerbuttz]

Well , I just come across a disk that fails if you limit the state count too low.
Its navigation is so convoluted that I had to remove the count limit for it to find all the data.

Even with identifying states that have already been processed , thus avoiding doubles , One node has 196 states and counting.

Im thinking on how to reduce this...

[geezerbuttz]

The only solution is to tighten the node identification by adding cells to the identifier, thus allowing more nodes to be generated , but we should be able to reduce the state count again.

One benefit is that nodes get added to the end of the current list , there for more get processed on the first pass.


Back to the keyboard...

[geezerbuttz]

ok that is confirmed....

It will gather 99.9 ->100% on the first pass alone , with a second pass cleaning up to see if we need any extra passes before exit.

It is faster.

G

[geezerbuttz]

So far So good... now I have to re do all the test disks ...

No short cuts

[geezerbuttz]

Last of the UI cosmetics completed.

The void data + lead tracks were a post process , and not visible for inspection until imported into MTR.
This has been corrected to mimic the look and feel of the V6 layout.

All are visible , and colour tint mapped for ease of visibility.

Tomorrow , I start the Assertion Class to handle errors in processing....

G

[geezerbuttz]

Updated a little in MTR to match the UI look and feel across the two apps.

Updated the node storage to group nodes according to VTS to lessen disk seeking.
Original system placed new Nodes at the end of the node chain. thus many VTS nodes were mixed.

New system groups them together for a tighter operation.

Small changes make a large change in disk seeking..

G

[geezerbuttz]

Spent today cleaning up the code:
Added more checks in button navigation to prevent buttons that jump and link to know where being executed.
Also added check for button that call Exit.

At long last tomorrow I can code the assertion/error handler.

Should have a new video up soon.

[geezerbuttz]

Assertion handler is well under way.

To aid in debugging i used a lot of assertions to break into the code.
I should of designed the method better to begin with.
Each assertion has to be replaced with a callback to the main UI Assertion Panel,
passing its data to it.

We also ned to decide " is this critical?"i.e do we reset the system , post the notice , and holt execution.
There are a few errors that can be easily worked around , and are not true critical errors.

Im well on it , and should , baring nothing happens to me between then and now , get it completed tomorrow!

I will attempt to get a final video up tomorrow of the app in full action..
I think you will appreciate the hard work gone into this.....

i said it once , and I will say it again....
It makes DVDProbe look dumb.

[Footloose]

i said it once , and I will say it again....
It makes DVDProbe look dumb.

How will this handle Lionsgate movies like "Deepwater Horizon"

[geezerbuttz]

it will map it and produce a 1-1 image


can somebody dump me an ISO of that to test?

[geezerbuttz]

That's the last , tomorrow , I start to re run every disk to check for any new breakages...
If it passes , I move to the main feature incorporating..

[geezerbuttz]

right the image I got this morning from L.A passes , there is some internal loop counting going on ( traps) , but it does break out.

For some sanity , I will implement a final check when the scan is complete to check the continuity of the acquired data.

Its just for confidence before saving....

[Footloose]

right the image I got this morning from L.A passes , there is some internal loop counting going on ( traps) , but it does break out.

For some sanity , I will implement a final check when the scan is complete to check the continuity of the acquired data.

Its just for confidence before saving....

After you ran the ISO thru MTR 6 what was the final output in GB?

[geezerbuttz]

Well, that's where it gets a little clouded.
If the ISO is 100% good then the result will be 100% good.
But if the Iso provided has any cells missing due to an incomplete rip in an earlier release , that It will only compound those issues.

So far the result is 100% playable , and I have been able to fully track all program chains with no data missing.

I believe the ISO is good , therefore the data result is 100% good.

Im still doing a lot of analysis of this disk now against the sector probe to check on one iteration that takes time to exit.
Im looking to find a way to exit earlier to decrease the time needed to process.

[geezerbuttz]

ok , so , the app is working as intended.
The disk I just received employs Random register calculations that can change the navigation paths.
To deal with this we intercept the call , and instead of a random number , we provide a sequential number.
If at the end , not all possibilities of MAX_RAND ( the maximum random value originally used in the VM ) have been tested , we restart , and keep going until all have been tested.

when you have 0xFFFF (65535) iterations to pass , you may be waiting a long time while it checks every single navigation possibility.

This is also compounded if more than one instance of a RND operand are used. Each one is independent and handles its own return calculated value......

Do the math folks , and see what I have had to deal with.

I did find however , a limitation in the code , that did not update the random class with the correct keys to guarentee a unique entry... this is fixed.


Its thorough , and it does get them all , and it works to unravel the deepest messes.

[geezerbuttz]

Been a busy day:

While taking my morning exercise , it dawned on me that the random register method of sequentially iterating from 0 to n is flawed and open to exploitation.

So , I spent the day creating an update to the register code that does return random numbers , but keeps a track of them to make sure we do not repeat any.

When all possible iterations have been tried , the code simply starts feeding normal random states to ensure continuation.
At that point all possible values ( paths of navigation too ) have been checked..

I also added preference that allows you to control the maximum RND iteration count, it reduces the operation cost with no visible side effects...

Tomorrow I will update the RandomPGN playback code to do the same....

[geezerbuttz]

DWH breaks the probes domain name creation.

Why?

We grab the name by sector matching from MTRs provided raw output.
The problem here is that the output is reduced and generalised.
This means that the VTS for a particular sector , if that sector is cloned , may not be the actual VTS played, as MTR grabs the first instance when building its table.

This leads to incorrect output names..

Fixing it now...
G

[geezerbuttz]

ok , tats done.
We now calculate the current file name form the domain and file / sector position. No more relying on MTR.

Next is to upgrade the Random PGN playback to behave as the Random Register code:

Should do that today.

G

[geezerbuttz]

So , im now running the pile of nasty ISOs I have.

I encountered one ( Sandition) that was missing a lot of the data.
On testing , the navigation was being performed , but due to a logical check in the code , it was being ignored.

The check was comparing root sectors and vts numbers .. If the root of 2 different entries was the same but the vts was not , we flagged it as illegal.

Nope , cannot do that.

Once removed , it picked up all the sectors.

So , disks with multiple VTS/Titles that lay on the same sector are calculated correctly.
But ( there is always a but )
The UI needs to be updated to reflect these titles/VTS/sectors that are mapped in the same space...

Im on it... Hopefully today I will get that update in place...

G

[geezerbuttz]

ok , that's done.. we now have a complete overview of all titles that map onto multiple VTS.
Gives us a heads up of how to merge the VTS together.

All data is output in the IMF file..

Video this afternoon showing progress.

[LilAbner]

Video this afternoon showing progress.

Will this Video have audio also?

[geezerbuttz]

why you miss my dulcet tones ?

[LilAbner]

why you miss my dulcet tones ?

Much easier to follow when there is audio

[geezerbuttz]

Delay on the video while I code another addition to the probe App.
This one is under the hood.

Disks can check that the current title matches a specific value in a register or a hard coded value.
When we adjust titles these can often be the cause of the failure.

So , for this , Im writing new code that evaluates the VM , check the conditional bit as well , evaluates that if ness, checks if either a title , vtstitle , or PGC are referenced , and if so , write an entry that identifies this VM command , its locations etc , and the value that it expects.

This info will be saved into the IMF file for later use with the future rebuild engine.

More soon!