[SOLVED]Amarok, Wherefore Art Thou???

[jglen490]

Re: [SOLVED]Amarok, Wherefore Art Thou

If Amarok is working for someone, that's great -- I still think it is a wonderful product. I agree that there could be QA problems, in software they usually show up as inconsistent results, and simple fact that my hardware platform is pretty old could contribute also.

I'll try again sometime, probably with 10.04, but until then Linux rules because there are many solutions available 8).

[GreyGeek]

Re: [SOLVED]Amarok, Wherefore Art Thou

......
That still doesn't explain why Amarok is so buggy, they have had nearly two years now to restore the features in 1.4.10. It can't be that hard surely, am I missing something here?

Amarok 2.2.1 on my 64b KK wouldn't run from the menu or off of an icon. It would bounce the icon for a few seconds a go away. I ran it from a konsole to see what error msgs it was putting out:

QObject: Cannot create children for a parent that is in a different thread.
(Parent is Solid::Backends::Hal::HalDevice(0x2aa5a20), parent's thread is QThread(0x1f730d0), current thread is ThreadWeaver::Thread(0x2c07840)

The QObject class is the base class of all Qt objects and it is the heart of the Qt object model. Among a LOT of other things it adds garbage collection to QPointers and other QOBJECT children.

Amarok is attempting to communicate between threads in different process, which QThreads cannot do.

it shares data with all the other threads within the process but executes independently in the way that a separate program does on a multitasking operating system.
...
Each thread gets its own stack from the operating system.
...
Each QThread can have its own event loop. You can start the event loop by calling exec(); you can stop it by calling exit() or quit(). Having an event loop in a thread makes it possible to connect signals from other threads to slots in this thread, using a mechanism called queued connections.

but only within the same process. Here is the dicussion on QThread in Qt4.5.3.

It's my understanding that K3b was plagued with that problem and it held up K3b on KDE4 until its author wrote his own thread class.

QPainter::begin: Cannot paint on a null pixmap                                                 
QPainter::translate: Painter not active                                                    
QPainter::end: Painter not active, aborted

The QPainter class performs low-level painting on widgets and other paint devices. Apparently, with the failure of the threads to communicate the pixmap class wasn't instantiated so the QPainter class had nothing to paint into and it failed.

On my system I believe this happened because I selected all 24 tracks in an audio CD I was attempting to play and each track was, apparently, a thread in a different process. When I opened aramok in a konsole and then pointed it at the cdrom I started the first track playing without loading a playlist, which always crashed the player, and then it just played each track, one after the other without me loading a playlist or changing the track. When each track started to play the konsole showed the follow lines;

QPainter::begin: Cannot paint on a null pixmap
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::translate: Painter not active
QPainter::save: Painter not active
QPainter::translate: Painter not active
QPainter::rotate: Painter not active
QPainter::restore: Unbalanced save/restore
QPainter::rotate: Painter not active

After playing the last track these msgs appeared:

...
QPainter::begin: Cannot paint on a null pixmap
QPainter::translate: Painter not active
QPainter::end: Painter not active, aborted
(played last track)
CDROMREADRAW: Input/output error
CDROMREADRAW: Input/output error
CDROMREADRAW: Input/output error
CDROMREADTOCHDR: No medium found
xine_open for gapless playback failed!
CDROMREADTOCHDR: No medium found
CDROMREADTOCHDR: No medium found
Object::disconnect: Unexpected null parameter
Object::disconnect: Unexpected null parameter
Object::disconnect: Unexpected null parameter
QCoreApplication:ostEvent: Unexpected null receiver

The "unexpected null receiver" is, I suspect, because QCoreApplication.exec() expected to get a message about running QThreads which it was supposed to terminate.

Overall, it seems to me that Amarok 2.2.1 could be expecting a different Qt4 library to be present on the client machine, not the one which Kubuntu 9.10 with KDE 4.3.3 is running.