Version: 2.1.1 (using KDE 4.3.0) Compiler: gcc (Gentoo 4.4.1 p1.0) 4.4.1 FLAGS: -march=native -mtune=native -O3 -msse4a -pipe OS: Linux Installed from: Gentoo Packages When clicking on mp3 file to play it (don't know about other formats) amarok takes a very long time prior to start the actual play, the bar show some seconds play but no sound comes out. Te song eventually starts but after several minutes. The same happens to shoutcast sources. when amarok is restarted the first file is played ok, only the following show this behaviour. I've tried both phonon (gestreamer) and xine backends, no difference. No crash or bugs shows up in any log. Other sources (say, firefox flash player on youtube) works just fine at the same moment and situation. mp3 files are located in main HD storage (lvm setup/raid/xfs) and I've recreated playlist just to be sure. It happens also with direct mp3 file selection. menu Amarok-> play a trace of the amarok thread shows an endless stream of this messages: semop(65536, 0x7f939103fbc0, 2) = 0 semop(65536, 0x7f939103fbd0, 1) = 0 read(64, "\1\0\0\0\377\377\377\377\17Y\1\0\0\0\0\0C\304\7'\0\0\0\0\1\0\0\0\0\0\0\0"..., 128) = 32 futex(0x7f9384a674a4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f9384a674a0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 poll([{fd=64, events=POLLIN|POLLERR|POLLNVAL}], 1, 40) = 1 ([{fd=64, revents=POLLIN}]) ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(78, USBDEVFS_IOCTL, 0x7f93846cd100) = 0 ioctl(75, 0x4122, 0) = 0 semop(65536, 0x7f939103fbc0, 2) = 0 semop(65536, 0x7f939103fbd0, 1) = 0 read(64, "\1\0\0\0\377\377\377\377\17Y\1\0\0\0\0\0\325ZM(\0\0\0\0\1\0\0\0\2\210\377\377"..., 128) = 32 futex(0x7f9384a674a4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f9384a674a0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 poll([{fd=64, events=POLLIN|POLLERR|POLLNVAL}], 1, 40) = 1 ([{fd=64, revents=POLLIN}]) ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 ioctl(75, 0x4122, 0) = 0 (fd 64 seems to be /dev/snd/timer) OS: linux 2.6.30.5 Le me know if more informations are needed.
Please run Amarok from the terminal like this, then attach amarok_debug.txt to this report: "amarok --debug --nofork &> amarok_debug.txt" Also one question: Does the GUI freeze during the period of silence?
Here you go; attached you can find all report file. And no, the gui is perfectly working, every menu and button works just fine. The interesting part seems to be this: [CUT] amarok: BEGIN: void LyricsManager::lyricsResult(const QString&, bool) amarok: lyrics xml: "<?xml version="1.0" encoding="UTF-8" ?><lyric artist="Huey Lewis &amp; The News" title="Come Kind Of Wonderful">Not found</lyric>" amarok: BEGIN: virtual void LyricsEngine::newLyrics(QStringList&) amarok: END__: virtual void LyricsEngine::newLyrics(QStringList&) - Took 0.00026s amarok: END__: void LyricsManager::lyricsResult(const QString&, bool) - Took 0.0017s amarok: END__: void AmarokScript::AmarokLyricsScript::showLyrics(const QString&) const - Took 0.0026s amarok: END__: void AmarokDownloadHelper::resultString(KJob*) - Took 0.0077s amarok: BEGIN: void ScanManager::startIncrementalScan() amarok: BEGIN: QStringList ScanManager::getDirsToScan() amarok: END__: QStringList ScanManager::getDirsToScan() - Took 0.018s amarok: GOING TO SCAN: amarok: Scanning nothing, return. amarok: BEGIN: void ScanManager::writeBatchIncrementalInfoFile() amarok: END__: void ScanManager::writeBatchIncrementalInfoFile() - Took 0.026s amarok: END__: void ScanManager::startIncrementalScan() - Took 0.045s (some minutes waiting) amarok: BEGIN: void ScanManager::startIncrementalScan() amarok: BEGIN: QStringList ScanManager::getDirsToScan() amarok: END__: QStringList ScanManager::getDirsToScan() - Took 0.018s amarok: GOING TO SCAN: amarok: Scanning nothing, return. amarok: BEGIN: void ScanManager::writeBatchIncrementalInfoFile() amarok: END__: void ScanManager::writeBatchIncrementalInfoFile() - Took 0.026s amarok: END__: void ScanManager::startIncrementalScan() - Took 0.044s amarok: BEGIN: void ScanManager::startIncrementalScan() amarok: BEGIN: QStringList ScanManager::getDirsToScan() amarok: END__: QStringList ScanManager::getDirsToScan() - Took 0.018s amarok: GOING TO SCAN: amarok: Scanning nothing, return. amarok: BEGIN: void ScanManager::writeBatchIncrementalInfoFile() amarok: END__: void ScanManager::writeBatchIncrementalInfoFile() - Took 0.025s amarok: END__: void ScanManager::startIncrementalScan() - Took 0.043s
Created attachment 36576 [details] debug attach file
*** Bug 205706 has been marked as a duplicate of this bug. ***
I can confirm that I have the same problem. Running Arch Linux x86_64, kernel version 2.6.30-5.
Forgot to say: my machine also is a 64bit arch: Linux 2.6.30.5 SMP PREEMPT x86_64 AMD
maybe a recent update in arch is to blame?
Well, likely, but I've updated several packaget ad it will took a *LOT* of time to bisect this (assuming that some library is the culprit. I even updated kernel...) Even a small hint on where the problem can lie could be helpful to find the right spot. In any case, amarok should cope with the upgrades :)
another comment: I'm unable to reproduce this issue on a similar installation (same kernel, distro, compiler, etc...) but on a 32 bit machine. It's possible that this issue happens only on a 64bit arch?
(In reply to comment #9) > another comment: I'm unable to reproduce this issue on a similar installation > (same kernel, distro, compiler, etc...) but on a 32 bit machine. > It's possible that this issue happens only on a 64bit arch? Must be Arch specific then, works quite well here on a 64bit with Kubuntu 9.04 and KDE 4.3.0
Hi, there's some issue with gstreamer and Amarok and it seems it's this one, see: http://bbs.archlinux.org/viewtopic.php?id=78871
(In reply to comment #11) > Hi, there's some issue with gstreamer and Amarok and it seems it's this one, > see: > http://bbs.archlinux.org/viewtopic.php?id=78871 Well, the reporter has also tried with the xine backend with the same results (see bug description), so this is unlikely.
Changing to the Xine backend fixed the problem for me. I guess this must be the cause.
No problem: in a short while I'll try again to switch sound backend, so I'll be able to report if this can be the root of the problem.
I've tried again several times, and in fact I'm unable to reproduce the issue with xine backend Anyway, the link does not provide a fix but only says to change to Xine that is fine but not a bugfix :) So now I wonder if this is a gstreamer bug or an amarok problem when tries to use gstreamer backend. Any suggestion on where to open the correct report? Thanks :)
(In reply to comment #15) > I've tried again several times, and in fact I'm unable to reproduce the issue > with xine backend > Anyway, the link does not provide a fix but only says to change to Xine that is > fine but not a bugfix :) Amarok doesn't handle sound itself, but let's phonon do it, so you might want to report it upstream to phonon against the gstreamer backend. You can check for duplicates here: http://tinyurl.com/phononbugs