| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Uses 'TPOS' for id3v2 tags, and 'DISCNUMBER' for vorbis comments (mostly
just relevant to flacs for our use case).
Fixes #181.
|
|
- The tag parser's cache is now cleared between indexing runs, preventing stale data from being used
- Multi-value tag fields (genres, all artists) are now properly ingested in the tag value cache
- Cleaning up removed index records now properly handles the case where only a subset of the records for multi-value tags need to be deleted.
- Synthesizing missing tag values is now done in the tag parser instead of TrackTags, which resolves some issues with multi-value tag callbacks from libtags not being handled properly
These fixes seem to address all the issues with stale index records we were able to repro (including the issues in https://codeberg.org/cool-tech-zone/tangara-fw/issues/191), but if you've got any more cases with consistent repros then lmk!
Co-authored-by: ailurux <ailuruxx@gmail.com>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/193
|
|
Queue now has a separate 'ready' property to indicate it's ready to be used, which is independent from whether it's still loading tracks in. This also improves the response time for shuffling all tracks (we will initially pick a random track in the first 100 tracks whilst the rest of the tracks are loading). This should also fix issues where one song will start playing and then repeat itself when the queue finishes loading, and hopefully solve #160 as well (though I couldn't actually repro this myself).
Co-authored-by: jacqueline <me@jacqueline.id.au>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/170
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
It turns out the index *id* controls this, which is probably not good!
|
|
mp3 is no good i do not like them at all
|
|
|
|
This is mostly just for flac handling, since we use libogg directly for
ogg containers, and flac+ogg are the only containers that use vorbis
comments.
|
|
|
|
We still mostly use the singular 'Artist' tag for e.g. displaying a nice
name in the now playing screen, but where a track has an 'ARTISTS=' tag,
we'll split by semicolon and then use the resulting list to populate an
index of tracks by artist
|
|
Trying and failing to parse tags from unsupported files is probably
costly (requires reading from SD card), and it probably slows down
indexing large collections that include a lot of non-audio files (like
cover art, etc).
This limits tag parsing to only files that have extensions for
supported audio formats. It assumes that folks don't have audio files
in supported formats with crazy extensions (e.g. an mp3-formatted file
with the extension .lol). Since this hardcodes a list of supported file
extensions for tag parsing, it'll need to be maintained later if more
formats are supported. The file ext matching is case-insensitive.
Fixes #149
|
|
- Accept 'DISCNUMBER' as a synonym for 'DISC'
- Accept 'TRACK' as a synonum for 'TRACKNUMBER'
This should help with #146
|
|
|
|
|
|
|
|
|
|
|
|
Podcasts aren't tagged consistently enough for other groupings to make
sense, at least until we implement RSS parsing
|
|
|
|
|
|
Initially set based on filepath, or by genre if the filepath doesn't
match one of our presets
|
|
|
|
|
|
|
|
|
|
This seems to be tickled by the ogg comment handling changes (possibly libtags doesn't actually handle this case?)
|
|
This is somewhat faster than relying on libtags to parse these, and also better handles cornercases such as tags that cross physical page boundaries.
|
|
This also has the effect of breaking up the enormous 'updateIndexes'
method into one call per file, which means database updates also no
longer monopolise a single background task for their entire duration.
avg. time per new file is now <140ms for a completely fresh database,
which is pretty good i think!
|
|
|
|
This is ostensibly yet another 'prepare for multithreaded updates'
commit, however it does actually save us another 60(!!) odd milliseconds
per track.
|
|
explicitly
This saves about 1ms per new track right now, but more importantly means
that minting a new track id is now a single atomic operation, rather
than being its own database write. This is a useful property that will
come in handy in a few commits time.
|
|
Also drop some of the other tuning changes, since they don't seem to
impact much.
|
|
|
|
This has been the cause of the elusive "selecting a track opens it like an index" bug :)
|
|
|
|
|
|
|
|
With Daniel's fix, this is no longer needed! Hooray!
|
|
Fixes issue with apparent duplicated tracks in the infinite list
|
|
|
|
|
|
|
