With any "breaking" changes or fixes to the code, there's bound to be some existing data that doesn't comply to those changes. For example, we previously changed how we create albums in order to fix album "fracturization" — we now use albumArtist instead of the artist value. The problem is that, any existing "fracturization" will remain unless the user basically clear the app storage & re-index everything.
This PR aims to fix this by adding some code to fix any "broken" data to comply with the new changes (ie: fix any pre-existing albums with "fracturization").
How
Currently, we have 2 "breaking" changes/fixes to: image saving & album "fracturization".
With image saving, we technically don't need to have code to fix this as if we encountered an error when trying to save an image from an invalid base64 string, we would throw an error, and not update the fetchedArt boolean on the Track entry. So technically on app load, we'll always try to save this image, and fail every time.
One important note with the code to fix album "fracturization", we try to optimize things and only try to fix the cases where there's duplicate album names. So if have a single album with the wrong artist (ie: uses artist instead of albumArtist), we won't fix it.
In other words, we fix any existing album "fracturization" that are visible.
This is probably the best compromise, compared to going through each album and checking to see if its albumArtist is different to its artist value.
The code to fix image saving is pretty simple; we needed to set all the fetchedArt boolean values on the Track entry to false. In addition, we needed to adjust some code in saveArtwork() to skip attempting to save artwork for tracks with artwork populated, but fetchedArt = false.
Some other changes:
We've updated the loading screen to note that we may be on the screen if the app is fixing the data.
We updated getAlbumKey() to run encodeURIComponent on the album & albumArtist values for better reliability.
Test Plan
We'll install a dev version of v1.0.0-rc.9 to mimic the behavior when we eventually release v1.0.0-rc.10. We'll use the same 3 tracks used in #32 which were 3 tracks by different artists that belong in the same album. With v1.0.0-rc.9, we'll get 3 separate album entries.
When we open up the app when running the code in this PR, we should now see a new album entry containing all 3 of those tracks (and the different albums generated by those 3 tracks prior to be gone).
Checklist
[ ] Documentation is up to date to reflect these changes (ie: CHANGELOG.md & README.md).
[ ] Add new dependencies into THIRD_PARTY.md.
[x] This diff will work correctly for pnpm android:prod.
Why
With any "breaking" changes or fixes to the code, there's bound to be some existing data that doesn't comply to those changes. For example, we previously changed how we create albums in order to fix album "fracturization" — we now use
albumArtistinstead of theartistvalue. The problem is that, any existing "fracturization" will remain unless the user basically clear the app storage & re-index everything.This PR aims to fix this by adding some code to fix any "broken" data to comply with the new changes (ie: fix any pre-existing albums with "fracturization").
How
Currently, we have 2 "breaking" changes/fixes to: image saving & album "fracturization".
fetchedArtboolean on theTrackentry. So technically on app load, we'll always try to save this image, and fail every time.artistinstead ofalbumArtist), we won't fix it.albumArtistis different to itsartistvalue.The code to fix image saving is pretty simple; we needed to set all the
fetchedArtboolean values on theTrackentry tofalse. In addition, we needed to adjust some code insaveArtwork()to skip attempting to save artwork for tracks withartworkpopulated, butfetchedArt = false.Some other changes:
getAlbumKey()to runencodeURIComponenton thealbum&albumArtistvalues for better reliability.Test Plan
We'll install a dev version of
v1.0.0-rc.9to mimic the behavior when we eventually releasev1.0.0-rc.10. We'll use the same 3 tracks used in #32 which were 3 tracks by different artists that belong in the same album. Withv1.0.0-rc.9, we'll get 3 separate album entries.When we open up the app when running the code in this PR, we should now see a new album entry containing all 3 of those tracks (and the different albums generated by those 3 tracks prior to be gone).
Checklist
CHANGELOG.md&README.md).THIRD_PARTY.md.pnpm android:prod.