3.6 KiB
Bugs
-
There is a bug where re-opening the app (closing it through swiping away on the android app screen, then re-opening it) will display a splash screen with the app icon large and centered, and nothing happens.
- repro:
- open "Run 8" playlist
- skip a few songs forward/backward
- swipe away the app in Android
- (LibPasada.stop() - PlaybackEngine::stop() - musicFeed->join() hangs)
- open app again: warm restart by Android
- splash screen shows app icon, hangs there
- repro:
-
MP3File::~MP3File() must call mp3file_delete()
O> (fixed on 2026-06-11) scrubber was returning 2x the time progress from PasadaMusicPlayerEngine / liblockstep
X> annotation playback: check what happens if some songs are not paired in the playlist. I believe the index is wrong and the player plays a different song from what is displayed as title and artist.
-
syncJukeboxIfToken() is always called at startup, even if we have a jukebox already
-
"Caveat: If a sync gets past the fetch phase, runs clearAllTables(), then dies while writing some playlists, you could still end up with a partial cache. Fixing that would mean a single Room transaction or a “swap” strategy; say if you want that next."
-
"playlists 401" in Playlists Activity should send us back to the Spotify auth screen
-
the server should implement some rate limiting / deadman switch / to avoid spamming Spotify API with broken-app API calls
-
pairing fails:
- (tag data from mp3 files is there)
- are we missing tracks? (or title/artist on the tracks?)
-
resolve duplicate playlist API request upon initial pairing
""" 84.115.228.119 - - [14/May/2026 09:53:30] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 200 - 84.115.228.119 - - [14/May/2026 09:53:31] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 200 - """
Nice-to
-
beat metadata is handled by the app, currently. The handling should move into "jukebox".
-
add a test for /playlists/<playlist_id> but obfuscate the IDs and user id
-
TrackFileMatching, scoreAgainstLocalHints
- these are very rudimentary heuristics to pairing mp3 files to the playlists. check them again.
-
Playlist has empty name, id=0gjOliftUAwV48X6KK9EeP
- in our server-side api, we might want to log such events too .
-
(pairing songs) "Possible race: openTree callback may capture an empty tracks list if the folder was picked before LiveData emitted."
-
toast: "no tracks loaded for this playlist yet. [...]"
Spotify API check
after fetching about 90 playlists, I start to see 429 rate limiting.
ALSO, now, I seem to get this very soon with 429: (even after logging in again) """
84.115.228.119 - - [14/May/2026 00:46:04] "GET /playlists HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:05] "GET /playlists HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:07] "GET /playlists HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:09] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:10] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:12] "GET /playlists HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:12] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 429 -
84.115.228.119 - - [14/May/2026 00:46:17] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:22] "GET /playlists HTTP/1.1" 429 - 84.115.228.119 - - [14/May/2026 00:46:26] "GET /playlists/4f4P6ULiHn0oEedTHal2AU HTTP/1.1" 429 -
"""
""" can we please avoid fetching playlist details upon first-run? i.e. only fetch the playlists but not their contents. only fetch playlist details upon clicking a playlist. """