search

Rigellute / spotify-tui

Spotify for the terminal written in Rust 🚀
MIT License
17.61k stars 526 forks source link

Freezes #92

Closed mrcnski closed 4 years ago

mrcnski commented 5 years ago

I had it running for a few songs and when I came back I found the program had frozen. No keypresses worked anymore, and I couldn't even Ctrl+C out.

trames57 commented 5 years ago

This also happening to me. Just installed it on Arch Linux and if I go away from the app to another workspace (i3) and go back to that workspace, it can freeze. Well actually it is responding a little, but very slowly. It would seem that it may be in some kind of loop and eventually gets some system time to respond to the keyboard.

I am playing an album, and it is delivering the tracks to the album like it should through the sound. Eventually I got an API Error "Spotify API reported an error". I hit esc and nothing is happening :( My album is playing fine though! OK, after about 4 minutes, it did respond to the esc key. The track time bar and track info at the bottom of the screen has not changed at all. It looks like when it froze, the track had completed (bar is all the way across) and was going to start to show the next track in the album. Weird though that the sound continues as if it not frozen.

OK.. So I had the Spotify web client open at the same time as spotify-tui. It appears that the web client was playing the tracks during the freeze. So somehow the Spotify web app knows I am playing those tracks (I guess through spotifyd). I wonder if that was affecting the spotify-tui somehow with the API errors. I have the web client open now along with spotify-tui and they are coordinated with the same track. They seem to interact with each other and perhaps it is a "racing" issue where the Web client changes tracks before tui or something like that. If I pause in web client, tui pauses and vice-versa. If I close the web client, tui continues to play. Perhaps we should not have the web client open along with tui?

Arch Linux is up to date - just updated today (Nov 17, 2019) Using XFCE terminal in an xwindows session (i3 window manager) Installed using the arch linux AUR (spotify-tui) and it pulled the latest git release as of 11/17/2019. App built with no errors. Using spotifyd daemon

trames57 commented 5 years ago

Just to report back in. The app froze again playing an album and I did NOT have the web client open. It froze when it went to change to the next track in the album. I was actually watching it LOL. The music continued to play as normal, but the tui client did not change to the next track.

I closed the tui app (music continued to play through spotifyd). I reopened stp and pressed "a". The track that is currently playing was highlighted and the timer bar was correct.

Rigellute commented 5 years ago

Thanks for the detailed follow up.

I'm not sure what is causing this, but wondering if the rendering loop is doing too much work and your terminal emulator doesn't like it.

I've seen something similar to the behaviour you've described when using iTerm2 on macOS. Using alacritty or kitty improved things greatly. If you happen to try one of these emulators, please let me know if this affects the freezing issue.

There is lots of room for optimaztions in the UI rendering loop, will keep this in mind.

trames57 commented 4 years ago

I finally got a chance to run spt using kitty today (I also tried zsh). The track list advance on an album did freeze after a while and the music continued to play, but this time the keyboard did respond OK even after the track advance froze. If I hit "a" I got the API error. It stopped advancing at the end of a track as before.

I closed spt and reopened, hit "a" and the track that is playing showed correctly.

Updated spt to 0.10.0 (this is an improvement also in some areas - no errors during compile) Updated Linux kernel to 5.4.2 rust version is 1:1.39.0 kitty version is 0.15.0 spotifyd version is 0.2.20

jeanlescure commented 4 years ago

Similar thing happening to me, spt freezes after a few minutes if I'm not playing anything, I've actually had no problem leaving it play for long times, but if I run spt and do something else for a short period of time before playing music, every time I'll have to close the terminal since not even ctrl-c works. For clarity's sake, also happens if I stop playing music and leave unattended for a while.

Has happened both using MacOS default terminal with bash as well as using Alacritty (rust based terminal emulator) with zsh.

Mac OSX Catalina 10.15.3 spotify-tui 0.14.0 rust 1.41.0 zsh 5.7.1 and bash 3.2.57(1) spotifyd 0.2.24

EduRenesto commented 4 years ago

I was writing this as an investigation for #207, but i figured out it would be more fitting here.

I've been also having problems with my bar script trying to get the info about the current song, and found spotifyd/spotifyd#503. Apparently, it is caused by the spotify api rate-limiting the user requests.

This might be correlated to both the slow performance and these freezes.

I'll further test using a spotifyd build without MPRIS enabled, since it causes the flood of Spotify API calls.

Rigellute commented 4 years ago

I think you're right @EduRenesto.

One major issue with the current implementation of spotify-tui is that all network requests are blocking.

Every 5 seconds, the program polls spotify for current playback and this could choke the entire app process.

Now that async/await is stable in Rust, I am eager to refactor to use an async model, but this work first needs to be done in the underlying Spotify API wrapper (I want to contribute to this effort too).

EduRenesto commented 4 years ago

Definitely that's the cause. I gdb'd spotify-tui and paused the execution during one of the freezes. It was indeed blocking on a reqwest call from the internals of rspotify.

Also, disabling MPRIS postponed a bit the freezes, as expected, since it decreases the amount of requests.

Wouldn't async fix this problem only partially? Of course the freezing would stop, but the Spotify API will probably still rate limit because of the polling.

ghost commented 4 years ago

I tried #312 that supports async/await. However, the problem remains yet. When I used spt in a place has bad signal, spt is slow and sometimes does not respond to any key pressing.

Only supporting async/await can not solve this problem. We should investigate another solution for this problem.

Rigellute commented 4 years ago

Thanks for checking this @echoSayonara.

This makes total sense.

I will investigate the difficulty of moving all network requests to another thread so as to not block the rendering loop.