[FEATURE] - Lidarr - Better documentation

[xstrex]

Is your feature request related to a problem? Please describe.
I don't know if I'd call this a problem, or a personal preference; Since both Lidarr & Beets can create or rename files or directories, where would one set custom paths and/or file names to match an existing standard?

The default is simply $artist/$disc$track - $title which doesn't work for me, or probably most people, because it creates a directory for $artist and includes potentially dozens of tracks titled, eg:01 - foobar.m4a, which basically defeats the purpose of using beets to organize and categorize music.

Describe the solution you'd like
Generally better documentation on what's configured where, and where to change it. Since so many of these options are set via scripts and simple booleans in a config file, like here in extended.conf. Sure you can set configureTrackNamingSettings to true, but what does that actually do? It's not even commented in the conf file.

Describe alternatives you've considered
I spent 9 days re-importing my entire music library with beets to get it back into a standard that I decided on years ago, by manually running for i in {A..Z}*/; do beet import -A --group-albums "$i"; done with a beets config.yaml with paths configured the way I wanted it, and various other options.

Additional context
What do these actually do, and where is it documented?

configureMediaManagement="true"
configureMetadataConsumerSettings="true"
configureMetadataProviderSettings="true"
configureCustomScripts="true"
configureLidarrUiSettings="true"
configureMetadataProfileSettings="true"
configureTrackNamingSettings="true"

[RandomNinjaAtk]

Lidarr manages the files, not beets. Beets is only used to enhance the files metadata via tagging.

So if you want to use beets as it’s designed to manage the files, you should look elsewhere because these scripts and automatons sole purpose are to enhance the arr apps functionality and not replace it.

Edit:
For what the options do you have to look in the script, but generally they auto configure the apps, and each option is a group of settings that get modified by the script in the app. The auto config generally follows best practices with minor tweaks based on my personal preferences and is actually what I use… The wiki is open for edits so anyone can contribute to documentation. For the most part if you enable auto config and don’t adjust anything, you should have a pretty good setup to start with and not require further tweaking.. but everyone has there own ideas on what they like…

[xstrex]

I understand the purpose of your scripts, and appreciate all the work you've put in this. Your coding is also solid, I would have done the same thing.

I'm just trying to get clarification around what you consider 'best practices' and what 'personal preferences' you've made?

If you can provide a list somewhere, I can write some documentation in your wiki.

By comparison I wouldn't install a Linux distro and check a box that says "secure" without knowing what it actually did; would you?

[RandomNinjaAtk]

Mostly follows the trash guides, which the community deems as best practices, for naming conventions and etc. All changes are made via API calls, so it's all things that any user would do via the web interface. The app itself is unmodified and not any different then if you were to not use these scripts...

An easy way to see the difference would be to do a direct comparison... Run 2 instances, one with default and one with the scripts auto-config to see the differences.

The source code for the changes is also available here...