MTR 6 ANNOUNCEMENTS - READ FIRST!

[LilAbner]

MTR 6.

[Edited by GB]

I need your help. Developing this app has been a life long pleasure for me..
15 years of grey hair and torture , and never much in return.

Now , I want to finish this app , and I need your support to do so.
It will take approx 6 months of hard going to design , code , and debug the next phase of this.
It is a massive change that I have devised.

It has become clear , from last year that asking for help , as I did regarding buying a new MABAir is a waste of time.
It is always the same names that step up to help.

Sad but true , in 11 month I did not raise 50% of the final cost , so I have had to delve into my savings for this.
Thats Is my cost , I could of walked away , I don't need anybody telling me this.

If I had walked away , you would not have a ARM version of the app. Not to mention the abuse in e-mail I would receive ( as I do frequently ) from people who think a few dollars binds you to them for life.

So...
What I propose is something similar to the patron system. Im looking for some patrons , to spend a few dollars each month to assist keeping the lights on , food on the table while I work on this.

Im not asking for thousands , just a little consistent help.
I intent to start In January , so there is no rush..
Who will step forward. Think about it.

G

[geezerbuttz]

So , after asking for support. only a few people assisted in single payments , not in a steady flow of support.

Due to this , and because of another issue, 6 development has been suspended.
Of course , with the world in a rather precarious state currently and the cost of living through the roof , this is understandable.

The other issue as mentioned is Apples continued certificate invalidation on the CSSLibrary , requiring constant rebuilds and resigning.

The solution , is to update the current 5409 build to 5410 , and port the CSS lib internal. Hopefully this will stop the need to constantly update the library.

This will be undertaken from this date with a release on completion.

Once this is done , and some more funding is acquired , the development of 6 will continue.

Thanks all.

[geezerbuttz]

Update 1: CSS library has been rolled into the core MTR Lib.

A little difficult as it needed to be re written and I was hell bent to duplicate the existing call names , thus avoid having to update all calls inside the main app.

Job done , testing now...

RIP CSSLIbrary.

[geezerbuttz]

Update: cleaned all stray code into compact singleton.
Updated the License database to now be in the app preferences ( encrypted of course )
Side effect you will need to enter your details again.
(I may add an import button to read and import the old style format, it will delete it once completed.)

The UI will be updated to a table view for a more easier reading experience.

[geezerbuttz]

Untitled.jpg

Update:
License DataBase has be updated fully.
As stated all license payment informations is encrypted into the App preferences.
It is formatted ready for all future license requests:
An option exists for a one-shot import of the older legacy format if found.This format is removed on successful importation.
Its a table view with editable currency selection so the currency type can be set.
Table is draggable to reorder the contents to place the contents in yearly chronological order
( i may automate this tomorrow , to keep the list in order as added)

I strongly suggest everybody uses this to maintain their payments for future license requests. For the sake of five minutes of typing , you can save hours of frustration looking up older payment information.

More to follow.

[geezerbuttz]

Update 2:
I may alter this tomorrow to use the table views to set the date and the currency directly in each view, thus removing the external controls:

You simply add and entry , and fill it in as required.
DataBase is updated when the window is closed.

[geezerbuttz]

Screenshot 2022-07-15 at 19.20.32.png

So that's complete.
All of yesterday was removed for a more logical easier layout.

Add your entry , fill it in.
Data is updated when you close the Payment Database window.

Database is ordered bottom to top on reloading ( date order ) or can be forced by 'right clicking' in the table view.
The Database window must be the active window for this to work.

Importation of old database works with two exceptions . If the date format you provided in the data base cannot be understood by the DateFormatter , then the date is assumed to be the current date. You will have to manually correct that before you dismiss the payment window, Also currency type will have to be manually set.

As before this information is automatically written out when a new license is requested , so , once again , I strongly suggest you use this function to your advantage.

More sooooon.

[geezerbuttz]

Screenshot 2022-07-16 at 13.46.54.png

So , I spoke to soon did I not:

It did not seem to gel correctly with me so I made the final changes.
Move all button functionality to a contextual menu.

Added manual save routine , keeping the automatic one on window close.
Added a 5.0 seconds timer delay after the date is changed , to atomically update the table in order of date.
The 5.0 second delay is effective from when you stop editing the date. If it takes you longer than 5.0 seconds to change a single digit , the panel 'will' update itself... so chop chop etc....

To delete an entry , just hover over the entry in the table , right click chose 'delete entry'.

The screen shot shows the legacy format entry in the Menu. This will vanish if the format is not found or after a successful
importation.

Update:1 Slight addition. had to make sure that the DatePicker window looses it focus state and closes before the update of the views occurs to prevent UI nastiness.

[geezerbuttz]

Hi.
Very busy last few days....
Decided to embark on making the app more modular , thus so far all read/write/decrypt routines now reside in their own framework.

The framework will expand slowly as I move all the common routines into it. Most Utilities , frame source calculations etc are prime candidates to move out of the app.

Verified the framework , and it decrypts nicely.
All demo and Release build info is movable , and built accordingly at compile time.

The hardest job is deciding what is truly global to the app....

More soon.
I am seriously toying with the Idea to move the disc arbitration code into the framework ,as we can register for events on the framework properties.. need a lot of thought , and a possible rewrite,,, after all that code is based on code from 8 years ago+

[geezerbuttz]

So , Utilities framework completed.
DisplayPanels Framework completed.
UserNotifications framework completed

Still a few more I want to do , then I will move them into the app , and gut older code.
Still on the fence for the DiskArbitration code , as it is bound to an external ArrayController , and that will not be easy if its moved into a framework.

On a lighter side , i improved the file scanning code not to keep trying to read files that are not there , thus speeding up the initial read...

More soon.....

[geezerbuttz]

Moved the DisplayPanels , and UserNotification Frameworks into the app , gut the older code.
All working.

Im going to start to update the downloader code , and move it into a framework, removing custom notifications ( the last of them ) in favour of the using the notification framework now in place .

( you can easily link a framework to another framework , might as well use the new code ..)
I was thinking to move the controller ( view ) to a framework , but that makes no sense,

It should really be utilities , and frequently used code....
It makes the app much more manageable....

[geezerbuttz]

Anybody think A more accessible thread for this build information would be better?

[TheSystemHasFailed]

Anybody think A more accessible thread for this build information would be better?

I think this is fine GB.. it's a steady stream of information.

Unfortunately I was behind in catching up and did not realize you were going to pause work on MTR6. Perhaps a renewed effort to get the word out about this tool on various social media might help? Via blogs/reviews etc. Just 'spitballing' to see what might work...

I'm a bit short of funds until October but if I can help cover certificate signing fees or whatever else I'll be happen to help.

[geezerbuttz]

So here we are , running on fumes , but struggling along.

6 more frameworks created centralising more code.
A lot of code redundancy removal is going on.

I figure to get this all done on the older code base before building ontop, reduce the risk of older bugs.

libMTR has been retired completely , all older CSS decryption code has been replaced , all cssCode is now internal.
No more libDVDCss required.

Bug fixed ISO code to stop VOIDPACKS from getting into a cyclic loop...

A lot more to do , more code that can be moved into a framework...

More info soon.

[geezerbuttz]

Enough framework code for a while.
Proceeding on the UI integration.
Big job moving over from the old diskStorage class to the new one. It will be done bit by bit.
New UI Window (DiscExtraction - replacing MultiRip) is under way , all mounted volumes are already showing in the table view , with all information visible to make choices.

DiscArbitration code is being updated to support the new UI. Have to make careful choices here how to proceed so not as to break the older code.

New UI, first release will only have ISO as its primary engine. Older UI will be kept keeping RnR for now as a legacy extraction engine.This will be removed once I get the framework in place for RnR's replacement.

New UI Volume Selection will have No buttons , it will all be done with contextual menus to reduce UI clutter when you you have minimal space.
beginning to look like an app again.......

More soon , with maybe a few more screen caps.
G

[geezerbuttz]

Another stage further.
BUT!!!! I have come to a place where I have to make a choice about the current design.
The DiskVolume controller is shared between both extraction core ( main and title ) . I am thinking of spinning of the volume menu into its own window , thus using one controller for the mounting / ejecting and loading into various modes...

This is something I would like some thoughts on. Please send private message with ideas as this thread is locked.
G

[geezerbuttz]

Right , no comments so I continued.
I span off the volume control to its own primary window.
That is the new face of MTR. a single small window that you can Access all extraction methods on per volume selection.
Right click for all contextual operations.

If the extraction view is not opened , it will open it prior to population of chosen disk.

Currently , I have nearly completed the MainFeature addition to this new UI.
a few small hard to pin down bugs there , but its coming on.

I located a bug in DiskArbitration that fails to read disks that are on the system but not mounted.. This will be corrected ( easy fix ).

Regarding the ejection of disks from the app. You cannot eject a disk now that has a extraction process created . You must first remove the process from the extraction engine ( all done from master volume window) you may then eject the disk.
Of course if you simply don't care you can eject from the system , but MTR is no longer designed to work that way.

Why? to make sure you do not interrupt an extraction while in process , thus ruining the extraction.

You can not rescan , remove or eject any volume that has an active extraction running.

More soon.

[geezerbuttz]

Hi , update at the end of a busy day.
In the past MTR only presented one volume at a time to load via its PopupButton.
Now you have access to the complete list of volumes , with nothing to stop you selecting them all.
This lead to an issue of thread safety and a rather large crash. This could be fixed easily by forcing the loading routines to run on the main thread ,syncronously.

Of course that means you can only load one volume at a time , and have to wait for the process to complete... not good enough really.
The main issue is in the older C code i wrote years ago , it needs to be updated to be thread safe,
Im on it , it will take a few days to get back to this point , but it will be worth it...no more beach ball while a disk loads etc...

Sleep time now though.
More soon.

[geezerbuttz]

spent the last 2 days hunting don a memory error.
Done:

Added a few more level of functionality to the volume controller in regards to extractor integration.
Added a 'window shade' option in prefs, this allows you to automatically close the extractor window when all volumes are removed from it.

Completed ( well 98% - still have to implement in older code ) the new thread safe IFo loading routines... Still room for improvement ,but that will be implemented when the code is in place....

Any mods listening? I locked myself out from the FTP site... somebody mail me ( privately please , ) the login details for me..
Thanks.

[geezerbuttz]

5 days to find an error is terrible. Async loading kept crashing.
For the life of me I could not find out why , I traced it down to the BUP IFO validation routine , but that made zero sense..
Not until I looked at the table content closely to see that the BUPS were all missing.....

Fixed the loader , and voila asynchronous loading of Images and disks.... ( loading all together at the same time )

Lot of bug testing to do , as it needs to be robust.
But from Wednesday , I am away for a short break.

Taking laptop with me lol.

[geezerbuttz]

Back home , already on the ball.
Big job now , MTR was always using manual memory control , and Im going to port it over to ARC.
A lot of changes have to be implemented to do this , but it will ease coding in the future.. I may be quiet for a few days.
G

[geezerbuttz]

Well this is fun.
The Convertor tries to convert all classes in one go , leading to a slew of fixes. S0..

Im marking the classes one by one for ARC and making the nessessary changes , then Im updating to objC 2.0.
Im noting an improvement in UI speed already...

Its slow tough going , but I have ( almost ) completed all the code that the batch extractor uses...
This will take longer than I thought....

Well , it will not do itself , so I must get on..
G

[geezerbuttz]

found an error in the Quantizer , needs to be fixed , so , ARC conversions stops until that is fixed.

[geezerbuttz]

ok , a short day away , took lap top , found error.
Not Quantizer ( thank god ) but a bug that sometimes writes a non standard IFO!

I coded a complete Ifo read / write that is only partially used ( read only currently ) , so I will now move over to the new code , to generate the ifo, and write it.

Should be relatively easy .
Then back on to modernisation.
G

[geezerbuttz]

Busy , Busy , Busy...
Masses of new code in the new ifo reader/ writer.
Extended complete functionality to rebuild existing sets ( may implement this as a utility within the app )
Moved into the Main feature for DVD rebuilding , saves them nicely , far more efficient.

A couple of memory related bugs cropped up , seem to have squashed them , its just a case to make sure any structs are now allocated , rather that used raw, esp in a threaded environment. ( lots of older code that was not designed for this that needs to be checked and updated )

Lots of testing tomorrow on this new code...

going to move the Post process button into the Main feature contextual menu , removing it from the Menu bar...
There will be no more extraction entries in the Menu after this.

Hopefully soon I can start to design the ISO code , and the new main controller , and gut the older ( read ancient ) stuff out.

Proceeding slowly on the ARC conversion , and the manual update to model code design.

So much work.

[geezerbuttz]

There you go all fun: all is good in IFO land now.
Been working on the Quantizer , works better now , total clean up , but no ARC for this as it slows it down due to the complex memory handling.


Quant has a new feature that tunes the quant value as you requantt to squeeze every last drop of byte space we can...

A few more updates on it in the morn and we move on.... I intent to serialise the packet writing on the Quant write, move it to a Queue so we can get on with extracting without waiting for the write to complete.

Stay tuned....

[geezerbuttz]

still in the Quant , decided to centralise it and get it ready for full disk post processing..
Centralised the rebuild structures .
Removed , and optimised the thread locking to reduce overhead on data transfer between the extraction engine and the quantise.. stops memory bloat.

Just about to improve the memory allocations , more rugged..

Last to do in Quant is the output queue , still not done yet.

Quite slow due to all the testing to make sure the output is still good....

HeyHo!

[geezerbuttz]

so , we finally made it into the new DiskExtractor controller.
Designed the UI , will make sure cosmetic changes along the way no doubt , but the UI basic design is well under way.

Roughed out a basic controller to test UI...

In the new controller I plan to have a functionality similar to Batch Extractor. You will be able to add the same disk multiple times , if desired , allowing you to queue multiple extractions of the same disk , with modified extractor or settings , as desired.

I am not sure how useful that will be , but it will bring this side unto the same capability as Batch rip.

I am soooo looking forward to ripping out all the old 'views in cells' code that i had to write to support the layout of version 5.0...

Cleaning out all the old junk is going to be a huge task at the end... but its needs doing.

One last thing , I have made the extractor view windows exactly the same size to try to maintain some conformity with the app.
I hope to have a few screen shot to post over the next few days , its late now , and I need to sleep.

[geezerbuttz]

ok , update time again.

The Iso extractor has to be rewritten from the ground up, there is just to much kludge in there.
Not a bad thing , as I can move over to the new DiscObject framework we now get from DiskArbitartion.
It encapsulates the whole disk info in one easy object.

This rewrite will give me the chance to incorporate the ISO packer routine as a post process.
This will split , encrypt , and pack the extracted ISO for transportation.
Passwords will be set in preferences , so everybody who uses it will need to communicate that password , but with different P/W per user , the packages will be far more secure.

So , Im on it , but its a lot to unpick and rewrite..

Stay tuned folks.... Its starting to come back together like never before...

[geezerbuttz]

Hey ! we are getting the Iso data to the interface... super clean code!
Will attempt to optimise it more though.....
Found a strange issue though , and I guess its down to ARC.

When malling a chunk of memory , if the chunk is not cleared and 'initialised to zero' the compiler throws a serious fit.
I have been moving over to calloc , it takes a little longer but it zeros out the block , and keeps the compiler happy.

who knew....