Debug log of "EngineController not advancing to next track"

[Mark Kretschmann]

On Wed, Feb 11, 2009 at 9:11 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
> On Wednesday 11 February 2009 08:10:31 Mark Kretschmann wrote:
>> amarok: END__: void EngineController::play(const Meta::TrackPtr&,
>> uint) - Took 0.29s
>> amarok: END__: void Playlist::Actions::play(quint64, bool) - Took
>> 0.29s
>> amarok: END__: void EngineController::slotAboutToFinish() - Took 0.35s
>> amarok: BEGIN: void EngineController::slotStateChanged(Phonon::State,
>> Phonon::State)
>> amarok: BEGIN: void EngineSubject::stateChangedNotify(Phonon::State,
>> Phonon::State)
>> amarok: BEGIN: virtual void
>> StatusBar::engineStateChanged(Phonon::State, Phonon::State)
>> amarok: END__: virtual void
>> StatusBar::engineStateChanged(Phonon::State, Phonon::State) - Took
>> 0.00061s
>> amarok: BEGIN: virtual void
>> Amarok::PlayPauseAction::engineStateChanged(Phonon::State,
>> Phonon::State)
>> amarok:        NEWSTATE:  1 OLDSTATE:  2
>> amarok: END__: virtual void
>> Amarok::PlayPauseAction::engineStateChanged(Phonon::State,
>> Phonon::State) - Took 0.00059s
>
>
> About all I can figure from this is that slotAboutToFinish() tells Phonon to
> load up the next track, then the next thing we know is that Phonon is
> notifying us of a state change from playing (2) to stopped (1).
>
> Also possibly interesting is that the last phonon state mentioned in the debug
> output is loading (0).  There is no indication that we moved from loading to
> playing.  The only state changes we ignore are when oldstate == newstate, or
> when newstate is buffering.

So, Dan Meltzer and I kinda came up with an idea that could (?) fix
the whole mess. First, what we noticed is this: Once Amarok gets into
this "wonky" state, it'll stay that way until you restart it.
Considering that, it could mean that some part of Phonon goes mental.

Now the idea: We somehow try to detect this mental state (a timer that
checks if tracks get played for <1s?), then call a "rescue" method
that tries to destroy the MediaObject and maybe also the MediaOutput
object from Phonon, and re-instantiates them. This should be pretty
much transparent to the user.

Maybe, just maybe, if we are lucky, that could fix this problem here,
and also the even worse bugs with xinelib 1.1.16
(http://bugs.kde.org/show_bug.cgi?id=180339).

I might try to implement this during the next days or so, or if
someone beats me to it, then go ahead, but please announce it first to
prevent duplicate work.

-- 
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org