Version: 2.4.1 (using KDE 4.6.2) OS: Linux I have two computers, a laptop and a desktop pc. The latter is connected to my stereo. I experimented a bit with pulseaudio's ability to stream audio over network and finally managed to get it working (the gui configuration option didn't work, but loading everything manually with help from http://wiki.openwrt.org/doc/howto/pulseaudio worked). Now I can set the Amarok output to send the sound to the network sink in pavucontrol, start a track and my desktop plays it on the stereo. However, the progress bar stays at 0:00 and when the track ends, Amarok stops playback as if I had pressed stop. This only happens if I use the network sink, I can switch the output back to the laptop, start a new track (the playback of the old track seems to continue, however there is no sound) and no problem occurs. Interestingly, this also does NOT occur if I use a combined sink, that outputs on laptop and network. I don't know if the problem is actually in Amarok or if the network sink is simply behaving incorrectly, but even then Amarok should at least be able to play the next track, since doing so manually obviously works. Reproducible: Always Steps to Reproduce: -Setup audio over network -Set output to other pc -Start a track and wait Actual Results: Playback stops after the track, the whole time, the progress bar sits at same track at time 0:00. Expected Results: Next track should start.
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!