mirror of
https://github.com/navidrome/navidrome.git
synced 2026-10-08 02:17:25 +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). |
||
|---|---|---|
| .. | ||
| fixtures | ||
| fake_http_client.go | ||
| init_tests.go | ||
| mock_album_repo.go | ||
| mock_artist_repo.go | ||
| mock_data_store.go | ||
| mock_ffmpeg.go | ||
| mock_genre_repo.go | ||
| mock_library_repo.go | ||
| mock_library_service.go | ||
| mock_mediafile_repo.go | ||
| mock_playlist_repo.go | ||
| mock_playlist_track_repo.go | ||
| mock_playqueue_repo.go | ||
| mock_plugin_manager.go | ||
| mock_plugin_repo.go | ||
| mock_property_repo.go | ||
| mock_radio_repository.go | ||
| mock_scanner.go | ||
| mock_scrobble_buffer_repo.go | ||
| mock_scrobble_repo.go | ||
| mock_share_repo.go | ||
| mock_transcoding_repo.go | ||
| mock_user_props_repo.go | ||
| mock_user_repo.go | ||
| mock_user_service.go | ||
| navidrome-test.toml | ||
| test_helpers.go | ||