mirror of
https://github.com/misiektoja/spotify_profile_monitor.git
synced 2026-04-26 07:25:56 +03:00
[GH-ISSUE #2] 403 Errors #1
Labels
No labels
Stale
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotify_profile_monitor#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tomballgithub on GitHub (Mar 21, 2025).
Original GitHub issue: https://github.com/misiektoja/spotify_profile_monitor/issues/2
I am getting a lot of these 403 errors. I've looked back in my log, and they didn't start until 3/18 when I updated to the latest TOTP code fixes and other changes. Any ideas?
@tomballgithub commented on GitHub (Mar 21, 2025):
The only other noteworthy thing is I am getting occasional 404 errors due to what I believe is an inaccessible playlist. It gets flagged when I first start up the monitor and then these are very consistent
@misiektoja commented on GitHub (Mar 21, 2025):
Please use the latest released version - it contains many fixes related to this logic.
I have been running it for a few days on my test account without any issues so far.
As for the second one - is the playlist issue visible on the user profile? Can you normally access it in your web browser? Typically, a 404 error occurs when a user removes the playlist or switches it to private.
@tomballgithub commented on GitHub (Mar 21, 2025):
I will try the latest version.
The monitor and the spotify web version say this profile has 26 public playlists. The web version shows 26 and the profile tool lists 25 + 1 error. The 1 error is this popular playlist which is actually NOT managed by this profile, but it's showing up on this profile's public playlist page in the web. This is the playlist: https://open.spotify.com/playlist/37i9dQZF1DX4E3UdUs7fUx
@misiektoja commented on GitHub (Mar 21, 2025):
Wow, I think you found some interesting corner case! I guess you use the -k parameter to grab all the playlists, right ?
I added it to my test account profile and encountered the same issue. It appears to be a special type of playlist. It belongs to Spotify and is dynamically generated for each user and for some reason it is not available via regular API endpoint (thus 404 error).
I need to review Spotify's documentation to understand how to manage it, maybe there is another endpoint for this, but anyway I'm confident I can address it in the code somehow. I believe we should simply skip those, as it is of little interest to us what Spotify adds/removes there. I'll get back to you on this.
By default, only public playlists owned by the user are fetched and as a workaround I suggest to disable fetching all of them (remove -k / --get_all_playlists parameter).
@tomballgithub commented on GitHub (Mar 21, 2025):
Yes, without -k I am seeing 12 playlists dropped off and not monitored. I was just going to hack the code to remove that one but never got around to it.
@misiektoja commented on GitHub (Mar 21, 2025):
Ok, it was easier to fix than I thought. The issue stems from this:
All the tracks in Spotify-generated playlists have an empty ID and a user URI ID for the user who added the track (added_by) and the code assumed something was wrong with the playlist and thus displayed the error message you saw.
I fixed it and the tool can now properly detect tracks added by the Spotify robot ;-) I pushed it into dev and main branches, so let me know if all is good now.
@tomballgithub commented on GitHub (Mar 22, 2025):
Running this now, and it fixed the 404 errors. However, will it be monitoring for changes in this spotify playlist that is not controlled by this profile? Depending on the playlist, as some of these get refreshed constantly, that could generate lots of changes. If it will get detected, it would be nice to have a flag to ignore those types of playlists completely.
@tomballgithub commented on GitHub (Mar 22, 2025):
I didn't expect to really see this so quickly, but there really needs to be a way to filter the public playlists. This happened in just a few hours
@misiektoja commented on GitHub (Mar 24, 2025):
I fully agree! Let me come up with a nice filtering solution for that. I'll keep you posted!
@misiektoja commented on GitHub (Mar 24, 2025):
I'm closing this one as the 40x errors seem to be fixed. As for the filtering solution, check out the response here.