Bug 192114 - Playback stops after every track if error had occurred earlier
Summary: Playback stops after every track if error had occurred earlier
Status: RESOLVED FIXED
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: Xine backend (show other bugs)
Version: 4.3.1 (KDE 4.4)
Platform: openSUSE Linux
: HI normal
Target Milestone: ---
Assignee: Matthias Kretz
URL:
Keywords:
: 194255 195937 208361 209789 211909 217046 221731 222559 222591 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-09 11:41 UTC by Jan Holthuis
Modified: 2010-12-05 21:41 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.4.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Holthuis 2009-05-09 11:41:56 UTC
Version:           2.0.90 (using KDE 4.2.2)
OS:                Linux
Installed from:    SuSE RPMs

If playlist errors occured (e.g. because you have your collection on an external, currently unmounted HDD) and you fix the problem, the playback will stop anyway after every single track.

It's noticable, that the playlist moves on to the next track (it's highlighed), scrobbles it, but doesn't play.

To solve that, you currently have to shut down amarok and start it again. If the playlist hasn't been stopped because of errors, amarok works perfectly.

Steps to reproduce:
1. Unmount the partition with your local collection
2. Drag some tracks from the collection browser to your playlist
3. Playback will not work (of course), a »playback has been stopped«-message will appear
4. mount the parition with your local partition
5. start playback. The first song will play fine, but after every single track, playback will stop.
Comment 1 Mark Kretschmann 2009-05-29 12:06:09 UTC
Yep, I've experienced this a few days ago. We might be forgetting to reset the error counter variable, or something to that effect.

Gotta investigate this for 2.1.1.
Comment 2 Myriam Schweingruber 2009-07-01 18:28:39 UTC
*** Bug 194255 has been marked as a duplicate of this bug. ***
Comment 3 Stephen Baker 2009-07-02 14:27:32 UTC
This does sound more like my issue, my music is on an external drive that I usually mount after starting Amarok.
Comment 4 Myriam Schweingruber 2009-07-08 13:29:58 UTC
Still present in 2.2-SVN. Anyone?
Comment 5 Myriam Schweingruber 2009-07-10 18:47:36 UTC

*** This bug has been marked as a duplicate of bug 191199 ***
Comment 6 Myriam Schweingruber 2009-08-20 15:38:07 UTC
Ouch, this is indeed quite wrong, must have mistyped the bug number of the duplicate, sorry for that.
Comment 7 Myriam Schweingruber 2009-08-20 15:40:10 UTC
*** Bug 195937 has been marked as a duplicate of this bug. ***
Comment 8 Niels Woo-Sang Kjærsgaard 2009-08-28 10:45:45 UTC
This also happens when playing a Last.fm radio.
Comment 9 Lydia Pintscher 2009-09-09 15:08:26 UTC
Leo: any idea? Or do you know who could look into this?
Comment 10 Oren Held 2009-09-22 10:23:51 UTC
This also happens simply after trying to play files from a remote server (daap) which do not exist anymore. Only after restarting amarok the behavior gets back to normal.

An additional symptom is that the pause button stops functioning as "pause", but starts to re-play the track from the start.

Tested on Debian/Amarok v2.1.1, but I assume it's still relevant on the devel tree, because this bug is still open.
Comment 11 Oren Held 2009-09-23 15:36:26 UTC
Confirming on 2.2~rc1 / 2.1.90
Comment 12 alx 2009-09-24 10:31:26 UTC
the same problems on my debian squeezee. But remounting of samba filesystem (where i listen my music from) and relaunching of amarok hasn't fixed this bug. But if i launch amarok under Root user it works correctly. So it seems to fix this bug temporary i should clear some user configurational files. I haven't noticed a key after which bug had arouse :-(
Hope bug will be fix soon.
Comment 13 Oren Held 2009-09-24 22:25:10 UTC
It seems to me that after state becomes ErrorState (debug message amarok:   [EngineController] [WARNING!] Phonon failed to play this URL. Error:  ""), the m_media->state() stays wrong even after starting to play.

thus even when trying to play the next truck, m_media->state() is 0 (LoadState?) and thus playPause() decides to play instead of pause, upon click on the pause button.
Comment 14 Myriam Schweingruber 2009-09-25 13:26:15 UTC
Hm, so this looks like a phonon problem then, Martin?
Comment 15 Myriam Schweingruber 2009-10-26 10:54:22 UTC
*** Bug 211909 has been marked as a duplicate of this bug. ***
Comment 16 Myriam Schweingruber 2009-10-26 10:54:53 UTC
void
Playlist::Actions::engineStateChanged( Phonon::State currentState, Phonon::State )
{
    static int failures = 0;
    const int maxFailures = 10;

    if ( currentState == Phonon::ErrorState )
    {
        failures++;
        warning() << "Error, can not play this track.";
        warning() << "Failure count: " << failures;
        if ( failures >= maxFailures )
        {
            The::statusBar()->longMessage( i18n( "Too many errors encountered in playlist. Playback stopped." ), StatusBar::Warning );
            error() << "Stopping playlist.";
            failures = 0;
            m_trackError = true;
        }
    }
    else if ( currentState == Phonon::PlayingState )
    {
        if ( failures > 0 )
        {
            debug() << "Successfully played track. Resetting failure count.";
        }
        failures = 0;
        m_trackError = false;
    }
}
Comment 17 Beat Wolf 2009-10-27 12:03:31 UTC
I now saw that it also happens if there is only a single error. amarok will jump to the next song that works, play it, but from now on it won't start the next track.
Comment 18 Mark Kretschmann 2009-10-27 13:53:28 UTC
I'm starting to wonder if this bug could be related to BUG 201233
Comment 19 Mark Kretschmann 2009-11-01 11:34:48 UTC
I've committed some patches to git master. Anyone up for some testing?
Comment 20 Myriam Schweingruber 2009-11-11 10:22:33 UTC
*** Bug 209789 has been marked as a duplicate of this bug. ***
Comment 21 Myriam Schweingruber 2009-11-16 14:01:23 UTC
Is this still valid with Amarok 2.2.1?
Comment 22 Beat Wolf 2009-11-16 15:55:14 UTC
i'll try as soon as amarok 2.1.1 is officialy out (with packages for kubuntu)
Comment 23 Murz 2009-11-22 10:50:28 UTC
Same problem appear for me on Kubuntu Karmic with Amarok Version 2.2.1 Using KDE 4.3.3.
It stops playing after every track if before I try to play streams that fail to load.
Repeat is set to "Playlist", Random to "Tracks".
Comment 24 Murz 2009-11-22 10:52:33 UTC
This bug is shows up for me after upgrading from 2.2.0 to 2.2.1 via ppa (and
upgrade KDE from 4.3.2 to 4.3.3).
Comment 25 Beat Wolf 2009-11-22 12:32:42 UTC
this is still valid for 2.2.1
Comment 26 Myriam Schweingruber 2009-11-22 12:32:45 UTC
Thanks for confirmation.
Comment 27 Jithin Emmanuel 2009-12-01 10:45:32 UTC
I am noticing this for 2.2.1. It switches to next track and stops. It even displays the OSD for the next track. Highly annoying I have change each track manually.

After amarok it seems to work. But don't know at what point it goes back to this erroneous behavior.
Comment 28 Beat Wolf 2009-12-01 10:50:18 UTC
as soon as one track had an error (could not be found, wrong format, whatever).
Comment 29 Mark Kretschmann 2009-12-01 11:58:46 UTC
Hmm ok, I think we should probably fix this before 2.2.2 release.

Getting it right might only be a one-liner change, but finding the logic error is another matter. Any help with debugging is appreciated :)


PS: Marking as "release_blocker", so that we won't forget.
Comment 30 Jithin Emmanuel 2009-12-01 14:05:06 UTC
I found a way to trigger it when "Show only matches" is ticked in playlist options and search for a song/album. Once the song is done playing the remainig songs in the list is not played.
Comment 31 alex 2009-12-02 13:14:05 UTC
I have same issue as Jithin, occurs when 'Show only matches' is on and filter in the playlist.

See https://bugs.kde.org/show_bug.cgi?id=217046 for issue I reported.
Comment 32 Myriam Schweingruber 2009-12-02 14:16:06 UTC
*** Bug 217046 has been marked as a duplicate of this bug. ***
Comment 33 Mark Kretschmann 2009-12-03 10:13:43 UTC
@Jithin: I tried to reproduce it exactly like you said, with latest 2.2-GIT. 

I couldn't reproduce. Amarok moved to the next track automatically.
Comment 34 Mark Kretschmann 2009-12-03 10:41:43 UTC
OK, I was able to reproduce the problem, doing it this way:

1) Loaded music into current playlist
2) While playing, deleted one file
3) When Amarok tried to play this, it actually crashed


The backtrace was useless, but I have some debug output:

amarok: END__: virtual VideoclipEngine::~VideoclipEngine() - Took 3.8e-05s
amarok: BEGIN: virtual ContextObserver::~ContextObserver()
amarok: BEGIN: void ContextSubject::detach(ContextObserver*)
amarok: END__: void ContextSubject::detach(ContextObserver*) - Took 2.5e-05s
amarok: END__: virtual ContextObserver::~ContextObserver() - Took 6.8e-05s

[1]+  Stopped                 amarok -m -d --nofork
Comment 35 Mark Kretschmann 2009-12-03 11:21:57 UTC
Got a new backtrace, and some debug output:

DEBUG:

amarok: END__: void VideoclipEngine::resultFinalize() - Took 0.0011s
amarok: BEGIN: void VideoclipApplet::dataUpdated(const QString&, const QHash<QString, QVariant>&)
amarok: END__: void VideoclipApplet::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.17s
KCrash: Application 'amarok' crashing...


BACKTRACE:

Application: Amarok (amarok), signal: Segmentation fault
pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
The current source language is "auto; currently asm".
[Current thread is 1 (Thread 0x7fd4386777a0 (LWP 15545))]

Thread 11 (Thread 0x7fd420d6c910 (LWP 15546)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:220
#1  0x00007fd426a21c91 in ?? () from /usr/lib/libxine.so.1
#2  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#3  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 10 (Thread 0x7fd41f823910 (LWP 15547)):
[KCrash Handler]
#5  __pthread_mutex_lock (mutex=0x2c8) at pthread_mutex_lock.c:50
#6  0x00007fd426a1e921 in xine_close () from /usr/lib/libxine.so.1
#7  0x00007fd426c881d7 in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#8  0x00007fd426c8a153 in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#9  0x00007fd43650cefc in QApplicationPrivate::notify_helper (this=0x576860, receiver=0x620e00, e=0x61a98b0) at kernel/qapplication.cpp:4056
#10 0x00007fd4365141ce in QApplication::notify (this=0x7fff56d769a0, receiver=0x620e00, e=0x61a98b0) at kernel/qapplication.cpp:4021
#11 0x00007fd4381f9e56 in KApplication::notify (this=0x7fff56d769a0, receiver=0x620e00, event=0x61a98b0) at ../../kdeui/kernel/kapplication.cpp:302
#12 0x00007fd435977c2c in QCoreApplication::notifyInternal (this=0x7fff56d769a0, receiver=0x620e00, event=0x61a98b0) at kernel/qcoreapplication.cpp:610
#13 0x00007fd43597880a in QCoreApplication::sendEvent (receiver=0x0, event_type=<value optimized out>, data=0x615480) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213
#14 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=<value optimized out>, data=0x615480) at kernel/qcoreapplication.cpp:1247
#15 0x00007fd4359a0533 in QCoreApplication::sendPostedEvents (s=<value optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:218
#16 postEventSourceDispatch (s=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:210
#17 0x00007fd42df2fbbe in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#18 0x00007fd42df33588 in ?? () from /lib/libglib-2.0.so.0
#19 0x00007fd42df336b0 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#20 0x00007fd4359a01a6 in QEventDispatcherGlib::processEvents (this=0x615280, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327
#21 0x00007fd435976532 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149
#22 0x00007fd435976904 in QEventLoop::exec (this=0x7fd41f822fb0, flags=) at kernel/qeventloop.cpp:201
#23 0x00007fd43588e6cb in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:487
#24 0x00007fd426c7c56e in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#25 0x00007fd435891445 in QThreadPrivate::start (arg=0x637c00) at thread/qthread_unix.cpp:188
#26 0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#27 0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#28 0x0000000000000000 in ?? ()

Thread 9 (Thread 0x7fd41ec11910 (LWP 15553)):
#0  0x00007fd434dec373 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=333) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007fd41ee1ecbe in ?? () from /usr/lib/xine/plugins/1.26/xineplug_ao_out_alsa.so
#2  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#3  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()
The current source language is "auto; currently c".

Thread 8 (Thread 0x7fd41e20a910 (LWP 15554)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd426a32983 in ?? () from /usr/lib/libxine.so.1
#2  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#3  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7fd41da09910 (LWP 15555)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd426a32983 in ?? () from /usr/lib/libxine.so.1
#2  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#3  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()
The current source language is "auto; currently asm".

Thread 6 (Thread 0x7fd417c78910 (LWP 15557)):
#0  0x00007fd434df13c2 in select () from /lib/libc.so.6
#1  0x00007fd426a4a725 in xine_usec_sleep () from /usr/lib/libxine.so.1
#2  0x00007fd426a2f7e9 in ?? () from /usr/lib/libxine.so.1
#3  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#4  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7fd40f700910 (LWP 15558)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd4358924fb in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159
#3  0x00007fd4327f7326 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0xfef8a0, th=0x17934f0) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#4  0x00007fd4327f945b in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#5  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#6  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#7  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#9  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17934f0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#10 0x00007fd4327f7a5f in ThreadWeaver::ThreadRunHelper::run (this=0x7fd40f700000, parent=0xfef8a0, th=0x17934f0) at ../../../threadweaver/Weaver/Thread.cpp:87
#11 0x00007fd4327f7eb8 in ThreadWeaver::Thread::run (this=0x17934f0) at ../../../threadweaver/Weaver/Thread.cpp:142
#12 0x00007fd435891445 in QThreadPrivate::start (arg=0x17934f0) at thread/qthread_unix.cpp:188
#13 0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#14 0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()
The current source language is "auto; currently c".

Thread 4 (Thread 0x7fd40eeff910 (LWP 15559)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd4358924fb in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159
#3  0x00007fd4327f7326 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0xfef8a0, th=0x1773b70) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#4  0x00007fd4327f945b in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x1773b70) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#5  0x00007fd4327f7a5f in ThreadWeaver::ThreadRunHelper::run (this=0x7fd40eeff000, parent=0xfef8a0, th=0x1773b70) at ../../../threadweaver/Weaver/Thread.cpp:87
#6  0x00007fd4327f7eb8 in ThreadWeaver::Thread::run (this=0x1773b70) at ../../../threadweaver/Weaver/Thread.cpp:142
#7  0x00007fd435891445 in QThreadPrivate::start (arg=0x1773b70) at thread/qthread_unix.cpp:188
#8  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#9  0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
The current source language is "auto; currently asm".

Thread 3 (Thread 0x7fd40b9ba910 (LWP 15560)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd4358924fb in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159
#3  0x00007fd4327f7326 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0xfef8a0, th=0x17335e0) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#4  0x00007fd4327f945b in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17335e0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#5  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17335e0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#6  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17335e0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#7  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17335e0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0x17335e0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#9  0x00007fd4327f7a5f in ThreadWeaver::ThreadRunHelper::run (this=0x7fd40b9ba000, parent=0xfef8a0, th=0x17335e0) at ../../../threadweaver/Weaver/Thread.cpp:87
#10 0x00007fd4327f7eb8 in ThreadWeaver::Thread::run (this=0x17335e0) at ../../../threadweaver/Weaver/Thread.cpp:142
#11 0x00007fd435891445 in QThreadPrivate::start (arg=0x17335e0) at thread/qthread_unix.cpp:188
#12 0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#13 0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fd3f872e910 (LWP 15576)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd4358924fb in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x17b2690, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159
#3  0x00007fd4327f7326 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0xfef8a0, th=0xe92560) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#4  0x00007fd4327f945b in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0xe92560) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#5  0x00007fd4327f9474 in ThreadWeaver::WorkingHardState::applyForWork (this=0xc3b280, th=0xe92560) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74
#6  0x00007fd4327f7a5f in ThreadWeaver::ThreadRunHelper::run (this=0x7fd3f872e000, parent=0xfef8a0, th=0xe92560) at ../../../threadweaver/Weaver/Thread.cpp:87
#7  0x00007fd4327f7eb8 in ThreadWeaver::Thread::run (this=0xe92560) at ../../../threadweaver/Weaver/Thread.cpp:142
#8  0x00007fd435891445 in QThreadPrivate::start (arg=0xe92560) at thread/qthread_unix.cpp:188
#9  0x00007fd42fd32a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300
#10 0x00007fd434df87bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fd4386777a0 (LWP 15545)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fd435890c93 in QMutexPrivate::wait (this=0x6cb750, timeout=-1) at thread/qmutex_unix.cpp:80
#2  0x00007fd43588c865 in QMutex::lock (this=0x620e78) at thread/qmutex.cpp:207
#3  0x00007fd426c81137 in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#4  0x00007fd426c94ed6 in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#5  0x00007fd43213f0b4 in Phonon::MediaNodePrivate::deleteBackendObject (this=0x5747e0) at ../3rdparty/phonon/phonon/medianode.cpp:81
#6  0x00007fd43214dcc5 in ~FactoryPrivate (this=0x574530, __in_chrg=<value optimized out>) at ../3rdparty/phonon/phonon/factory.cpp:193
#7  0x00007fd434d51c12 in __run_exit_handlers (status=1) at exit.c:78
#8  *__GI_exit (status=1) at exit.c:100
#9  0x00007fd436568328 in qt_xio_errhandler () at kernel/qapplication_x11.cpp:707
#10 0x00007fd4381f9838 in KApplication::xioErrhandler (this=0x7fff56d769a0, dpy=0x593c60) at ../../kdeui/kernel/kapplication.cpp:408
#11 0x00007fd434600fae in _XIOError () from /usr/lib/libX11.so.6
#12 0x00007fd4346089a5 in ?? () from /usr/lib/libX11.so.6
#13 0x00007fd434609257 in _XEventsQueued () from /usr/lib/libX11.so.6
#14 0x00007fd4345f201b in XEventsQueued () from /usr/lib/libX11.so.6
#15 0x00007fd4365a167c in x11EventSourceCheck (s=0x56ecd0) at kernel/qguieventdispatcher_glib.cpp:87
#16 0x00007fd42df32a9a in g_main_context_check () from /lib/libglib-2.0.so.0
#17 0x00007fd42df33280 in ?? () from /lib/libglib-2.0.so.0
#18 0x00007fd42df336b0 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#19 0x00007fd4359a01a6 in QEventDispatcherGlib::processEvents (this=0x429770, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327
#20 0x00007fd4365a14be in QGuiEventDispatcherGlib::processEvents (this=0x6cb79c, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202
#21 0x00007fd435976532 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149
#22 0x00007fd435976904 in QEventLoop::exec (this=0x7fff56d76940, flags=) at kernel/qeventloop.cpp:201
#23 0x00007fd435978ab9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#24 0x00000000004098aa in main (argc=4, argv=0x7fff56d788a8) at /home/mark/kde/src/amarok/src/main.cpp:235
Comment 36 Mark Kretschmann 2009-12-04 10:49:16 UTC
Looking at the backtrace again, I'm starting to suspect that it could involve a Phonon-Xine issue too.

This here: 

#6  0x00007fd426a1e921 in xine_close () from /usr/lib/libxine.so.1
#7  0x00007fd426c881d7 in ?? () from
/usr/lib/qt4/plugins/phonon_backend/phonon_xine.so


Sandsmark, what do you think?
Comment 37 Mark Kretschmann 2009-12-10 11:44:14 UTC
After some discussion with other Amarok devs, we came to the conclusion that this is very likely a xine bug (the crash happens in xine).

I'm going to reassign this to Phonon for now, and then Martin Sandsmark (Phonon maintainer) can decide if it could be worked around in Phonon, or not.
Comment 38 Myriam Schweingruber 2009-12-17 23:54:48 UTC
*** Bug 208361 has been marked as a duplicate of this bug. ***
Comment 39 alex 2009-12-27 15:45:44 UTC
Is there anywhere we can keep track of the Xine bug, or more details on this? It's quite a big bug for me and interested on knowing the status, as I love listening to just 1 album or artist sometimes (and annoying to change playlist all the time)
Comment 40 Myriam Schweingruber 2010-01-09 09:02:21 UTC
*** Bug 221731 has been marked as a duplicate of this bug. ***
Comment 41 Myriam Schweingruber 2010-01-13 21:37:21 UTC
*** Bug 222559 has been marked as a duplicate of this bug. ***
Comment 42 Myriam Schweingruber 2010-01-13 21:41:52 UTC
(In reply to comment #39)
> Is there anywhere we can keep track of the Xine bug, or more details on this?
> It's quite a big bug for me and interested on knowing the status, as I love
> listening to just 1 album or artist sometimes (and annoying to change playlist
> all the time)

Well, you are subscribed to it, so you should get notifications when something changes.

With the latest Phonon in  KDE 4.4 beta I can't reproduce a crash, changing severity.
Comment 43 Myriam Schweingruber 2010-01-13 22:23:18 UTC
*** Bug 222591 has been marked as a duplicate of this bug. ***
Comment 44 Myriam Schweingruber 2010-01-26 19:40:14 UTC
Can somebody reproduce this with the latest xine backend? This seems to be solved with version 4.3.80-5 in Fedora
Comment 45 Clint Silvester 2010-01-26 19:57:44 UTC
I'm on 4.3.80-3.1 of the phonon-backend-xine in Opensuse 11.2 and can't reproduce this anymore.
Comment 46 Murz 2010-01-26 20:03:54 UTC
Can't reproduce on 4.4 RC2 too.
Comment 47 Clint Silvester 2010-01-26 20:23:47 UTC
I'm still on 2.2.1 of Amarok, too, btw.
Comment 48 Myriam Schweingruber 2010-01-26 22:53:26 UTC
Great news! Thank you all for the fast feedback, I close this as solved :)
Comment 49 MHildebrandt 2010-03-25 09:58:55 UTC
Sotty, but the problem still exists for me using OpenSuse 11.2 and Amarok 2.3.

Also I can't move the time slider.
Comment 50 Mathias Panzenböck 2010-03-25 11:49:57 UTC
I forgot to mention: This also happened to me once since the bug was closes (which is awfully less often than it used to be, but still).
Comment 51 Valorie Zimmerman 2010-05-17 11:00:42 UTC
I'm sorry to report that this is still happening in 2.3-GIT, built right now, with an up-to-date phonon-vlc backend. I found it necessary to use PulseAudio in my Lucid fresh Kubuntu install, to cure sound stuttering in most applications. The output I get before Amarok stops playing:

[0x7f1b88033d08] ogg demux debug: end of a group of logical streams
[0x7f1b88033d08] ogg demux warning: couldn't find any ogg logical stream
[0x23d7508] main input debug: EOF reached
stateChangedInternal newState: "StoppedState" previousState: "PlayingState" 
amarok: BEGIN: void EngineController::slotStateChanged(Phonon::State, Phonon::State) 
amarok:   BEGIN: void Engine::EngineSubject::stateChangedNotify(Phonon::State, Phonon::State) 
amarok:      State changed, oldState: 2 -> newState: 1 
[0x7f1b88d97238] main decoder debug: removing module "vorbis"
[0x7f1b88d97238] main decoder debug: killing decoder fourcc `vorb', 0 PES in FIFO
[0x7f1b64007a58] main audio filter debug: removing module "scaletempo"
[0x7f1b64009068] main audio filter debug: removing module "bandlimited_resampler"
[0x30056c8] pulse audio output debug: Pulse Close
amarok:      returning bookmarkcurrenttrack action 
[0x30056c8] main audio output debug: removing module "pulse"
[0x7f1b64006878] main generic debug: removing module "float32_mixer"
[0x23d7508] main input debug: releasing aout
[0x23d7508] main input debug: Program doesn't contain anymore ES
[0x7f1b88033d08] main demux debug: removing module "ogg"
[0x7f1b88033b08] main stream debug: removing module "stream_filter_record"
[0x7f1b881459c8] main access debug: removing module "filesystem"
[0x23d7508] main input debug: thread ended
amarok:   END__: void Engine::EngineSubject::stateChangedNotify(Phonon::State, Phonon::State) - Took 0.013s 
amarok: END__: void EngineController::slotStateChanged(Phonon::State, Phonon::State) - Took 0.013s 
amarok: BEGIN: void EngineController::slotQueueEnded() 
stateChangedInternal newState: "StoppedState" previousState: "StoppedState" 
setSource 
setSource Error: MediaSource is empty. 
amarok:   BEGIN: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) 
amarok:     [EngineController] Empty MediaSource (engine stop) 
amarok:   END__: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) - Took 0.00011s 
amarok:   BEGIN: virtual void Context::ContextView::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) 
amarok:     BEGIN: virtual void CurrentEngine::message(const Context::ContextState&) 
amarok:     END__: virtual void CurrentEngine::message(const Context::ContextState&) - Took 8.9e-05s 
amarok:     BEGIN: virtual void LyricsEngine::message(const Context::ContextState&) 
amarok:     END__: virtual void LyricsEngine::message(const Context::ContextState&) - Took 0.00014s 
amarok:   END__: virtual void Context::ContextView::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) - Took 0.00039s 
amarok:   BEGIN: virtual void ProgressWidget::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) 
amarok:     BEGIN: void Amarok::TimeSlider::clearTriangles() 
amarok:        number of triangles:  0 
amarok:        deleted them all... 
amarok:     END__: void Amarok::TimeSlider::clearTriangles() - Took 8.1e-05s 
amarok:   END__: virtual void ProgressWidget::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) - Took 0.00023s 
amarok:   BEGIN: virtual void TimecodeObserver::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) 
amarok:   END__: virtual void TimecodeObserver::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) - Took 4.1e-05s 
amarok:   BEGIN: virtual void ScrobblerAdapter::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) 
amarok:     BEGIN: void ScrobblerAdapter::checkScrobble() 
amarok:       [lastfm] total played 84531 duration 42000 isNull false submit? true 
amarok:       [lastfm] scrobble:  "Johann Sebastian Bach"  -  "The Works for Organ Volume 2, feat. Kevin Bowyer, Organ"  -  "Gelobet siest du, Jesu Christ BWV 722" 
amarok(7343) KNetworkAccessManager::createRequest: PostOperation:  QUrl( "http://post2.audioscrobbler.com:80/protocol_1.2" )
HTTP POST:  QUrl( "http://post2.audioscrobbler.com:80/protocol_1.2" )  "s=403c9c4c44634a539bd0705a4fdfdad9&a[0]=Johann%20Sebastian%20Bach&t[0]=Gelobet%20siest%20du%2C%20Jesu%20Christ%20BWV%20722&i[0]=1274086365&o[0]=P&r[0]=&l[0]=84&b[0]=The%20Works%20for%20Organ%20Volume%202%2C%20feat.%20Kevin%20Bowyer%2C%20Organ&n[0]=0&m[0]=" 
amarok:     END__: void ScrobblerAdapter::checkScrobble() - Took 0.0012s 
amarok:   END__: virtual void ScrobblerAdapter::enginePlaybackEnded(qint64, qint64, Engine::EngineObserver::PlaybackEndedReason) - Took 0.0013s 
amarok: END__: void EngineController::slotQueueEnded() - Took 0.011s 
amarok(7343) KNetworkReply::setMimeType: "text/plain"
"OK" 
amarok: BEGIN: void CurrentEngine::stoppedState() 
amarok: END__: void CurrentEngine::stoppedState() - Took 0.0015s 
amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) 
amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.00072s 
amarok: BEGIN: void CurrentEngine::resultReady(const QString&, const Meta::TrackList&) 
amarok: END__: void CurrentEngine::resultReady(const QString&, const Meta::TrackList&) - Took 0.00037s 
amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) 
amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.00053s 
amarok:  painting action:  "" 
amarok:  painting action:  "" 

Sometimes Amarok will play 10 or so tracks in a row, but lately, it's mostly onesies. Really quite annoying. Oh, I do have KDE 4.4.3, but Amarok reports that is is using 4.4.2.
Comment 52 Myriam Schweingruber 2010-05-17 23:31:21 UTC
Valorie, it works perfectly well without Pulseaudio here in Kubuntu 10.04, be this with the xine or the VLC backend. I can assure you, you do *not* need pulseaudio in 10.04, unless you are using Gnome.

This is not a phonon bug, but your setup.
Comment 53 Richard Longland 2010-05-24 22:10:40 UTC
Sorry, but I also get this problem. Is it a phonon-vlc bug? I'm using Amarok 2.3-GIT with phonon-vlc. I tried xine for an hour or so with no problems...

Here is what happens at the track change:
[0xb7c4f18] ogg demux debug: end of a group of logical streams
[0xb7c4f18] ogg demux warning: couldn't find any ogg logical stream
[0xbb82590] main input debug: EOF reached
[0xb6c4840] main decoder debug: removing module "vorbis"
[0xb6c4840] main decoder debug: killing decoder fourcc `vorb', 0 PES in FIFO
[0x9cf26de8] main audio filter debug: removing module "scaletempo"
[0xa05ee1d0] main audio filter debug: removing module "bandlimited_resampler"
[0xb4ff3350] main audio output debug: removing module "alsa"
[0xa05b3728] main generic debug: removing module "float32_mixer"
[0xbb82590] main input debug: releasing aout
[0xbb82590] main input debug: Program doesn't contain anymore ES
[0xb7c4f18] main demux debug: removing module "ogg"
[0xb997390] main stream debug: removing module "stream_filter_record"
[0xb22aad8] main access debug: removing module "filesystem"
[0xbb82590] main input debug: thread ended
stateChangedInternal newState: "StoppedState" previousState: "PlayingState" 
stateChangedInternal newState: "StoppedState" previousState: "StoppedState" 
setSource 
setSource Error: MediaSource is empty.
Comment 54 Myriam Schweingruber 2010-05-25 10:47:02 UTC
(In reply to comment #53)
> Sorry, but I also get this problem. Is it a phonon-vlc bug? I'm using Amarok
> 2.3-GIT with phonon-vlc. I tried xine for an hour or so with no problems...

Please file a new bug for the phonon VLC backend, then. This report is about the xine backend.