After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523993 - playbin2 blocks after a while when listening to a radio stream
playbin2 blocks after a while when listening to a radio stream
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.20
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-23 15:21 UTC by Sjoerd Simons
Modified: 2008-04-03 15:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sjoerd Simons 2008-03-23 15:21:58 UTC
After listening to a internet radio stream for a while playbin2 blocks. Looking into it with gdb revealed the following (only the relevant parts pasted):




Looking into the gstqueue2 at the relevant lines showed that the waits are respectively for removing/adding a queue.. So it's both waiting for an item to be removed and to be added.. Using gdb to doublecheck:

(gdb) p ((GstQueue*) 0x76a020)->waiting_add
$48 = 1
(gdb) p ((GstQueue*) 0x76a020)->waiting_del
$49 = 1

Woopsie.. So let's see if it's actually empty:
(gdb) p ((GstQueue*) 0x76a020)->queue->length
$50 = 0

Apparently it is. So now let's see why it thinks it's full:

(gdb) p ((GstQueue*) 0x76a020)->max_level.buffers
$65 = 100
(gdb) p ((GstQueue*) 0x76a020)->cur_level.buffers
$66 = 0
(gdb) p ((GstQueue*) 0x76a020)->max_level.bytes
$67 = 2097152
(gdb) p ((GstQueue*) 0x76a020)->cur_level.bytes
$68 = 0
(gdb) p ((GstQueue*) 0x76a020)->max_level.time
$69 = 2000000000
(gdb) p ((GstQueue*) 0x76a020)->cur_level.time
$70 = 0
(gdb) p ((GstQueue*) 0x76a020)->use_rate_estimate 
$71 = 1
(gdb) p ((GstQueue*) 0x76a020)->max_level.rate_time
$72 = 2000000000
(gdb) p ((GstQueue*) 0x76a020)->cur_level.rate_time
$73 = 2015175107
Comment 1 Wim Taymans 2008-03-24 14:09:18 UTC
        * gst/playback/gstqueue2.c: (gst_queue_is_filled):
        The queue is never filled when there are no buffers in the queue at all.
        Fixes #523993.
Comment 2 Sjoerd Simons 2008-03-24 20:44:40 UTC
But this means that when the case shown above is hit, then the queue will be completely emptied before buffers are allowed in again. Isn't it better to recalculate cur_level.rate_time everytime a buffer is dequeued?