86 lines
3.6 KiB
Markdown
86 lines
3.6 KiB
Markdown
# 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
|
|
|
|
- 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.
|
|
"""
|
|
|