When launching Amarok 1.2.2 it goes through the movments for starting (according to debug anyway) untill it gets to [StatusBar] 1updateProgressAppearance(), upon where it drops into a sleep, and the KDE Kicker Freezes solid, and amarok never appears. Upon killing of amarokapp, the kicker resumes normal life. Reproducible: Always Steps to Reproduce: 1. install kde 3.4 from split version (kde-meta) 2. install amarok 1.2.2 3. run kde 3.4 4. run amarok Actual Results: kicker froze, and amarok didnt show Expected Results: kicker NOT freezing.. amarok spawning Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.200 50125-r1, 2.6.11-gentoo-r3 i686) ================================================================= System uname: 2.6.11-gentoo-r3 i686 AMD Athlon(TM) XP 2000+ Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 1 2005, 06:13:25)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disable d] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r6 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share /config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kd e/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/default s/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips /config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config / /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms usepkg" GENTOO_MIRRORS="ftp://gentoo.recoil.net.nz/gentoo ftp://ftp2.jetstreamgames.co.n z/dist/gentoo" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://gentoo.recoil.net.nz/gentoo-portage" USE="x86 X aalib acpi adns alsa apm arts audiofile avi bash-completion berkdb bi tmap-fonts bonobo bzlib cdparanoia cdr crypt cscope cups curl directfb divx4linu x doc dvd emboss encode esd examples exif fam fbcon ffmpeg firebird flac flash f ont-server foomaticdb fortran freetds ftp gcj gdbm ggi gif glut gnome gphoto2 gp m gstreamer gtk gtk2 guile icc imagemagick imlib ipv6 jack java javascript jpeg junit kde kdexdeltas ldap libcaca libg++ libwww lm_sensors mad mcal mikmod ming mmap mmx mng motif mozilla mp3 mpeg msn mysql nas ncurses nls odbc offensive ogg oggvorbis openal opengl oss pam pcre pdflib perl php png postgres python qt qui cktime readline recode ruby samba scanner sdl snmp speex spell spl sse ssl svg s vga szip tcltk tcpd test tetex threads tidy tiff tokenizer truetype truetype-fon ts type1-fonts unicode usb userlocales videos wmf xine xml xml2 xmlrpx xmms xpm xsl xv xvid yahoo zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
edit... for some absurd reason, now it doenst freeze the kicker.... (i didnt change anything as far as i can tell).. but amarok still wont launch
And what do you get in this case if you run amarokapp in a terminal?
im really not understanding what the bug is now... now it DOES run, it just takes an inordinate amount of time to do so. the problem seems to have eventually solved itself if left running long enough... bloody confusing.... it _USED_ to freeze straight after the debug message: amarok: [virtual bool BrowserBar::event(QEvent*)] Line: 182 amarok: [BlockAnalyzer] FallTime: 300 amarok: [ThreadWeaver] Job completed: PlaylistReader. Jobs pending: 0 amarok: [ThreadWeaver] Job completed: UrlLoader. Jobs pending: 0 amarok: END__: UrlLoader - Took 0.43s amarok: [StatusBar] Creating timer for: 1hideMainProgressBar() amarok: [StatusBar] 1updateProgressAppearance() but now it doesnt....
Long startup times can have various explanations, maybe a very large collection? Anyway, I'm closing this bug now until there's a way to reproduce it consistently.
