70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
# Bugs
|
|
|
|
- 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
|
|
|
|
- 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.
|
|
"""
|
|
|