mirror of
https://github.com/navidrome/navidrome.git
synced 2026-10-11 03:47:18 +02:00
f0625ff709getRandomSongs used a single ORDER BY random() over the media_file table. At large library sizes that forces SQLite to scan the wide table and sort every matching row before applying the limit — roughly 4 seconds for a 1M-track library, regardless of how many songs are requested. Add MediaFileRepository.GetRandom, which does this in two passes: first select N random rowids over a narrow index (filters + library scope only, no wide columns or joins), so the random sort runs over compact, index-friendly data; then hydrate just those rows with the full select. The wide media_file row is never part of the sort. End-to-end this drops getRandomSongs from ~4s to ~0.3s on a 1M-track library, and the cost no longer grows with the requested size. The handler now calls GetRandom directly. The filter helper that builds the genre/year filters is renamed SongsByRandom -> SongsByGenreAndYearRange to reflect what it does, since the random ordering is now owned by GetRandom rather than a Sort option. Filters (genre, year, library) compose into the first pass unchanged. The album random list path is left as-is (far fewer rows, already fast). |
||
|---|---|---|
| .. | ||
| backgrounds | ||
| e2e | ||
| events | ||
| nativeapi | ||
| public | ||
| subsonic | ||
| testdata | ||
| auth.go | ||
| auth_test.go | ||
| initial_setup.go | ||
| initial_setup_test.go | ||
| middlewares.go | ||
| middlewares_test.go | ||
| serve_index.go | ||
| serve_index_test.go | ||
| server.go | ||
| server_suite_test.go | ||
| server_test.go | ||
| throttle_backlog.go | ||
| throttle_backlog_test.go | ||