mirror of
https://github.com/aome510/spotify-player.git
synced 2026-04-26 01:15:55 +03:00
[GH-ISSUE #160] Sucking up too much of my CPU #78
Labels
No labels
bug
documentation
enhancement
good first issue
help wanted
pull-request
question
third-party
third-party
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotify-player#78
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 @vannotz on GitHub (Mar 19, 2023).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/160
Spotify-player has the tendency to suck up way too much of my CPU, it usually hangs around the ball-park of 25% CPU usage with common spikes to 50% and sometimes (like when opening the program), it spikes up to 80%. It also has the tendency to suck up 100% of a single core, changing between which.
I have compiled spotify-player with the alsa-backend and image features if that's of any concern.
spotify-player-23-03-19-12:35.log
I am running on Artix Linux with the runit init system.
@vannotz commented on GitHub (Mar 19, 2023):
I have changed some settings in my app.conf, I was refreshing some stuff too quickly and it was taking a hit on my CPU, although the problem of it spiking to 80% on startup still persists, it doesn't surpass 15% usage anymore, with no further spikes during session.
@aome510 commented on GitHub (Mar 19, 2023):
Yeah, you're right, from the logs, it was because these two values are set to
0. I think the default values should work well.Another thing I found interesting from the logs is
The 4 requests took really long time to finish, which I think is the reason for the 80% spike on startup. Do you happen to have a large number of liked tracks, playlists, saved albums, or followed artists? By large here, I mean more than 500 items. For comparison, here is what I have on a normal run on my account:
I only have 131 liked tracks.
@vannotz commented on GitHub (Mar 19, 2023):
Depends, I have 230 liked song and my artists+playlists+saved albums would probably total just around 100. I could get hid of quite a few, most of these are trash I saved years ago and never thought about them again. I could give it a clean up and try launching the program again.
@vannotz commented on GitHub (Mar 19, 2023):
Removing a good amount of liked songs, followed artists, liked albums, etc has indeed solved the CPU spiking issue and looking at the logs I cut down, for example, GetUserPlaylists, from 8478ms to 489ms. I guess I didn't notice how much junk I had saved up. Thank you for your help
@braheezy commented on GitHub (Mar 21, 2023):
Just happened to randomly read this thread. I've got some metrics too.
I have over 4k liked Songs and similar absurd counts for liked Albums and Artists. Here's the request times. Check out that GetUserSavedTracks call!
Granted, this machine has a 13th gen i5. But CPU load was unnoticeable and startup time is quick. Slight expected delay in some of the menus as the data loads in.
@vannotz commented on GitHub (Mar 21, 2023):
I have a 8th i7 so I don't think the difference should be this massive to the point as I get 80% usage spikes and you don't even notice it but clearing up my tracks has solved the issue either way
@aome510 commented on GitHub (Mar 21, 2023):
Look like this issue is resolved by you @vannotz. I'll close it for now. Feel free to reopen if encounter any related issues.