[GH-ISSUE #611] Saved albums are not recognized when an artist's page is loaded without a search #247

New issue

Closed

opened 2026-02-28 14:48:01 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 14:48:01 +03:00

Owner

Originally created by @Utagai on GitHub (Oct 10, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/611

Seems like, if you search for an artist, then with a high probability, you will also find some or all of their albums as well. When this happens, spt will asynchronously dispatch an event for populating its knowledge of the user's saved albums.

This works pretty well most of the time, but has two main issues:

If you navigate to an artist's page outside of a search, e.g., through your saved artists, your saved albums won't be recognized.
If by some quirk of Spotify's search, one or more of the artist's albums is not fouund, and you eventually load the page for that artist, the correct albums won't be recognized as saved.

Here's a screenshot of an artist I follow, that I found by searching:

Note that the saved albums are starred.
NOTE I'm running a fork of spt where I have changed the glyph used for saved albums, because the heart wasn't rendering with the font I use. I'm considering filing another issue to make the symbol configurable for those who have non-unicode supporting fonts/environments like me, or may dislike the icon, etc, but this is not relevant.

Here's a screenshot of the same artist that I navigated to from my saved artists:

NOTE I feel like it would make sense that the code would be analogous for saved tracks as well, but the current code only dispatches an event for caching the saved albums only. I'm assuming this omission was intentional, but it is a little odd so this issue may be applicable to tracks too.

Originally created by @Utagai on GitHub (Oct 10, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/611 Seems like, if you search for an artist, then with a high probability, you will also find some or all of their albums as well. When this happens, `spt` will asynchronously dispatch an event for populating its knowledge of the user's saved albums. This works pretty well most of the time, but has two main issues: 1) If you navigate to an artist's page outside of a search, e.g., through your saved artists, your saved albums won't be recognized. 2) If by some quirk of Spotify's search, one or more of the artist's albums is not fouund, and you eventually load the page for that artist, the correct albums won't be recognized as saved. Here's a screenshot of an artist I follow, that I found by searching: ![image](https://user-images.githubusercontent.com/10730394/95665389-b1cea880-0b1d-11eb-874e-ae3e154c587a.png) Note that the saved albums are starred. **NOTE** I'm running a fork of `spt` where I have changed the glyph used for saved albums, because the heart wasn't rendering with the font I use. I'm considering filing another issue to make the symbol configurable for those who have non-unicode supporting fonts/environments like me, or may dislike the icon, etc, but this is not relevant. Here's a screenshot of the _same_ artist that I navigated to from my saved artists: ![image](https://user-images.githubusercontent.com/10730394/95665404-e8a4be80-0b1d-11eb-9da9-c44b7ec4b181.png) **NOTE** I feel like it would make sense that the code would be analogous for saved tracks as well, but the current code only dispatches an event for caching the saved albums _only_. I'm assuming this omission was intentional, but it is a little odd so this issue may be applicable to tracks too.