Automatic rescanning

[OxygenCobalt]

Currently, Auxio loads music once and then never responds to updates. This was a technical decision I made really early on and now regret. Currently, the only way to rescan the app is either by force-stopping Auxio or using the "Reload music" option, both of which simply hard-restart the app so that it begins loading music again.

This issue is about replacing that system with a new one that automatically rescans the music library and delivers updates to the app in a graceful way. This is a major technical rework, and so the addition will take some time to get right. This is currently meant to act as an issue to avoid duplicate "Auxio does not show new songs" issues.

This feature is my top priority right now, and is more or less what's holding up all other features. Such a addition probably means a total rework of the playback system [Not a rewrite, those are bad], and so this migration will likely take a long time and render the in-dev builds unusable for some time.

[OxygenCobalt]

After doing some research, this feature is going to be more complicated than I thought it would be. The issue is that there is no broadcast used for detecting if the filesystem has changed. Instead, I have to deliberately attach a ContentObserver that must be kept around in some background service. This is difficult, as background services that aren't related to media have become increasingly restricted in newer versions of Android.

I have a few options for implementing this as a result:

1. Borg the functionality within PlaybackService, as it will always be running in the background. I dislike this, as it ties unrelated code together.
2. Create a separate service that must always run in the foreground (with a notification), kind of like how FairEmail has it's own monitoring service. This is more elegant internally, but is also not battery-efficient and would likely force me to gate it behind a setting.
3. Use WorkManager and have some loading task that starts every hour or so. This is probably the most future-proof method, however it's also the most user-unfriendly one.

I'm gravitating towards 2 honestly, however I may go with 1 if push comes to shove.

[OxygenCobalt]

Another update. I've settled on the second option for automatic rescanning. This is for a few reasons:

1. If I add a slower method of metadata collection (See: manual metadata extraction), then it would be better to put that into a service. That way, android could not shut off the music loading process like it currently could and cause a variety of unpleasant bugs.
2. Judging by the new foreground service monitor in Android 13, adding a persistent notification for automatic rescanning would become a lot less intrusive than it currently is.

It's still going to be gated behind a setting, but I know what I can do now.

[OxygenCobalt]

Another update, there are only two blockers behind this now:

1. The playback state. After a rescan, we would preferably want to re-save the playback state, but assuming that rescanning might be done in the background, there may be no app component that could do the work to re-save the state (except for maybe the music indexer itself). This is somewhat easy to resolve.
2. Harder, I have to handle what occurs when a song is deleted and the playback state ends. This leads to a variety of bugs with the panel UI and I'm not completely sure how to resolve.

Nearly 100 issues and 4 months later, I'm still struggling with this. Shared Mutable State and Concurrency is hard.

[OxygenCobalt]

Issue 2 has been resolved, so now we are rapidly approaching the MVP for this system. True automatic rescanning (i.e Auxio automatically responds to a deleted file) might not come for a bit later, as I want to deliver this first and then clear out a ton of blocked issues.

[OxygenCobalt]

Auxio now rescans music at runtime! It still does not respond to new files, but I want to push that to later (mostly out of laziness).

[OxygenCobalt]

Automatic rescanning has arrived in 2.5.0. It does not work like other apps, as the feature requires a persistent notification to ensure music updates always occur. Because of this, the feature is gated behind a setting called "Automatic reloading", as it does not seem like a good default behavior the way it currently is (and I personally don't care for it).

[satisfiedsingle]

It is just so stupid(IMO) that the refresh option is hidden inside the settings as "refresh music" button whereas the about section is displayed in the "more options" menu.

I respect the dev's wish to not add a refresh toggle which makes no sense to me btw and his reasons seem to be lame. But there is no reason to not add it in the "more options" menu atleast.

I respect what you are doing but please reconsider about hiding the scan option which is essential to the app's functionality.

[OxygenCobalt]

The issue is that "scanning" has two different meanings depending on whether you want to use the cache or not @satisfiedsingle. I'm still trying to figure out how to properly indicate the difference while still making the option more accessible.