At some point, the switch to keying raw music information broke my
mitigation for duplicate tags that use similar cases. This then
crashed the music loader in certain cases. Fix it by making the
check use raw music keys.
Resolves#614
Only include an artists explicit albums (ones directly linked w/album
artist) in their count.
This is arguably more appropriate than the prior behavior, given
Auxio's collaborator/artist distinction.
Resolves#581.
This is part of the MusicBrainz spec, but I didn't think of implementing
it. Turns out it's stupidly common among music releases, so may as well.
Resolves#590.
M4A has it's own multi-value spec that works similarly to vorbis, where
they just repeat the atom several times with multiple values. Since M4A
atoms are remapped to ID3v2 frames, this more or less requires us to
tolerate duplicate ID3v2 frames as well, which is frustratingly a spec
violation. It solves the problem though
Resolves#558.
Make it so that music items are meaningfully different when they were
created under different settings. This resolves an issue where music
information would not correctly update when separators or intelligent
sorting would change.
Resolves#546.
Implement a new Name.Known.Factory instance that replaces the usage of
Name.Known.from.
This again allows songs to be differentiated on tag interpretation and
is generally easier to test.
Move all multi-value utilities to a new Separators interface.
This should allow separator config to be dynamically compared across
song instances, and generally make songs easier to test.
Trim simple names once punctuation has been removed.
This prevents situations where album names like "& Yet & Yet" (a real
album by post-rock outfit Do Make Say Think) will have blank thumbs.
This probably isn't the best approach in general, but nothing about the
intelligent name system is a good approach.
Apparently dialog fragments do not change the state of the fragment it
is overlaid on, resulting in it still having active StateFlow
collectors that will intercept new playlist requests before
AddToPlaylistDialog. Once again sharing StateFlows across views has
bit me.
In the future I may try to preserve the navigation idioms by not
stacking NewPlaylistDialog on AddToPlaylistDialog and instead
simply swap them out. I think this would also be better design too
(It's not like I'm allowing other decision dialogs to be exitable
back to their prior dialog).
Add a dialog that shows the stack trace of a music loading error.
This is an MVP that is only available to music loading to resolve some
immediate issues.
Resolves#527.
Add play and shuffle options for all song menus.
These will override the shuffle state, unlike other song play
interactions.
This required a good bit of refactoring to menu, some of which
might be ported to other commands in future changes.
Rename MusicMode to MusicType.
The original naming was always a bit clunky given that it referred to
both settings and data configuration. I feel that "Type" is probably
better overall.
Standardize navigation command consumption to only occur when a
navigation route has *definitively* ended. If more commands could
come, observe them. Otherwise, consume immediately.
Add a dialog that shows menu information as a bottom sheet instead of as
a PopupMenu.
This did not take as much finessing of BottomSheetBehavior as the main
playback UI framework did, just some style redefinitions.
Fix miscellanious issues from the flattened nav graph system.
Nowhere near enough, largely counting on the planned bottom sheet menus
to eventually be able to ignore most of these issues.
Simplify the 4 stateflows controlling when playlist decision dialogs
must be opened to just one enum.
This is like the detail view, and makes the amount of observers I have
to spin up much smaller.
Eventually, most of even these observer calls will be collapsed into
the menu itself.
Remove functionally duplicate artist/genre values that were read from
a file.
This caused a indexer crash in 3.1.2 due to the switch to music sets,
which no longer made duplicate values group the song twice. This then
cascaded to a failure in song finalization, as it expects there to be
the same amount of artists/genres as raw artists/genres.
Fix a regression where the loading process will never stop on a no-op
refresh operation.
This was an oversight made in the redocumentation of the loading
process.
Further document the music indexing process.
It's so aggressively parallelized as to require some more extensive
comments to actually make it clear what's going on.
Recognize artists sort, albumartists sort, and album artists tags.
These are written by mediafile, so they are probably also written by
other software.
Do not hang when an error halts the discovery process.
This was an oversight with the previous band-aid fix regarding handling
errors in music loading. If something failed, the channels would not
close, resulting in the main loop consuming the channel hanging.
There's probably a deeper issue causing this in 3.1.2, but with this
fix I can actually start digging for it.
Use sets for all child music information.
Unlike parent information, which usually has an ordering derived from
file information, child music information more or less doesn't, and
will be consistently re-interpreted by the app to apply user-configured
sorts.
Use a Set when storing all song, album, artist, and genre information.
These all have no consistent ordering due to parallelization, and
should be communicated as such.
