Bug 110921

Works for me. Does it make any difference what engine you are using? What does "after a while" mean?
Thanks.

First i start amarok remotely on a laptop forwarding the display to a desktop system i work with.
Secondly i wrote a wrapper script which greps for "Very" on stderr which kills the amarok and the amarokapp process and then restarts amarok. This was the only possibility to hear music more than a hour or minutes.
Remember the error message is "Very strange! got a DCOPReply.."

I never figured out why these DCOPreply errors ocurred. Maybe it's related with the forwarded display, never get the errors with amarok running locally.
I only know that these errors came then amarok changes the track.
Without the wrapper script, after the error came, the mousepointer changes to a arrow-clock cursor. After a while amarok freezes. The freezes come immediatly on starting konqueror with the musicbrainz link or going into the coveradministration.
To make this thing more complicated, as i started amarok yesterday by hand without the wrapperscript to look at the exact errormessage, the error never came! But i didn't test for long.
I tried the engines arts, gstreamer and xine. No effect.

So does avoiding music without &'s not help? I'm confused.

No.
I'm confused too 8o  Will test and observe more.

OK, here is what happened.
I start amarok and everything runs fine except for the messages below.

--
$ amarok
amaroK: [Loader] Starting amarokapp..
amaroK: [Loader] Don't run gdb, valgrind, etc. against this binary! Use amarokapp.
QObject::connect: Cannot connect Engine::Base::statusText( const QString& ) to (null)::shortMessage( const QString& )
QObject::connect: Cannot connect Engine::Base::infoMessage( const QString& ) to (null)::longMessage( const QString& )
QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for PlaylistWindow/PlaylistWindow
--

This DCOPError only appears when changing tracks, so i change manually tracks.
Nothing happens, tracks change happily. I let amarok running, i'm not sure how long, approx. an hour.

Then changing tracks and:

--
18:08:16^mhe@positron:~
$ Very strange! got a DCOPReply opcode, but we were not waiting for a reply!
--

The clockcursor appears and disappears. On 1.2 the clockcursor stays. Amarok didn't freeze like in 1.2. But the contextinfos of the current song didn't change anymore.
After three hours amarok freezes. 

--
Launched ok, pid = 7450
QObject::connect: Cannot connect QSignal::signal(const QVariant&) to (null)::(null)
QObject::connect: Cannot connect QSignal::signal(const QVariant&) to (null)::(null)
QObject::connect: Cannot connect QSignal::signal(const QVariant&) to (null)::(null)
--

a backtrace is mailed automatically to amarok...sf.net after i hit ctrl-c in the
terminal where i started amarok.

Maybe i found some more patterns the next days.

Another test:

starting amarok from commandline remotely over a telnet session

--------------
$ amarok
amaroK: [Loader] Starting amarokapp..
amaroK: [Loader] Don't run gdb, valgrind, etc. against this binary! Use amarokapp.
QObject::connect: Cannot connect Engine::Base::statusText( const QString& ) to (null)::shortMessage( const QString& )
QObject::connect: Cannot connect Engine::Base::infoMessage( const QString& ) to (null)::longMessage( const QString& )
QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for PlaylistWindow/PlaylistWindow
------------

after the first track:

------------
18:02:22^mhe@positron:~
$ Very strange! got a DCOPReply opcode, but we were not waiting for a reply!
------------

the mousecursor stays as an arrow with clock
the trackinfo on the left stays at the last song and never updates.

I let amarok running after the DCOP error described in my last comment. A couple
of tracks later after clicking on the icon to erase the playlist, amarok freezes.
 

Looks like the errors came only when the album cover changes.

What does "got a DCOPReply opcode, but we were not waiting for a reply" mean?
And why amarok turns mad on it?

Strangely it doesn't happen on another laptop, same KDE version and amarok.

I currently tested if it has something to do that i start amarok remotely.
No, this DCOPReply thingie also happens when amarok is started locally.

When a "got a DCOPReply opcode.." occurs and i quit amarok this is the last
output

WARNING: DCOPReply<bool>: cast to 'QString' error

This is a similar 'bug', with solution

http://bugs.kde.org/show_bug.cgi?id=98801

Solution:

CVS commit by vkrause:

Prevent wallet operations from the network thread, this causes the thread to hang.
...

As this bug happens when tracks change and a change causes some net operations
i suppose something similar here(?)
It's curious why it happens only here on my laptop.

In an amarok session this "got a DCOPReply opcode.." warning happens only once, and never again. Until then the current cover remains and the mousecursor shows 'busy'. This indicates that something hangs as vkrause writes in the comment above.

Playing podcasts gives

Very strange! got a DCOPReply opcode, but we were not waiting for a reply!

Mousecursor shows busy and after clicking on e.g. Text in the context amarok crashes with

(process:30250): GStreamer-CRITICAL **: gst_buffer_create_sub: assertion `size > 0' failed
kio (KIOConnection): ERROR: Could not write data

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

Problem seems to be not related to the &, since we can't reproduce

Are you using a Pentium 4 with HyperThreading enabled?

No, it's a Pentium III (Coppermine)

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

DCOPError because of proxy!
Finally found the cause of the DCOPError. If i switch off the proxysupport
in the KDE-settings everything runs fine.
The error can be reproduced when switching on proxy and cycle manually through some tracks.
Hope this helps the developers.

*** This bug has been marked as a duplicate of 112437 ***