Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically download playlist metadata on first launch #905

Merged
merged 9 commits into from
Nov 9, 2024

Conversation

Chaphasilor
Copy link
Collaborator

This enhances the user experience when adding tracks from playlists (as it shows which playlists the track is already part of), enables removing tracks from playlists using the playlist actions menu, and shows partially downloaded playlists in offline mode.

@Chaphasilor
Copy link
Collaborator Author

@Komodo5197 would you mind taking a look? I'll still have to test this out to see if it actually works, but maybe there's something that could be improved with the download code already ^^

@Komodo5197
Copy link

That seems about as I expected. I don't 100% remember how this migration script works when conducting the initial login, so definitely test that. Also, it might make more sense to chain the future so that the playlist download gets added before we start the repair, although this probably doesn't really matter.

@Chaphasilor
Copy link
Collaborator Author

From what I saw there's a hidden setting that is false by default and gets set to true after the migration, so it should be fine.

I thought about that, but wanted to prioritize the migration of existing downloads over the metadata. Is the download system even a proper FIFO queue?
Either way, I haven't decided on the final order yet. Might try out different approaches.

@Chaphasilor
Copy link
Collaborator Author

@Komodo5197 I noticed that in finamp_models.dart the defaultValue for hasCompleteddownloadsServiceMigration is false, but the supplied default in the constructor for FinampSettings is true. Is that on purpose, maybe to only migrate existing installations but not new ones (or something similar)?

- also reworded the download item name for it
@Chaphasilor
Copy link
Collaborator Author

I noticed that my previous approach couldn't work, because the migration is ran right after startup when the downloads service is initialized, but for new installations we don't even have a server address or viewId at that point. So I moved to to a callback in the music screen and added the same kind of one-off conditional logic.

While testing that I also noticed that the download migration currently doesn't work, even on the redesign/beta branch. Steps to reproduce:

  1. Fresh install of stable/main version
  2. Go to a playlist, download it
  3. Go to an album, download it
  4. Upgrade to the beta version
  5. Get multiple errors on launch and rendering errors when going to the downloads tab

Haven't had time to take a closer look yet...

@Komodo5197
Copy link

Yes, the divergence in setting values is to give different values for migrating vs fresh installs. Regarding your code, I'm not sure it actually needs server info? It should be able to just register the download at any point and then the sync should just wait until there's actually server info to use. I don't believe supplying a viewId is necessary for this download. Also, there's another music screen hook for starting the queue restore which is currently in build, it should probably be cleaned up to init or maybe even in main, I think it was where it was just for an error handling context, but GlobalSnackbar fixes that.

The migration not working is concerning. If you've got the logs handy from the failure, I'd love to look at it and see if something stands out, otherwise I'll try to reproduce it myself at some point.

@Chaphasilor
Copy link
Collaborator Author

Sure, logs are here:
finamp-logs-migration-failure.txt
Error seems pretty clear I believe.

Ah, didn't scroll down far enough to see the queue restore stuff :P
I'll try to unify it.
As for the viewId, I was under the impression that was needed to figure out where to store things in the database, but I'll try without it!

@Chaphasilor
Copy link
Collaborator Author

I had to change the type for addDownload(), it required a viewId even though it is optional for resync(). That's why I thought I had to supply it.
I'll still leave the code in the music_screen hook because it is separate from migration (since migration is only run for existing installs upgrading, but not for new installs).
I noticed that after a migration with my changes, not all images are downloaded for offline use. For one playlist where a track within that playlist was downloaded, only blurhashes were shown in offline mode. The metadata size showed a ~2.5 MB. After deleting the playlist metadata and re-downloading it, the size was ~20 MB and all covers were properly downloaded.
Could it be that the migration needs to be finished before adding the new download? I hoped that the migration had priority, but maybe that's not yet the case.

Only somewhat related, but how much effort would it be to include the image sizes in the download item size? Right now playlist metadata shows up as 0 byte, but downloaded almost 190 images in my case. Even though images aren't counted as "real" downloads, I think they should be included in the total size...

@Komodo5197
Copy link

The core migration of metadata nodes blocks the progress of main and will always be complete before your code runs. The only thing you might overlap with is the repair/sync, which is supposedly fine. My first guess would be that you just caught things that were still running which would have been correct eventually. Another possibility is that the early download adding did prevent syncing immediately, but it would have fixed itself on the next sync at reboot. Do you have the logs for this?

Images are counted. I tried with the latest beta release and playlist metadata has a non-zero size?

@Chaphasilor
Copy link
Collaborator Author

It should've been completed. I was doing other things while it compiled and it was probably sitting idle for a few minutes post launch before I checked. Screen was on all the time. The sync seemed complete. I can try to repro later.
Logs should be here: finamp-logs_metadata-no-covers.txt

The metadata being 0 bytes happened for me with this PR and a fresh install. Basically when only the metadata was downloaded, and nothing else.

@Komodo5197
Copy link

You didn't assign a download location when adding the metadata download, so no actual files could be created. This explains both the missing images and the 0 size.

@Chaphasilor
Copy link
Collaborator Author

Oh, so there's no default location? I'll fix that

@Chaphasilor
Copy link
Collaborator Author

Okay, I'm supplying the location now. Testing now.
I also noticed that the defaultDownloadLocation setting isn't set by default. Is there a reason for that? My intuition would be to use the internal storage as the default, especially if the only other default option after migration is "Legacy Internal Storage".

@Komodo5197
Copy link

The default location is a user setting. We want it unset so that you start getting prompts once you add another download option unless you specifically choose otherwise.

@Chaphasilor
Copy link
Collaborator Author

I see. How about a default metadata location that can't be changed and points to internal storage?

@Chaphasilor
Copy link
Collaborator Author

I've now tested this with migrations from the stable version, fresh installs, and upgrades from 0.9.11 (both with and without playlist metadata downloaded before the upgrade). Everything seems to work as expected.
After the initial launch, playlist metadata is automatically downloaded. If it is deleted later on, it says so until manually changed.

Any comments before I merge this?

lib/models/finamp_models.dart Outdated Show resolved Hide resolved
lib/models/finamp_models.dart Outdated Show resolved Hide resolved
lib/screens/music_screen.dart Show resolved Hide resolved

// make sure playlist info is downloaded for users upgrading from older versions and new installations AFTER logging in and selecting their libraries/views
if (!FinampSettingsHelper.finampSettings.hasDownloadedPlaylistInfo) {
// check if metadata already downloaded to avoid possible duplicates

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this status check actually necessary? We shouldn't ever run this block more than once due to the setting, and we shouldn't be able to produce duplicates of this anyway, The existing one should just be updated with the new profile and resynced.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure how duplicated are handled, the check was just in case a user had already manually downloaded the metadata. If it's fine to re-add it, we can get rid of the check :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, everything should operate fine. I don't think it's been possible to re-add something required before, but adding something that already has info uses basically the same update/overwrite path and that happens all the time without issue.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll give it another try without the check tomorrow 👍🏻

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, seems to behave the same!

lib/services/downloads_service.dart Show resolved Hide resolved
lib/screens/music_screen.dart Outdated Show resolved Hide resolved
@Chaphasilor
Copy link
Collaborator Author

Okay, this should be ready then. I'll merge it once the checks pass and if we find any bugs we can fix them later on.

@Chaphasilor Chaphasilor changed the title Automatically add playlist metadata download item during migration Automatically download playlist metadata on first launch Nov 9, 2024
@Chaphasilor Chaphasilor merged commit 672e7ac into redesign Nov 9, 2024
8 checks passed
@Chaphasilor Chaphasilor deleted the auto-download-playlist-metadata branch November 9, 2024 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants