Clementine
Clementine copied to clipboard
1.4.0rc1 - INTERMITTENT - double clicking on a song and it won't play
Before posting
Please follow the steps below and check the boxes with [x] once you did the step.
- [*] I checked the issue tracker for similar issues
- [*] I checked the changelog if the issue is already resolved
- [*] I tried the latest Clementine build from here
System information
Please provide information about your system and the version of Clementine used.
- Operating System: Ubuntu 20.04
- Clementine version:
Clementine 1.4.0rc1-737-g69fd49b97
Expected behaviour / actual behaviour
Expected: I double-click on a song in a playlist and it starts playing Actual: I double-click on a song in a playlist and it doesn't start playing. If I double click again either it does start or doesn't but it seems non-deterministic. Sometimes I need to double-click several times, sometimes it works right away.
Steps to reproduce the problem (only for bugs)
Choose a song, double-click to play (NOTE: I have reproduced this with the app remote as well, so it's not about the clicking or the UI), it may work, or I may need to keep selecting it over and over until it does.
I've tried running with --verbose
, and the only ERROR
I see is this (note that this bus sync thing happens a lot):
11:20:12.011 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.011 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.012 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.013 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.014 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.015 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.016 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.016 DEBUG GstEnginePipeline:622(GstEnginePipelineCallbacks) 2 sync bus message buffering
11:20:12.994 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
11:20:14.043 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
11:20:14.047 ERROR logging:64(GLib) Source ID 21 was not found when attempting to remove it
After this line I see these messages, once per second, forever, but nothing starts playing:
1:20:17.178 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
11:20:18.178 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
11:20:19.178 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
11:20:20.177 DEBUG MainWindow:1596 position: 0 , scrobble point: 116 , lastfm status: 0 , play count point: 116 , is local library item: true , playlist have incremented playcount: false
I have a workaround for this that I'm completely happy with, but want to leave this open for your reivew.
If I turn off 'crossfade when manually selecting tracks', everything works as expected.
Yeah, I've seen this and also noticed that disabling the cross-fade fixed the issue. Strangely, though, I couldn't repro the issue by turning on cross-fade on a different install, so I think there might be a second variable.
I'm running Kubuntu 20.04 and don't seem to get that bug. However, I did notice that with cross-fading enabled and switching songs manually, I always get an error message
ERROR logging:64(GLib) Source ID xy was not found when attempting to remove it
a short while after switching. This does not occur if I disable cross-fading and neither when the playlist switches to the next songs after finishing the previous one. I haven't had the time to look at this in detail so far, but my (uneducated) guess would be that this is from code that is supposed to remove the previous song after fading and uses the source ID in gstreamer for doing so. I've found doing stuff like that to be somewhat finicky in the past (and it doesn't seem to be working properly here as well), so maybe there's some race condition that might cause the switched-to song to be removed instead in rare cases, which might then lead to it not being played.. I'll see if I have time to dig deeper soon.
EDIT: Disregard the above. I have noticed that the above error is logged for every song change, manual or not, cross-fade or not (it just stands out more with cross-fade manual), so it's probably unrelated to this.
EDIT2: I nevertheless managed fixed the error message mentioned above. @nathanschepers Just on the off chance that it was related after all, could you see if you still encounter your bug in the latest pre-release ?
Same Problem