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 680366 - GstDiscoverer slows down when discovering multiple files
GstDiscoverer slows down when discovering multiple files
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.36
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-07-21 10:54 UTC by Jens Georg
Modified: 2015-09-10 06:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Simple testcase (728 bytes, text/x-csrc)
2012-07-21 10:54 UTC, Jens Georg 		Details
Plot of the testprogram's output run on a mp3 file (8.52 KB, image/png)
2012-07-21 10:56 UTC, Jens Georg 		Details

Description Jens Georg 2012-07-21 10:54:37 UTC 
Created attachment 219375 [details]
Simple testcase

Starting investigation from https://mail.gnome.org/archives/rygel-list/2012-July/msg00129.html

It looks like that 0.10, the repeated use of a GstDiscoverer in a mass-extraction scenario (such as Rygel's metadata harvester) causes the discoverer to slow down quite a lot after some rounds of extraction.

See attached example which simulates the extraction of 4.5k mp3 files. After ~1.5k extractions the time for a single extraction is up to ~0.5s from ~0.005 seconds.
Comment 1 Jens Georg 2012-07-21 10:56:50 UTC 
Created attachment 219376 [details]
Plot of the testprogram's output run on a mp3 file
Comment 2 Jens Georg 2012-07-21 11:19:30 UTC 
This also seems to have a bad effect in the async scenario, idle funcs (with default priority) are massively delayed, up to several seconds.
Comment 3 Roderich Schupp 2012-07-23 07:04:38 UTC 
Note: The problem seems to be fixed in Gstreamer 1.0 (as of 0.11.92), 
i.e. the time for a single extraction doesn't increase there.
But the test program is leaking memory.
Comment 4 Jens Georg 2012-08-20 14:04:39 UTC 
Also seems to be fixed for 0.10 now.
Comment 5 Tim-Philipp Müller 2012-12-25 17:47:52 UTC 
I gather this is obsolete now?
Comment 6 Roderich Schupp 2012-12-25 23:13:06 UTC 
(In reply to comment #5)
> I gather this is obsolete now?

I just rebuilt and ran Jens's test program:
the behaviour is still as reported for gst-plugins-base 0.10.36: the more gst_discoverer_discover_uri() you do, the slower it gets.
It's OK for gst-plugins-base 1.0.4 though, so this may be a purely academic exercise.

My original complaint with rygel has been addressed with a workaround there
(in the 0.16 series which was still using gstreamer 0.10).
Comment 7 Jens Georg 2012-12-26 21:13:58 UTC 
IIRC in comment 4 I tried it with some 0.10 git after 0.10.36 and it was gone as well.
Comment 8 Tim-Philipp Müller 2012-12-26 22:42:59 UTC 
Thanks the updates. I think we're only really interested in whether it's fixed in 1.x or not, but if it's fixed in 0.10 git as well, all the better :) Let's close this bug then, if there's still an issue I'm sure someone will file a new bug soon enough.
Comment 9 Jens Georg 2015-09-10 06:41:51 UTC 
While reworking the discovery in rygel unstable I noticed that this weird behavior is still there in 1.x when discoverer fails on a file. It gets really slow afterwards if you keep using it. I will try to reproduce with some sample file and probably file a new bug