Sometimes on song changes the UI freezes and CPU usage goes up to 100%
What seems to be happening here is that the song
duration gets wrongly reported as
SmoothScale::_update_timeout which then leads to a
0, leading to kind of an endless loop between
_update_position_callback getting called with a timeout of
0 which then calls
_update_timeout which again calls
_update_position_callback with a timeout of
0 and so on. The wrong song duration seems to be triggered on song changes. This somehow causes
GstPlayer::_query_duration to return
(False, -1). Maybe as a workaround in addition to a maximum
timeout_period there could also be a minimum, especially since a lot of the code seems to intentionally handle
-1 as a 'valid' duration.
With such a minimum
timeout_period the UI no longer becomes unresponsive and the CPU usage does not go up to 100% on a single core in situations like this. There seem to be other things that could still trigger a high CPU usage though.