I've bumped into a number of issues while using the import with a spotify export.
- if the length of the live import line is wider than the current terminal, the line is retained, causing scrollback. As an example, if you make your terminal 240cols wide, the live updating line showing the percent / count done / current track will generally stay on a single line. if you have your terminal at 80cols, and are importing a large list, there's only about 24 columns available to the 'title - artist' portion, and you'll end up with every scrobble that didn't fit on your screen. at first i thought this was a feature, so you'd see previously imported data. but then i made my terminal wider and saw that only extremely long song titles were retained (classical ones with full symphony info).
- Tracks which are no longer available on spotify fail to submit. I find this confusing, as i'd expect scrobbles to still work even if enrichment data is unavailable. the information in the json is sufficient to create the artist/album/song entries. i've taken to manually removing these entries, and blowing away my local import caches (to ensure the missing track(s) doesn't cause issues with resume logic). i also then usually filter the start date forward to avoid a ton of revalidation of existing imported tracks.
- Failures revert your import back to where you started, forcing re-evaluation of all following scrobbles. I think this may have been mentioned in another issue. Personally, as i don't think it's possible to have more than one scrobble for a given second (whether due to last.fm rules or the Spotify data filtering of <30s by default), it seems like it'd be better to retain a list of failed tracks by the timestamp in the checkpoint file, and instead mark the latest successful (regardless of previous failures), so you pick up where you left off, and can have a thread go and retry previous failures (and remove them, if they pass on this attempt). that would reduce the check/enrich calls for imported scrobbles that pass after a singular failure. i'm also often surprised to see some tracks take ages to verify if i know they previously imported, and then it'll do a quick run of several others it identifies quickly. not sure what's causing this. In any case, given the issue with #2, i've been intentionally stopping as soon as i notice a failure, to minimize these retries in a future session, and/or to excise tracks that will always fail.
- The logic to import being near the default atproto PDS cap doesn't leave much room for ..using atproto in any other fashion. i think the default should probably start lower, and the documentation better explain the PDS limitations. if users want to 'max it out' they can easily do so, since you enforce a safe maximum regardless.
- import display of existing rocksky data stats seem buggy to me here:
- [import 9:38:49 PM] ✔ Indexed your existing library — 21,883 scrobbles, 38222 songs, 11913 albums, 6470 artists. Duplicates will be skipped.
- how is it possible to have more songs than scrobbles? a single song can be scrobbled multiple times, but a single scrobble can't contain multiple songs. is there some way this is just an output issue, or does my PDS somehow contain songs i have not generated a scrobble for as well?
- my library page is currently only listing 6200 artists as well, while an import is underway, so that's also strange.
also a minor related bug, but not in the cli. for data which is imported prior to 2024, the page for personal analytics are always capped at 2024-01-01 (what is set if you click "all time") and forward. however, the Top Scrobblers chart below obeys the date capped selected range, and also actually shows data from 'all time' (including pre-2024 scrobbles).