2183 – Amarok hangs when updating podcast feeds

By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2183 - Amarok hangs when updating podcast feeds

Summary: Amarok hangs when updating podcast feeds

Status:	NEEDINFO

Alias:	None

Product:	TDE
Classification:	Unclassified
Component:	tdemultimedia (show other bugs)
Version:	R14.0.x [Trinity]
Hardware:	Other Debian Wheezy

Importance:	P5 normal
Assignee:	Timothy Pearson

URL:

Depends on:
Blocks:

Reported:	2014-11-06 08:56 CST by Kristopher
Modified:	2018-08-02 09:13 CDT (History)
CC List:	4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Screenshot of Amarok "trying" to update podcast feeds (149.91 KB, image/png) 2014-11-06 08:57 CST, Kristopher	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Kristopher 2014-11-06 08:56:46 CST

When asking Amarok to check for updates for a podcast, whether it be for one podcast, several of them, or all of them, Amarok's podcast updater seems to hang indefinitely until I either cancel the update check or close Amarok. This bug has survived several updates of the R14 nightlies.

Comment 1 Kristopher 2014-11-06 08:57:38 CST

Created attachment 2341 [details]
Screenshot of Amarok "trying" to update podcast feeds

Comment 2 Timothy Pearson 2014-11-06 09:09:33 CST

Can you install the Amarok debugging symbols, then launch Amarok from the command line like this:

gdb amarokapp
r <enter>

Try updating the podcasts, and when Amarok hangs switch back to the terminal and enter:
Ctrl+C
thread apply all bt

then post the output to this report.

Thanks!

Comment 3 Kristopher 2014-11-06 09:30:13 CST

(In reply to Timothy Pearson from comment #2)
> Can you install the Amarok debugging symbols, then launch Amarok from the
> command line like this:
> 
> gdb amarokapp
> r <enter>
> 
> Try updating the podcasts, and when Amarok hangs switch back to the terminal
> and enter:
> Ctrl+C
> thread apply all bt
> 
> then post the output to this report.
> 
> Thanks!

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/trinity/bin/amarokapp...Reading symbols from /usr/lib/debug/opt/trinity/bin/amarokapp...done.
done.
(gdb) run
Starting program: /opt/trinity/bin/amarokapp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x4800025
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x896bf0 ): TDEAccel object already contains an action name "play_pause"
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x896bf0 ): TDEAccel object already contains an action name "play_pause"
[New Thread 0x7fffe76b6700 (LWP 7796)]
[Thread 0x7fffe76b6700 (LWP 7796) exited]
[New Thread 0x7fffe76b6700 (LWP 7797)]
[Thread 0x7fffe76b6700 (LWP 7797) exited]
[New Thread 0x7fffe76b6700 (LWP 7798)]
[Thread 0x7fffe76b6700 (LWP 7798) exited]
[New Thread 0x7fffe76b6700 (LWP 7799)]
[New Thread 0x7fffe59fe700 (LWP 7800)]
[New Thread 0x7fffe51fd700 (LWP 7801)]
[New Thread 0x7fffe482f700 (LWP 7802)]
[New Thread 0x7fffdffff700 (LWP 7803)]
[New Thread 0x7fffdf7fe700 (LWP 7804)]
STARTUP
[Thread 0x7fffdf7fe700 (LWP 7804) exited]
[New Thread 0x7fffdeffd700 (LWP 7805)]
[Thread 0x7fffdeffd700 (LWP 7805) exited]
[New Thread 0x7fffdeffd700 (LWP 7837)]
[Thread 0x7fffdeffd700 (LWP 7837) exited]
[New Thread 0x7fffdeffd700 (LWP 7838)]
[Thread 0x7fffdeffd700 (LWP 7838) exited]
[New Thread 0x7fffdeffd700 (LWP 7859)]
[Thread 0x7fffdeffd700 (LWP 7859) exited]
[New Thread 0x7fffdeffd700 (LWP 7860)]
[Thread 0x7fffdeffd700 (LWP 7860) exited]
[New Thread 0x7fffdeffd700 (LWP 7899)]
[Thread 0x7fffdeffd700 (LWP 7899) exited]
[New Thread 0x7fffdeffd700 (LWP 7900)]
[Thread 0x7fffdeffd700 (LWP 7900) exited]
[New Thread 0x7fffdeffd700 (LWP 7937)]
[Thread 0x7fffdeffd700 (LWP 7937) exited]
[New Thread 0x7fffdeffd700 (LWP 7938)]
[Thread 0x7fffdeffd700 (LWP 7938) exited]
[New Thread 0x7fffdeffd700 (LWP 7960)]
[Thread 0x7fffdeffd700 (LWP 7960) exited]
[New Thread 0x7fffdeffd700 (LWP 7961)]
[Thread 0x7fffdeffd700 (LWP 7961) exited]
[New Thread 0x7fffdeffd700 (LWP 7999)]
[Thread 0x7fffdeffd700 (LWP 7999) exited]
[New Thread 0x7fffdeffd700 (LWP 8000)]
[Thread 0x7fffdeffd700 (LWP 8000) exited]
[New Thread 0x7fffdeffd700 (LWP 8022)]
[Thread 0x7fffdeffd700 (LWP 8022) exited]
[New Thread 0x7fffdeffd700 (LWP 8023)]
[Thread 0x7fffdeffd700 (LWP 8023) exited]
[New Thread 0x7fffdeffd700 (LWP 8061)]
[Thread 0x7fffdeffd700 (LWP 8061) exited]
[New Thread 0x7fffdeffd700 (LWP 8062)]
[Thread 0x7fffdeffd700 (LWP 8062) exited]
[New Thread 0x7fffdeffd700 (LWP 8086)]
[Thread 0x7fffdeffd700 (LWP 8086) exited]
[New Thread 0x7fffdeffd700 (LWP 8087)]
[Thread 0x7fffdeffd700 (LWP 8087) exited]
[New Thread 0x7fffdeffd700 (LWP 8111)]
[Thread 0x7fffdeffd700 (LWP 8111) exited]
[New Thread 0x7fffdeffd700 (LWP 8112)]
[Thread 0x7fffdeffd700 (LWP 8112) exited]
[New Thread 0x7fffdeffd700 (LWP 8152)]
[Thread 0x7fffdeffd700 (LWP 8152) exited]
[New Thread 0x7fffdeffd700 (LWP 8153)]
[Thread 0x7fffdeffd700 (LWP 8153) exited]
[New Thread 0x7fffdeffd700 (LWP 8194)]
[Thread 0x7fffdeffd700 (LWP 8194) exited]
[New Thread 0x7fffdeffd700 (LWP 8195)]
[Thread 0x7fffdeffd700 (LWP 8195) exited]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fffe76b6700 (LWP 7799)]
pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
216     ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory.
(gdb) thread apply all bt

Thread 9 (Thread 0x7fffdffff700 (LWP 7803)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe615177b in xine_event_wait () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#2  0x00007fffe615181e in ?? () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#3  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 8 (Thread 0x7fffe482f700 (LWP 7802)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe614166b in ?? () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#2  0x00007fffe614890d in ?? () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#3  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7fffe51fd700 (LWP 7801)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe614f803 in ?? () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#2  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#3  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7fffe59fe700 (LWP 7800)):
#0  0x00007ffff1d84b73 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=333) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007fffe5cf90de in ?? () from /usr/lib/x86_64-linux-gnu/xine/plugins/2.2/xineplug_ao_out_alsa.so
#2  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#3  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7fffe76b6700 (LWP 7799)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1  0x00007fffe613d770 in ?? () from /usr/lib/x86_64-linux-gnu/libxine.so.2
#2  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#3  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7ead7a0 (LWP 7791)):
#0  0x00007ffff1d84b73 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=19) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007ffff55cb624 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff55cb744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff67c1d33 in TQEventLoop::processEvents (this=0x6982f0, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279
#4  0x00007ffff67ef7a9 in TQEventLoop::enterLoop (this=0x6982f0) at kernel/qeventloop.cpp:227
#5  0x00007ffff67ef739 in TQEventLoop::exec (this=0x6982f0) at kernel/qeventloop.cpp:174
---Type <return> to continue, or q <return> to quit---
#6  0x0000000000401674 in main (argc=1, argv=0x7fffffffe388) at /build/buildd/amarok-trinity-14.0.0-r275/./amarok/src/main.cpp:116
(gdb)

Comment 4 Timothy Pearson 2014-11-06 09:35:34 CST

Interesting; the hang seems to be coming from underneath Amarok, in Xine itself.

Can you install the libxine2-dbg package and repeat the debug process?

Thanks!

Comment 5 Kristopher 2014-11-06 09:48:09 CST

(In reply to Timothy Pearson from comment #4)
> Interesting; the hang seems to be coming from underneath Amarok, in Xine
> itself.
> 
> Can you install the libxine2-dbg package and repeat the debug process?
> 
> Thanks!


GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/trinity/bin/amarokapp...Reading symbols from /usr/lib/debug/opt/trinity/bin/amarokapp...done.
done.
(gdb) run
Starting program: /opt/trinity/bin/amarokapp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x4800025
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x891a70 ): TDEAccel object already contains an action name "play_pause"
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x891a70 ): TDEAccel object already contains an action name "play_pause"
[New Thread 0x7fffe76b6700 (LWP 10168)]
[Thread 0x7fffe76b6700 (LWP 10168) exited]
[New Thread 0x7fffe76b6700 (LWP 10169)]
[Thread 0x7fffe76b6700 (LWP 10169) exited]
[New Thread 0x7fffe76b6700 (LWP 10170)]
[Thread 0x7fffe76b6700 (LWP 10170) exited]
[New Thread 0x7fffe76b6700 (LWP 10171)]
[New Thread 0x7fffe59fe700 (LWP 10172)]
[New Thread 0x7fffe51fd700 (LWP 10173)]
[New Thread 0x7fffe482f700 (LWP 10174)]
[New Thread 0x7fffdffff700 (LWP 10175)]
[New Thread 0x7fffdf7fe700 (LWP 10176)]
STARTUP
[Thread 0x7fffdf7fe700 (LWP 10176) exited]
[New Thread 0x7fffdeffd700 (LWP 10177)]
[Thread 0x7fffdeffd700 (LWP 10177) exited]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fffe76b6700 (LWP 10171)]
pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
216     ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory.
(gdb) thread apply all bt

Thread 9 (Thread 0x7fffdffff700 (LWP 10175)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe615177b in xine_event_wait (queue=queue@entry=0x1612e20) at events.c:56
#2  0x00007fffe615181e in listener_loop (queue_gen=0x1612e20) at events.c:219
#3  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 8 (Thread 0x7fffe482f700 (LWP 10174)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe614166b in fifo_buffer_get (fifo=0x1606fd0) at buffer.c:236
#2  0x00007fffe614890d in audio_decoder_loop (stream_gen=0x15fb2f0) at audio_decoder.c:67
#3  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7fffe51fd700 (LWP 10173)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fffe614f803 in fifo_peek_int (blocking=1, fifo=0x14b9c20) at audio_out.c:360
#2  fifo_peek (fifo=0x14b9c20) at audio_out.c:400
#3  ao_loop (this_gen=0x1494440) at audio_out.c:1025
#4  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#5  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7fffe59fe700 (LWP 10172)):
#0  0x00007ffff1d84b73 in *__GI___poll (fds=<optimized out>, fds@entry=0x7fffe59fdda0, nfds=<optimized out>, nfds@entry=1, timeout=timeout@entry=333)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007fffe5cf90de in my_snd_mixer_wait (mixer=0x1498550, timeout=<optimized out>) at audio_alsa_out.c:150
#2  ao_alsa_handle_event_thread (data=0x1434540) at audio_alsa_out.c:166
#3  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7fffe76b6700 (LWP 10171)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1  0x00007fffe613d770 in metronom_sync_loop (this_gen=0x14335c0) at metronom.c:889
#2  0x00007ffff30a1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#3  0x00007ffff1d8f7bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7ead7a0 (LWP 10147)):
#0  0x00007ffff1d84b73 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=19) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007ffff55cb624 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#2  0x00007ffff55cb744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff67c1d33 in TQEventLoop::processEvents (this=0x698360, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279
#4  0x00007ffff67ef7a9 in TQEventLoop::enterLoop (this=0x698360) at kernel/qeventloop.cpp:227
#5  0x00007ffff67ef739 in TQEventLoop::exec (this=0x698360) at kernel/qeventloop.cpp:174
#6  0x0000000000401674 in main (argc=1, argv=0x7fffffffe388) at /build/buildd/amarok-trinity-14.0.0-r275/./amarok/src/main.cpp:116
(gdb)

Comment 6 Timothy Pearson 2014-11-06 09:54:51 CST

Thanks for the debug info.  I'll need to look into this further as something is hanging Xine, which I guess is then deadlocking Amarok.  This might be related to Bug 2060 and Bug 2174.

Comment 7 Kristopher 2014-11-06 09:57:28 CST

(In reply to Timothy Pearson from comment #4)
> Interesting; the hang seems to be coming from underneath Amarok, in Xine
> itself.

I just tested with the Engine set to "yauap engine" (instead of "xine Engine"), and the hang still occurs.

Comment 8 Kristopher 2014-11-06 10:03:00 CST

(In reply to Kristopher from comment #7)
> (In reply to Timothy Pearson from comment #4)
> > Interesting; the hang seems to be coming from underneath Amarok, in Xine
> > itself.
> 
> I just tested with the Engine set to "yauap engine" (instead of "xine
> Engine"), and the hang still occurs.

In case it's helpful, I've installed yauap-dbg for the following backtrace:




GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/trinity/bin/amarokapp...Reading symbols from /usr/lib/debug/opt/trinity/bin/amarokapp...done.
done.
(gdb) run
Starting program: /opt/trinity/bin/amarokapp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x4800025
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x892230 ): TDEAccel object already contains an action name "play_pause"
tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel = 0x892230 ): TDEAccel object already contains an action name "play_pause"
[New Thread 0x7fffe76b6700 (LWP 11247)]
[Thread 0x7fffe76b6700 (LWP 11247) exited]
[New Thread 0x7fffe76b6700 (LWP 11248)]
[Thread 0x7fffe76b6700 (LWP 11248) exited]
[New Thread 0x7fffe76b6700 (LWP 11249)]
[Thread 0x7fffe76b6700 (LWP 11249) exited]
[New Thread 0x7fffe76b6700 (LWP 11251)]
STARTUP
[New Thread 0x7fffe619c700 (LWP 11252)]
[Thread 0x7fffe619c700 (LWP 11252) exited]
[Thread 0x7fffe76b6700 (LWP 11251) exited]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff55ca925 in g_main_context_release () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7ead7a0 (LWP 11226)):
#0  0x00007ffff55ca925 in g_main_context_release () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff55cb5d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff55cb744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff67c1d33 in TQEventLoop::processEvents (this=0x698340, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279
#4  0x00007ffff67ef7a9 in TQEventLoop::enterLoop (this=0x698340) at kernel/qeventloop.cpp:227
#5  0x00007ffff67ef739 in TQEventLoop::exec (this=0x698340) at kernel/qeventloop.cpp:174
#6  0x0000000000401674 in main (argc=1, argv=0x7fffffffe388) at /build/buildd/amarok-trinity-14.0.0-r275/./amarok/src/main.cpp:116
(gdb)

Comment 9 Timothy Pearson 2014-11-06 11:25:07 CST

(In reply to Kristopher from comment #8)
> (In reply to Kristopher from comment #7)
> > (In reply to Timothy Pearson from comment #4)
> > > Interesting; the hang seems to be coming from underneath Amarok, in Xine
> > > itself.
> > 
> > I just tested with the Engine set to "yauap engine" (instead of "xine
> > Engine"), and the hang still occurs.
> 
> In case it's helpful, I've installed yauap-dbg for the following backtrace:

Yes, that does help (it indicates threading is not responsible).  Thanks!

Comment 10 Timothy Pearson 2014-11-08 00:53:46 CST

Was this bug present in TDE 3.5.13.x?  If not then this should have a [Regression] tag added.

Thanks!

Comment 11 Timothy Pearson 2014-11-09 22:56:20 CST

(In reply to Kristopher from comment #0)
> When asking Amarok to check for updates for a podcast, whether it be for one
> podcast, several of them, or all of them, Amarok's podcast updater seems to
> hang indefinitely until I either cancel the update check or close Amarok.
> This bug has survived several updates of the R14 nightlies.

Hmmm....I just tested this on Debian Jessie R14 nightly; I added two Linux podcasts (an RSS and an XML feed) and closed Amarok, then relaunched Amarok and right-clicked on Podcasts and selected "Refresh All Podcasts".  The refresh worked fine.

Am I reproducing this wrong?

Thanks!

Comment 12 Kristopher 2014-11-10 19:48:38 CST

(In reply to Timothy Pearson from comment #11)
> (In reply to Kristopher from comment #0)
> > When asking Amarok to check for updates for a podcast, whether it be for one
> > podcast, several of them, or all of them, Amarok's podcast updater seems to
> > hang indefinitely until I either cancel the update check or close Amarok.
> > This bug has survived several updates of the R14 nightlies.
> 
> Hmmm....I just tested this on Debian Jessie R14 nightly; I added two Linux
> podcasts (an RSS and an XML feed) and closed Amarok, then relaunched Amarok
> and right-clicked on Podcasts and selected "Refresh All Podcasts".  The
> refresh worked fine.
> 
> Am I reproducing this wrong?
> 
> Thanks!

Other than the fact that we are using different versions of Debian, you are doing it the same way I did.

Despite using a development version of TDE, I have decided to stick with Debian stable -- maybe some of the underlying libraries in Jessie have changed in a way that prevents this bug from showing for you?

Comment 13 Kristopher 2014-11-10 20:01:10 CST

(In reply to Kristopher from comment #12)
> (In reply to Timothy Pearson from comment #11)
> > (In reply to Kristopher from comment #0)
> > > When asking Amarok to check for updates for a podcast, whether it be for one
> > > podcast, several of them, or all of them, Amarok's podcast updater seems to
> > > hang indefinitely until I either cancel the update check or close Amarok.
> > > This bug has survived several updates of the R14 nightlies.
> > 
> > Hmmm....I just tested this on Debian Jessie R14 nightly; I added two Linux
> > podcasts (an RSS and an XML feed) and closed Amarok, then relaunched Amarok
> > and right-clicked on Podcasts and selected "Refresh All Podcasts".  The
> > refresh worked fine.
> > 
> > Am I reproducing this wrong?
> > 
> > Thanks!
> 
> Other than the fact that we are using different versions of Debian, you are
> doing it the same way I did.
> 
> Despite using a development version of TDE, I have decided to stick with
> Debian stable -- maybe some of the underlying libraries in Jessie have
> changed in a way that prevents this bug from showing for you?

While I'm thinking about it, I'm starting to think that Xine may have a few bugs (see bug #2183 for another seemingly xine-related example of TDE applications malfunctioning). It may be necessary to add some workarounds for whatever version of xine Debian Wheezy is using (at the very least, display some message explaining that older versions of xine may cause issues).

Comment 14 Kristopher 2015-02-05 09:25:40 CST

I am marking this bug as specific to Debian Wheezy. That is where I found this bug (where it is still present), and I'm unable to reproduce it in CentOS version 7.

Please note that I have *not* tried this in Debian Squeeze or Debian Jessie, so I don't know if this bug shows in either of those.

Comment 15 Michele Calgaro 2018-08-02 09:13:11 CDT

Is this bug still valid?