summaryrefslogtreecommitdiff
path: root/src/tangara/database/database.hpp
AgeCommit message (Collapse)Author
2025-01-24Resolve some issues with dangling index records (#193)cooljqln
- 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
2025-01-07Improvements to the queue for shuffling/playing all (#170)ailurux
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>
2024-12-30Add a new track tag + index for multiple artistsjacqueline
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
2024-09-19Introduce a MediaType for each track and indexjacqueline
Initially set based on filepath, or by genre if the filepath doesn't match one of our presets
2024-09-12WIP: Add last_position field to track data and start on implementationailurux
2024-09-03Use libogg + our own parser for ogg filesjacqueline
This is somewhat faster than relying on libtags to parse these, and also better handles cornercases such as tags that cross physical page boundaries.
2024-08-12Shard searching for new tracks across multiple tasksjacqueline
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!
2024-08-12Make FileGatherer shaped more like a normal iteratorjacqueline
2024-08-12Batch up the db operations associated with adding new tracksjacqueline
This is ostensibly yet another 'prepare for multithreaded updates' commit, however it does actually save us another 60(!!) odd milliseconds per track.
2024-08-12Derive the next track id from stored track data, instead of tracking it ↵jacqueline
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.
2024-07-11Break FatfsStreamFactory's dep on ServiceLocatorjacqueline
2024-05-02start moving include files into subdirsjacqueline
2024-05-02WIP merge cyclically dependent components into one big componentjacqueline