The playback stops even in case of flac files. So, I guess it is not a problem of codecs. Also, there is no fade-out now, still the problem occurs. So fade-out is not a problem as well.

The playback stops even in case of flac files. So, I guess it is not a problem of codecs. Also, there is no fade-out now, still the problem occurs. So fade-out is not a problem as well.

The problem is with the phonon-backend-gstreamer. Do you use the latest 4.6.0 version?
Also you didn't specify your Amarok version, please provide that feedback.

Sorry for that.
My amarok version is 2.5.0.
The phonon-gstreamer version is 4.6.0.

Thank you for the feedback.

I have observed another type of behaviour, sometimes the playback would "race" through the file without playing the sound (kind of like what happens when we have got an incomplete file or a damaged file). But then, replaying the file makes the playback occur normally. 

I'm trying out the debug functionality now and will see if I get anything worth looking at and will post it here if I find anything.

strangely, I'm having the same issue, but with the phonon-vlc backend.  With phonon-gstreamer everything works perfectly fine.  

This is on Fedora 16 64-bit with package phonon-backend-vlc-0.5.0-1.fc16.1.x86_64

I'm getting the problem on both phonon-backend-vlc and phonon-backend-gstreamer.

I have seen this with the MPlayer, VLC, and GStreamer backends. This is not looking very backend-specific.

Could it have something to do with the version of the backends?  Although I've had some glitches here and there with gstreamer, this seemed to happen a LOT with VLC.  Could it depend on the type of file? ogg vs flac vs mp3?

Very strange. Since playback is done by Phonon I doubt it is an Amarok problem. Could you all please add these environment variables to your $HOME/.bashrc, reload it and start amarok with the options -d --nofork from the konsole:

$ export PHONON_DEBUG=5
$ export PHONON_PULSEAUDIO_DEBUG=5
$ export PHONON_VLC_DEBUG=5
$ export PHONON_GST_DEBUG=5

Please only paste the part of the output where the playback stops.

Just to narrow down the problem: you all use Pulseaudio, don't you?

I do use pulse audio.  I'll have to see if I can find some time this weekend to test the VLC backend with those options in the bashrc file

I definitely do _not_ use pulseaudio, and I see the problem with every backend that I've tried (vlc, mplayer, and gstreamer).

Created attachment 70913 [details]
Log of amarok stopping with phonon-vlc

I ran amarok from konsole with the environment variables as requested, and here's the latter portion of the log.

Thank you for the feedback.

Created attachment 70949 [details]
log of amarok with pulseaudio and gstreamer

I have also been getting this problem for quite a while (amarok 2.5.0, kde 4.8.3, phonon-gstreamer 4.6.0, pulseaudio 2.0). After the silence from 0:02, it seems that playback continues from arbitrary position. Once it continued playing from the middle of the next song. Here is debug strings when playback continues, if it is any help:

amarok: BEGIN: void EngineController::seek(int) 
amarok:   [EngineController] seek to:  44811 
amarok: END__: void EngineController::seek(int) [Took: 0.015s] 
"PulseSupport(2): Found PulseAudio stream index 30 for Phonon Output Stream {739cb8de-e4ff-45e3-a1b5-bd4ff7d52be2}" 
"PulseSupport(2): Found PulseAudio stream index 30 for Phonon Output Stream {739cb8de-e4ff-45e3-a1b5-bd4ff7d52be2}" 
amarok: BEGIN: void ScanManager::checkForDirectoryChanges() 
amarok:   BEGIN: void DirWatchJob::setPaused(bool) 
amarok:   END__: void DirWatchJob::setPaused(bool) [Took: 0s] 
amarok: END__: void ScanManager::checkForDirectoryChanges() [Took: 0s]

Was hoping this would have been fixed with amarok 2.6, but no, still having this problem. Arch Linux with amarok 2.6.0, kde 4.9.0, phonon 4.6.0, phonon-gstreamer 4.6.2, pulseaudio 2.1.

I believe that a temporary workaround can be to seek to zero at the start of the track by default, since I can get the track to start playing normally when I do so using the GUI and then the corresponding message that appears is as follows.
 [EngineController] seek to:  0 

Seamless playback may get affected though.

Also, does this indicate any error?
""PulseSupport(2): Phonon Output Stream {928fe94c-2a11-4c52-92c7-4df8bc115a93} is gone at the PA end.
Marking it as invalid in our cache as we may reuse it."

Created attachment 73227 [details]
Log of the problem from amarok 2.6.

Attached an excerpt of the log when the problem occured. Running amarok 2.6 with pulseaudio 2.1 and phonon-gstreamer 4.6.2.

(In reply to comment #13)
> I definitely do _not_ use pulseaudio, and I see the problem with every
> backend that I've tried (vlc, mplayer, and gstreamer).

Hmmm, what kernel version and alsa-lib are you using?

Is this reproducable with the normal VLC UI or mplayer?

> Hmmm, what kernel version and alsa-lib are you using?

I'm on Arch. It's constantly changing. At the moment, it's kernel version 3.5.4  and alsa-lib version 1.0.26.

> Is this reproducable with the normal VLC UI or mplayer?

Not that I've ever seen, but I don't do more than play single videos at a time with them. I don't use them for playlists or whatnot.

And it doesn't even happen consistently with amarok. Once it starts happening, I have to reboot to fix it, but who knows if it'll happen again after I rebooted or when it'll happen again if it doesn't.

I tried to reproduce this with vlc backend (phonon-vlc 0.6.0), after several days of playing, this never occurred for me with vlc. But with gstreamer backend this happens constantly: silence at 0:02, silent during few songs in a playlist, then suddenly in the middle of a song plays about 1 second from a previous song, then again playing ok.

(In reply to comment #24)
> I tried to reproduce this with vlc backend (phonon-vlc 0.6.0), after several
> days of playing, this never occurred for me with vlc. But with gstreamer
> backend this happens constantly: silence at 0:02, silent during few songs in
> a playlist, then suddenly in the middle of a song plays about 1 second from
> a previous song, then again playing ok.

Forgot to mention that those songs that are "played" during the silence are not scrobbled to last.fm.

Setting status correctly.

*** Bug 311469 has been marked as a duplicate of this bug. ***

I'm also having this problem since many months. It does happen randomly with both backends, but much more frequently with gstreamer's one. However, I'm using this one since vlc's one seems not to respect replaygain.

Are there advances in this bug?

Some details of my box:

ArchLinux, pulseaudio, KDE 4.9.4, 64 bits
amarok 2.6.0
kernel linux-ck 3.7.1
alsa-lib 1.0.26
pulseaudio 3.0
phonon 4.6.0
phonon-gstreamer 4.6.2
phonon-vlc 0.6.1

Created attachment 76614 [details]
Log of short stop on aac-file with amarok -cd --debug-audio

Yeah, the bug advanced to amarok 2.7.0. ;-)
I´m on Gentoo here. Would there be any outcome of compiling phonon-gstreamer, phonon and amarok with debug support (maybe more verbose output or similar)?
I also don´t use pulseaudio. For me, this bug happens exclusively for aac-files. If I seek to the end of the previous track, playing sometimes stops for a short time at the 2 second mark and continues after a short time amount. Maybe this is relevant.
amarok 2.7.0
phonon 4.6.0
phonon-gstreamer 4.6.2
alsa-lib 1.0.25

Created attachment 77077 [details]
Curious behavior about amarok playback stream.

Hi,

TL;DR The bug has its origins in the beginning of song played before the song at which the playback actually stops. The bug seems to be caused by the Wikipedia plugin. The following is my analysis.


I was casually looking at the kmix output when listening to amarok today.  And I saw something interesting which might be related to the bug. I have found the behavior recurring almost everytime the bug occurs, so there is a high co-relation if not a causation.  

As you can see, the first interesting thing is the presence of two playback streams in the multiplestreams01.png when actually only one song was playing. The correct stream is the "I'm with You" by Avril Lavigne. For the record, I do not even have any "Jules Ismail" song on my computer. Actually if you visit the link [1], you will see that 'Avril Lavigne' by Jules Ismail is actually a wikipedia audio file read out of the article on Avril Lavigne. That is the first result in google showing up Jules Ismail on wikipedia. 

Anyway, the song "I'm with you" plays perfectly nicely. However, the next song was "Inside Out" by Bryan Adams, which failed to play and the bug occurs there.  If you see in the photo 2, all you get from Amarok is "Playback Stream" which does not describe the song name. The song stops after two seconds. Now, I click on the beginning of the of the toolbar to start such songs again. And when I start the song again, there is no correction and the whole song is played in the playback stream. The next song then has the correct playback stream details though. (Photo 3)

However, when I click on the song from the playlist, the song title corrects itself. And then, plays with the correct details again. That is one approach. 

Now, I tried to press the back button when the song in Photo 3 was being played, and we go back to the song in photo 2 but this time, it plays properly with proper stream name as seen in Photo 4. 

So, it seems the playback stream handling gets messed up on the previous song than where the bug actually occurs. I have not yet tested the logs to find out anything suspicious, but I will keep a watch out for it in the future and see if I can reproduce the bug.

[1] : https://en.wikipedia.org/wiki/File:Avril_Lavigne_Wikipedia_Article_Read_By_Jules_Ismail.ogg

Also, it looks to me that the playback stream handling occurs over the period of 2-3 seconds on my computer. During this time, both the streams (the previous song and the next song) are registered with kmix. Then, after two seconds, the playback stream of the previous song de-registers itself. In my case however, the playback stream of the previous song does not deregister itself automatically. 

When I click on the beginning on the toolbar to start the song again, then the normal behaviour occurs and the playback of the previous stream is automatically dropped after 2-3 seconds.

I don't know about the previous track being to blame, but Wiki is unlikely. I disconnected my computer from the network and saw no difference in behaviour.

@Tim: Dry disabling your wiki widget in the bar. I have disabled it, and since there, there have not been any bugs. However, my testing is not very extensive, and I am planning to keep on running songs all day long starting right now and see how it goes.

As far as I can tell, I don't have any wiki plugin installed, and almost every plugin that I do have installed is disabled, and yet I still run into this problem sometimes. So, while a wiki plugin might exacerbate the problem, it can't be the sole cause. And I've never seen a pattern to this bug. Once it starts happening, I usually (always?) have reboot to get it to stop, but it seems to be completely random as to when it strikes. I have no clue what conditions could be triggering it.

Okay, I can confirm that the problem still occurs without the plugin. But without the plugin, the severity is hugely reduced. From like once per 6-7 songs to once per 40-45 songs.

Created attachment 77168 [details]
An error log of amarok describing the previous track than the one where the bug takes place.

I have been monitoring as to when the playback stream stops being accurate to the name of the song as described in my previous comment, and I have recorded the log file for the same which I have uploaded. Looking through the log file, the following lines stand out, as they appear only when the song with "incorrect" stream is being played. And the lines keep on recurring for a long time, as can be seen. The lines are as following:

amarok:   [EngineController] slotMetaDataChanged() triggered by phonon, but we've already seen exactly the same metadata recently. Ignoring for now. 
amarok: [00;32mEND__:[00;39m void EngineController::slotMetaDataChanged() [00;32m[Took: 0s][00;39m 
amarok: [00;34mBEGIN:[00;39m void EngineController::slotMetaDataChanged()

Created attachment 77169 [details]
An error log of amarok describing the previous track than the one where the bug takes place.

Uploaded a truncated file before. This is the full error file for those who want to see how the comments I described do not appear in previous songs.

(In reply to comment #36)
> Created attachment 77168 [details]
> An error log of amarok describing the previous track than the one where the
> bug takes place.

Right, but since this bug is about the phonon-backend-gstreamer you should at least have the phonon debugging enabled, see also http://techbase.kde.org/Development/Tutorials/Debugging/Phonon

Also please make sure you test this with the phonon-backend-vlc as well.

Created attachment 77283 [details]
Detailed Error Log with Phonon Debug Enabled

I have followed the steps given as mentioned to create  a Phonon Debug Log for Gstreamer. I will create one for VLC soon.

The playback stops on the track "Depend on Me" by Bryan Adams. The song playing before that was "Money (That's What I Want)" by beatles. 

After the playback stopped on ""Depend on Me" , I clicked on the position at 0:00 to start the song and then later pressed the back button to go back to the "Money" song, and let it finish after which the playback stopped again on "Depend on Me". 

I hope this information is good. If not, ask me for more information.

Thanks for the update.

*** This bug has been confirmed by popular vote. ***

I have a track that this occurred on quite regularly (Lucy in the Sky with Diamonds by The Beatles) in Musepack and cleared the tags to no avail. It still stops 3 sometimes 2 seconds in.

Created attachment 78864 [details]
Error log from comment #39

Error log from comment #39

This problem (at least with Amarok) seems to be alleviated completely with the vlc backend and vlc-extras package (that plays Musepack if you've seen it happen with Musepack). With Juk the pauses seem fewer and farther in between with the Gstreamer backend as opposed to the VLC backend which runs flawlessly.

I cleaned my debian to revert to a 100% wheezy one, removing all deb-multimedia packages and installing wheezy ones, and the bug disappeared.

*** Bug 320504 has been marked as a duplicate of this bug. ***

Any news on this ? 
If you need new/further debugging output feel free to ask

(In reply to comment #47)
> Any news on this ? 
> If you need new/further debugging output feel free to ask

Which exact KDE and Amarok versions as well as phonon backend versiion are you using?

Phonon-Gstreamer: 4.6.3
Amarok: 2.7.1
KDE 4.10.4

*** Bug 322746 has been marked as a duplicate of this bug. ***

It can take a lot of track changes until this happens. When I tested it once it were more than 40 track changes. When it happens, it occurs much more often (1 of 5 track changes or similar) until the system is restarted. Since I don't hibernate so often anymore, I have not seen this for weeks. So there are possibly more affected users of phonon-gstreamer, who simply restart their system more often.

(In reply to comment #48)
> Which exact KDE and Amarok versions as well as phonon backend versiion are
> you using?

FWIW, still can happen with kde libs, runtime, etc from trunk (to be 4.12) as also master phonon(-gstreamer).
GStreamer plugins are at 0.10.36, alsa 1.0.27.2, PA 4.0.
Observed with at least FLAC files...

*** Bug 327308 has been marked as a duplicate of this bug. ***

*** Bug 327308 has been marked as a duplicate of this bug. ***

This report is about a rather old version, could you please test with the phonon-backend-gstreamer 4.7.2 and current gstreamer 1.x libraries and plugins and report if this still happens?

*** Bug 320025 has been marked as a duplicate of this bug. ***

Rebuilt phonon from git on Gentoo, bug still exists. Triggered most easily by setting up a playlist with mixed file formats (flac, vorbis, mp3), it's very prone to bug out when switching from one format to another (but not limited to this condition).

Also, if there's a git repository with a version of phonon ported to gstreamer 1.x, I'd like to know, as git://anongit.kde.org/phonon-gstreamer is not.

Amarok Version: 2.8.0
KDE Version: 4.13.3
Qt Version: 4.8.5
Phonon Version: 4.7.50
Phonon Backend: GStreamer (4.7.50)
PulseAudio: Yes

The port is in a branch of that repository, so building master will not help.

I can test quite easily in Kubuntu 14.04 which uses a patched version of that build, sorry if my comment was misleading, seems like other distros do not have those patches yet.

I tested building directly from the 1.0-porting-for-merge branch, as well as the snapshots in ubuntu trusty (4:4.7.1+git20140403-0ubuntu1) and utopic (4:4.7.2+git20140710-0ubuntu1) against both the current git master of phonon (4.7.50) and the last release (4.7.2), and while it builds and links against gstreamer-1.2.4, amarok refuses to play anything, and the test in System Settings -> Multimedia -> Audio and Video Settings crashes, even after rebooting (or running kbuildsycoca4 --noincremental and logging in and out). 

I guess the patches needed to make it work might be in the dependencies of the phonon-backend-gstreamer package, as it carries none by itself in trusty or utopic, but at a glance, the patches against phonon aren't related.

I think there is a misunderstanding on your behalf: if you use Kubuntu, there is no need to build or patch anything, as the version there is already patched, just use Kubuntu 14.04, I have the backports PPA enabled and currently use this configuration (acording to the Amarok Diagnostics):
   Amarok Version: 2.8-git
   KDE Version: 4.13.3
   Qt Version: 4.8.6
   Phonon Version: 4.7.1
   Phonon Backend: GStreamer (4.7.2)
   PulseAudio: Yes

The only thing I build from git is actually Amarok, everything is packages from the distribution, and I can't reproduce this bug at all.

I've just replicated it though it stopped at the start of the track - with play activated
   Amarok Version: 2.8-git
   KDE Version: 4.13.2
   Qt Version: 4.8.6
   Phonon Version: 4.7.1
   Phonon Backend: GStreamer (4.7.2)
   PulseAudio: Yes

In stdout after the comms with lastfm saying the track was nowplaying, there was the message:

QTimeLine::setPaused: Not running

not sure if that's relevant.

The previous track was a flac the stopped one an mp3

Hi Robert,

I don't remember, do you also use Kubuntu 14.04? That is AFAIK the only distribution so far that has the patched gstreamer 1.x support, all others would have to be compiled separately.

Yes I'm using 14.04 (without backports)

Thank you for the fast feedback. Strange I can't reproduce it, and there shouldn't be any changes if I use the backports, as the patched version is in since the 14.04 release.

Hi,

I am experiencing this bug on gentoo with the following:

media-libs/phonon-gstreamer-4.8.0
media-libs/gstreamer-1.2.4
Amarok :Version 2.8.0, Using KDE 4.13.3

Notes: - no pulseaudio in my setup
- phonon-vlc works correctly

I noticed in the debug messages that the computation of the remaining time seems to be wrong. In the example below you can see that after the AboutToFinish call, phonon-gstreamer computes the remaining time using total time - current time. However total time is wrong: in this example the playing track was 3min24s, but total time was set to 268 sec. I could figure out that 268sec. was exactly the total time of the previous track, i.e the one played before the current one. 
My guess is that for some reason total time is not always up to date, and leads to phonon-gstreamer to wait too long after the end of the track (sometimes it restarts after a while but usually after much longer than the advertised "remaining time").

PHONON-GST BEGIN: void Phonon::Gstreamer::MediaObject::handleAboutToFinish() 
PHONON-GST   About to finish 
PHONON-GST   total time 268068 
void Phonon::MediaObjectPrivate::_k_aboutToFinish() 
PHONON-GST   current time 197308 
PHONON-GST   BEGIN: virtual void Phonon::Gstreamer::MediaObject::setNextSource(const Phonon::MediaSource&) 
PHONON-GST     remaining time 70760 
PHONON-GST     waiting for 70260 
PHONON-GST     Got next source. Waiting for end of current.

I'm having this issue with my collection on NFS and using Gstreamer backend.

Amarok Version: 2.8.0
KDE Version: 4.14.9
Qt Version: 4.8.6
Phonon Version: 4.8.3
Phonon Backend: GStreamer (4.8.2)
PulseAudio: Yes

Hello,

I'm lollypop dev (a GNOME audio player) and i can confirm bug with python-gstreamer.

So issue seems to be in gstreamer, not in phonon ;)

Well, changing the backend to the VLC have the same effect. So I believe it's not related with gstreamer or phonon-gstreamer.
I also tried to run amarok inside valgrind but got no crash, so I can't get a proper report. If some dev want to have more data available I'll be glad to help.

I also must add that Amarok gets stuck in track change... and in VLC reading the same files works flawlessly.

(In reply to Paulo Fidalgo from comment #68)
> Well, changing the backend to the VLC have the same effect. So I believe
> it's not related with gstreamer or phonon-gstreamer.
> I also tried to run amarok inside valgrind but got no crash, so I can't get
> a proper report. If some dev want to have more data available I'll be glad
> to help.

Are you sure you really changed the backend? Because you have to restart your KDE session for the change to take effect, and I can't reproduce any track changing problems with that particular backend. And of course you can't reproduce a crash as there is no crash, it's just the playback that is stopping on track change with a different file type. I presume it is related to gstreamer having to switch the plugin, and that doesn't go well.
Also, the problem has been reproduced with the gstreamer libraries directly, so very likely an upstream bug indeed.

Cédric: was there a bug report made to the gstreamer devs and if yes, do you have a link to it?

@Myriam Schweingruber: 
I am sure I'm using VLC backend:

Amarok Version: 2.8.0
KDE Version: 4.14.11
Qt Version: 4.8.6
Phonon Version: 4.8.3
Phonon Backend: VLC (0.8.2)
PulseAudio: No

I even reboot the computer to make sure.
Also the GUI frozes and after playing the first track, it can't play more tracks even in the same format. The only solution is to KILL.

(In reply to Paulo Fidalgo from comment #71)
> @Myriam Schweingruber: 
> I am sure I'm using VLC backend:
> 
> Amarok Version: 2.8.0
> KDE Version: 4.14.11
> Qt Version: 4.8.6
> Phonon Version: 4.8.3
> Phonon Backend: VLC (0.8.2)
> PulseAudio: No
> 
> I even reboot the computer to make sure.
> Also the GUI frozes and after playing the first track, it can't play more
> tracks even in the same format. The only solution is to KILL.

What distribution do you use? You really should use pulseaudio, I wouldn't be astonished if that was the actual problem you have, Phonon is meant to work with pulseaudio ideally, and in most distributions it is default.

I am using Fedora 22 and I am sure I'm using pulseaudio. If I open pavumeter I can see the amarok stream. Using pactl list I get:

Client #39
        Driver: protocol-native.c
        Owner Module: 12
        Properties:
                application.name = "Amarok"
                native-protocol.peer = "UNIX socket client"
                native-protocol.version = "30"
                application.version = "2.8.0"
                application.icon_name = "amarok"
                application.process.id = "11727"
                application.process.user = "fidalgo"
                application.process.host = "hp"
                application.process.binary = "amarok"
                application.language = "en_GB.UTF-8"
                window.x11.display = ":0"
                application.process.machine_id = "e2b16d3a0b364fc79a5d5a28d0a4de6d"
                application.process.session_id = "1"

Client #41
        Driver: protocol-native.c
        Owner Module: 12
        Properties:
                application.name = "Amarok"
                native-protocol.peer = "UNIX socket client"
                native-protocol.version = "30"
                application.id = "org.kde.phonon.amarok"
                application.version = "2.8.0"
                application.icon_name = "amarok"
                application.language = "en_GB.UTF-8"
                application.process.id = "11727"
                application.process.user = "fidalgo"
                application.process.host = "hp"
                application.process.binary = "amarok"
                window.x11.display = ":0"
                application.process.machine_id = "e2b16d3a0b364fc79a5d5a28d0a4de6d"
                application.process.session_id = "1"

Paulo,

if your collection is on NFS it is possible that Amarok hangs because of slow access to the collection. Try this:

Settings -> Configure Amarok -> Local Collection and uncheck "Watch folder for changes".

This should solve the problem of the freeze after the 1st song (or even before, as was my case), but the issue of Amarok hanging on track change is unrelated to this.

(In reply to Paulo Fidalgo from comment #73)
> I am using Fedora 22 and I am sure I'm using pulseaudio. If I open pavumeter
> I can see the amarok stream. Using pactl list I get:
> 
That was just my reaction because in your previous answer you have written you were not using pulseaudio, so at least that can be ruled out. But indeed, if you use an external collection, the problem can indeed be a slow connection rather than a real backend problem.

The connection is on a fast pc (i5 quad-core) with a gigabit connection, so it's really fast. I am not using it now, but if needed I could make a speed test.
Also with VLC everything works as expected!

(In reply to Paulo Fidalgo from comment #76)
> The connection is on a fast pc (i5 quad-core) with a gigabit connection, so
> it's really fast. I am not using it now, but if needed I could make a speed
> test.
> Also with VLC everything works as expected!

You are comparing apples with oranges, there, VLC =! vlc backend, which uses the libvlc library and that definitely doesn't have even half of the features the full blown vlc application has, so , please do not compare what is not comparable!

We would need 2 things: please open a new bug against the vlc backend, and activate Phonon debugging as described here: https://techbase.kde.org/Development/Tutorials/Debugging/Phonon#Environment_Variables ,
then provide an output when the problem happens by starting amarok from the command line with

amarok -d --nofork

we only need about 20-30 lines of that output, so trigger the problem and paste the output directly in the comment (not an attachement, those are not searchable in the database of bugzilla)

(In reply to Myriam Schweingruber from comment #77)
> (In reply to Paulo Fidalgo from comment #76)
> > The connection is on a fast pc (i5 quad-core) with a gigabit connection, so
> > it's really fast. I am not using it now, but if needed I could make a speed
> > test.
> > Also with VLC everything works as expected!
> 
> You are comparing apples with oranges, there, VLC =! vlc backend, which uses
> the libvlc library and that definitely doesn't have even half of the
> features the full blown vlc application has, so , please do not compare what
> is not comparable!
> 
> We would need 2 things: please open a new bug against the vlc backend, and
> activate Phonon debugging as described here:
> https://techbase.kde.org/Development/Tutorials/Debugging/
> Phonon#Environment_Variables ,
> then provide an output when the problem happens by starting amarok from the
> command line with
> 
> amarok -d --nofork
> 
> we only need about 20-30 lines of that output, so trigger the problem and
> paste the output directly in the comment (not an attachement, those are not
> searchable in the database of bugzilla)

I have created a new bug: #354408

This backend for Phonon is no longer maintained or supported, and has not been for quite some time. Please use the VLC backend instead--which is the recommended and maintained replacement--and see if you can reproduce the issue there. If you can, please open a new bug report at https://bugs.kde.org/enter_bug.cgi?product=phonon-backend-vlc.

Thanks a lot!