|
Description
mk
2011-07-03 21:50:34 UTC
Amarok doesn't handle sound itself, it lets Phonon do that, reassigning. Could you please also specify which Phonon backend you are using? Sorry for filing it for the wrong program then. The phonon configuration dialogue says the backend is GStreamer 4.5.0 Thank you for the feedback. *** Bug 306883 has been marked as a duplicate of this bug. *** Is that still a problem with phonon gstreamer 4.6.2 & phonon 4.6? If so a debug log would be very helpful: http://techbase.kde.org/Development/Tutorials/Debugging/Phonon (In reply to comment #5) > Is that still a problem with phonon gstreamer 4.6.2 & phonon 4.6? If so a > debug log would be very helpful. A debug log is here: https://bugs.kde.org/show_bug.cgi?id=306883 Well, I don't see random stopping there. PGST emits abouToFinish, which gets handled by tomahawk in onAboutToFinish but does not set a new source, so playback stops. Progress bar staying at 0:0 may well be related to the network sink though (which would be a bug in gstreamer itself). (In reply to comment #7) > Well, I don't see random stopping there. Why are you looking for random stopping? It doesn't stop randomly. It just stops after each track (every time) as stated in the topic of this bug and is reflected by my bug log as you say. > PGST emits abouToFinish, which gets > handled by tomahawk in onAboutToFinish but does not set a new source, so > playback stops. Then this is the fault of tomahawk? If yes, could you please tell them how to do it right? Because their opinion is that they do nothing wrong (based on the fact, that it works as expected with the vlc-backend). > Progress bar staying at 0:0 may well be related to the > network sink though (which would be a bug in gstreamer itself). Okay. I will file a bug report there as soon as my distro offers the latest version of gstreamer. It is all a bit convoluted. When tomahawk stops, does it reflect so in the UI? What puzzles me about the log is that absolutely nothing appears to happen after abouttofinish although phonon should actually go into stopped state immediately after that. So my theory is that gstreamer for whatever reason fails to get the total length and the current position right (or for the sake of argument perhaps phonon gstreamer is doing it wrong...) which then explains why the progress bar remains at 0 and why playback stops (i.e. it does not actually stop on a state level... it stops producing audio, but the pipeline keeps running). So what additionally would be interesting is a) does the UI reflect the stopedness b) a couple of pipeline graphs both with and without the network sink, you basically add another environment variable as explained on [1] and then tar up the .dot files and attach them to this bug. [1] http://techbase.kde.org/Development/Tutorials/Debugging/Phonon#Drawing_a_dot_diagram (In reply to comment #9) > So what additionally would be interesting is > a) does the UI reflect the stopedness No, for example the "pause"-button should change to "play" if nothing is played, but it stays "paused", so Tomahawk acts as there is still something to play. Interestingly when pressing the "pause" button after the song has finished Tomahawk plays the next song (in contrast, pressing the "pause" button during real play causes Tomahawk to pause and resumes as one would expect). > b) a couple of pipeline graphs both with and without the network sink I will upload both the logs and the generated pipeline graphs with and without network sink. The filenames of the logs without network sink are prefixed with 'wop_' while the ones with pulsesink are prefixed with 'p_'. What I was doing during logging: * with pulsesink: - start tomahawk - select a song to play - wait for song to finish - exit tomahawk * without pulsesink: - start tomahawk - select a song to play - wait for song to finish - the next song begins to play - stop the song - exit tomahawk Created attachment 75249 [details]
debug log with network sink
Created attachment 75250 [details]
pipeline graph with network sink
Created attachment 75251 [details]
pipeline graph with network sink
Created attachment 75252 [details]
pipeline graph with network sink
Created attachment 75253 [details]
pipeline graph with network sink
Created attachment 75254 [details]
pipeline graph with network sink
Created attachment 75255 [details]
debug log without network sink
Created attachment 75256 [details]
pipeline graph without network sink
Created attachment 75257 [details]
pipeline graph without network sink
Created attachment 75259 [details]
pipeline graph without network sink
Created attachment 75260 [details]
pipeline graph without network sink
Created attachment 75261 [details]
pipeline graph without network sink
Created attachment 75262 [details]
pipeline graph without network sink
Created attachment 75263 [details]
pipeline graph without network sink
Created attachment 75264 [details]
pipeline graph without network sink
Created attachment 75265 [details]
pipeline graph without network sink
any news on this? Harald, the requested feedback is available. I think that PulseAudio network sink is a pretty bad idea anyway. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |