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 1.0
in SmoothScale::_update_timeout
which then leads to a timeout_period
of 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.