[Redesign] Offline favorites improvments

[Komodo5197]

Uses an info download of the favorites finampCollection to provide more accurate and up-to-date favorite information when online. Switches favorites provider to use this when appropriate, and re-enables favorite filter on music screen.

Also, adds an option to download info for all playlists, allowing partially downloaded playlists to be shown when offline.

[Chaphasilor]

Thanks for taking the time to add this!
I'll take a look at it today and try to do some testing involving other clients as well to see how it behaves.

Since we now have the ability to cache playlist metadata, I think we could use that (if available) to pre-select the ToggleableListTiles in the playlist actions menu? The metadata should usually be pretty up-to-date, and if someone modified a playlist on another device, sees the old status in Finamp, and then updates the state again, it shouldn't have any effect anyway (since duplicates in playlists are disabled by default, and removing a track "twice" also doesn't hurt).

Also, I noticed your solution for getting a BuildContext within a regular class using the GlobalSnackbar, that's really clever. I assume I could also use this for the queue service and the Android Auto stuff to provide localized strings to the OS itself?

[Chaphasilor]

There is no collection item for the playlist metadata:

[Chaphasilor]

Just tried liking a track in Symfonium and then seeing how Finamp handles it.

If Finamp is in online mode and started (or resumed after more than 4h, I assume), a sync is automatically started and favorites are synced properly.

If Finamp is in offline mode and started, sync is briefly attempted, but then marked as completed. Switching to online mode will not restart a sync in this case. This should probably be changed, either by always syncing when switching from offline to online mode, or "queueing up" the sync after startup so that it is performed when offlinr mode is turned off for the first time after a restart.

Playing a downloaded track in online mode will show the correct favorite status, and that will be mostly preserved when switching to offline mode. The track will be shown as liked, but the favorite-only filter will not find it. Changing to a different track and refreshing the current view will then remove the favorite status again.

Manually triggering a sync will always update the favorite metadata, and will also immediately download the favorites if all favorites are downloaded.

Here are some logs:

(finamp-logs_favorite-sync-issues.txt), I wasn't sure if all of this was contained in the other logs.

finamp-logs_favorite-sync-issues-2.txt

And some screenshots

          

[Komodo5197]

I can add info items to the downloads screen for these two collections, but it'll be a bit weird. The favorites collection will keep getting re-generated to match the setting, even if you delete it. The all playlists collection will always show a zero file size because we only follow require links, so all the info linked images don't count.

Using the offline data to approximate playlist inclusions for the playlist menu is a good idea, I'll try to add it. You should be able to use the same method I used to get a BuildContext elsewhere, although it should probably only be a last resort, and you want to watch out for accidentally using it during early initialization and getting null.

Regarding the behavior in the face of an external like, that all seems like mostly correct behavior. The exception is not queuing a sync when started offline, which I've fixed. Falling back to the offline known status when switching to offline mode is expected, with a slight holdover while favoriteProvider created online still exists. This would behave cleaner if the offline favorites were up-to-date, which the queued sync from offline to online mode should help with.

[Chaphasilor]

No need to show the favorites download collection, that's a toggle in settings. But the playlist stuff should be shown, even if the size is zero. It shouldn't be zero though, since the playlist covers are downloaded/required by it?

I'll be sure to not use a null check when using the global context. I can always fall back to the current solution with untranslated strings, but in most scenarios it should work.

Yeah, I think if a sync is started when leavj ing offline mode, everything should work out just fine.
Maybe invalidating the favorite provider when toggling offline mode (same as we do with the metadata provider) is a good idea though, that way it's more obvious to the user that there is stale data. The favorite status simply disappearing at some seemingly random point could be confusing, same as the favorite filter not showing the track, even if the track is shown as a favorite in the player screen / mini player.

Thanks for the fixes and playlist improvements. Really looking forward to testing that tomorrow!

[Komodo5197]

I managed to get info linked items included in file sizes in a way that hopefully works - tell me if all the sizes seem to be still correct for you. I ended up turning the playlist metadata into a fully separate FinampCollection type because trying to make most of the stuff work on info linked items was getting too messy, so now the only info linked thing is the hidden favorites metadata collection. There is an issue where none of the syncing/deleting/updating file size on change logic works because the item never changes state. This is because the playlists it points to are never considered downloaded, because we do not, in fact, download them. I'm not sure this is fixable, but I've forced it to be marked complete so at least you can see the current file size instead of 'syncing'.

[Chaphasilor]

The new playlist metadata on the playlist actions menu works well, and newly-created playlist (e.g. added by a Jellyfin plugin) still show up with the dashed icon like they should. I debated using the metadata to speed up loading of playlists, but in the case of new, unsynced playlists this would either cause a layout shift or mess up the order of playlists, so I think leaving it like this is best for now.

The queued sync after leaving offline mode also seems to work.

I guess we can get this merged then?

Unrelated, but another thing I noticed:
When library images are cached, a quick sync seems to also sync all nodes for which there are cached images. I guess this is done to detect changed images, and there's no way to sync less nodes?

[Komodo5197]

Yeah, trying to steal downloaded metadata in more ways than this seems messy. I think this should be good to merge.

I believe detecting changed images doesn't actually involve syncing the nodes in this case. They just sync because finampCollections don't have the logic to not add unchanged children to the sync queue like normal collections do with the expectChangesInChildren logic. The nodes still generally skip themselves when processed because unless an image changed they are already images in state complete, they just have to run through the sync queue to do it. It doesn't matter too much, pretty much only albums/playlists have the volume for this optimization to matter.

[Chaphasilor]

That sounds good. If any of the new stuff causes issues, we won't know it before releasing it to users anyway ^^