Main Loop Logic Rewrite and QoL Upgrades

[shitwolfymakes]

Is your feature request related to a problem? Please describe.

Currently, the main loop execution path is decided by a matrixed truth table of options that tries to account for each combination of settings before executing a rip. This has gotten to the point where modifying core logic, or even predicting it's behavior, is unacceptably complex. To address this, I will be rewriting the core logic in of ARM, implementing the Stranger Fig Pattern to make it available for release in piecemeal fashion.

Describe the solution you'd like

Currently, the logic doesn't know what type of video disk it's working with when determining the steps to go through. This compounds the multiple layers of checks it needs to make, leading to code that is hard to read, debug, and maintain. This rewrite will break each type out into it's own execution path, while maintaining the minimal amount of code duplication that we've already achieved.

This issue aims to track the pull requests that will cover fixing this problem, of which there should be at least 6:

• 1. Separate RIPMETHOD variables in arm.yaml for DVD, Blu-ray (MLLR-1: Adding placeholder variables #590)
• 2. Migrate DVD ripping to new architecture
• 3. Migrate Blu-ray ripping to new architecture
• 4. Migrate music ripping to new architecture
• 5. Migrate dataripping to new architecture
• 6. Excise deprecated logic and variables

Additionally, this rewrite aims to achieve 2 further goals across each step.

1. Ensure that each job is executed as a thread separate from the UI to prevent hangs on the page
2. Minimize the amount of time the database is being accessed as much as possible

Are you able to help code/implement this feature ?

Yes. I will take full responsibility for the development of this

[github-actions]

If youre having issues, please remember to read the wiki and follow the instructions carefully

[microtechno9000]

@shitwolfymakes what is the plan for the change? i.e. architecturally.
Are you looking at breaking the ripping portion of ARM into various classes, or leaving the current structure with various function calls?

[shitwolfymakes]

That's a great question, and exactly why I settled on the Strangler Fig Pattern.

Basically, with each addition of rewritten functionality, a harness added to the main function will preempt the current logic, redirecting to to newly added functionality.

The high-level architecture will look like this as the rewrite progresses.

CURRENT

main
    Do stuff...
    If/else [dvd, BR, music, data]...
    Do more stuff...

DVD REWRITTEN

main
    Do stuff...
    If/else [new_dvd]
        If/else [dvd, BR, music, data]...
    Do more stuff...

BR REWRITTEN

main
    Do stuff...
    If/else [new_dvd, new_BR]
        If/else [dvd, BR, music, data]...
    Do more stuff...

MUSIC REWRITTEN

main
    Do stuff...
    If/else [new_dvd, new_BR, new_music]
        If/else [dvd, BR, music, data]...
    Do more stuff...

DATA REWRITTEN/COMPLETED

main
    Do stuff...
    If/else [new_dvd, new_BR, new_music, new_data]...
    Do more stuff...

At each stage, rather than replacing the current, highly coupled code, we redirect to the new functionality instead. Once the rewrite is done, we can remove the old system without worry about causing unintended consequences!

[1337-server]

Any update on this ?

[shitwolfymakes]

Gonna get back to work on this once we get mtech's stuff merged