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 446902 - [queue2] Define minimum buffering message steps
[queue2] Define minimum buffering message steps
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-12 21:53 UTC by Thiago Sousa Santos
Modified: 2009-09-10 08:17 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Adds the functionality. (4.97 KB, patch)
2007-06-12 22:20 UTC, Thiago Sousa Santos
none Details | Review

Description Thiago Sousa Santos 2007-06-12 21:53:17 UTC
To avoid a continuous posting of messages to the bus while buffering, queue2 should offer a property to set a minimum difference between buffering messages posted.

Suppose it has just posted 5%, so if this message-step property is set to 10, it will only post another message when the buffering is at least 15%.
Comment 1 Thiago Sousa Santos 2007-06-12 22:20:11 UTC
Created attachment 89846 [details] [review]
Adds the functionality.

Creates the property buffering-message-step and add the code to do what the enhancement proposes.
Comment 2 Sebastian Dröge (slomo) 2009-05-07 12:35:04 UTC
Looks good in general but what exactly is the NOT_BUFFERING constant about? If the last message is set to this you will always post a message because the diff is always larger than 100 unless I miss anything here... and this means that messages will be posted in any case and forever if 100% is reached.
Comment 3 Thiago Sousa Santos 2009-05-07 17:13:58 UTC
You're right, the patch has a bug. But this has been proposed a long time ago when queue2 was still being developed (or almost finishing its development) and no one bothered about it.

If this issue is relevant I can send an updated patch, but I think that no one cares about this, so, closing it is also an option.
Comment 4 Sebastian Dröge (slomo) 2009-09-10 08:17:47 UTC
Then let's close this because nobody cares anymore ;)