Bug 6108 – tracker takes cpu and time when scanning media

Bug 6108 - (int-146323) tracker takes cpu and time when scanning media

(int-146323)
Summary:	tracker takes cpu and time when scanning media

Status:	NEW

Product:	Multimedia
Component:	gstreamer
Version:	5.0/(1.2009.41-10)
Platform:	N900 Windows

Importance:	Low normal with 2 votes (vote)
Target Milestone:	---
Assigned To:	unassigned
QA Contact:	gstreamer-bugs

URL:
Keywords:	performance

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-11-11 00:08 UTC by Gary Birkett
Modified:	2010-03-22 19:59 UTC (History)
CC List:	4 users (show)

See Also:

Attachments
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 Gary Birkett (reporter) 2009-11-11 00:08:22 UTC

SOFTWARE VERSION:
41-10

STEPS TO REPRODUCE THE PROBLEM:

connect computer to usb
select mass storage mode
drag drop a few .avi movie files (6 files, each about 350mb, 42mins or so)

unplug usb

EXPECTED OUTCOME:

n900 should continue to function perfectly and all media should be accessible
in a timely manner without dragging system down and causing other applications
to run slowly.

ACTUAL OUTCOME:

after unplugging the system gets busy and tries to scan the media
causing slowdowns to my running applications as the system chomps at the media
in the background.

a notification flashes up briefly saying how long it will take.
i think it said 9 minutes last time after I added 6 files.
after this notification, i have no way of knowing why the system is running
slowly.

the slowdowns continue until its finished which is rather annoying since I'm
using the machine at the time.

REPRODUCIBILITY:
the last 3 times I have added substantial media to the device.

EXTRA SOFTWARE INSTALLED:
not much
OTHER COMMENTS:

i would like to find a way to tell the tracker daemon to either ignore metadata
within movie and mp3 files and to work with the meta data available from the
filesystem only or a way to perform this quick scan at first and then to
schedule its deeper slower scan when the device is really really not being
used.



i have no movie/music which needs more since it is all categorised by its
complete file system name and has been for many years.

/movies/scifi/trailers/startrek.avi
/music/albums/barney kessel/Poll Winners Three/*.mp3

I understand others may not categorise their data this way, but a lot do and at
least if we could tell it this preference it may be beneficial.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5)
Gecko/2008120122 Firefox/3.0.5

Comment 1 Gary Birkett (reporter) 2009-11-11 00:27:35 UTC

followup

for the limiting search part I mention, I did some digging.

http://linux.die.net/man/5/tracker.cfg

informs me there is this available:

NoIndexFileTypes=FILEGLOB[;MORE;FILEGLOBS...]
    List of partial file patterns (glob) separated by semicolons that specify
files not to index. Only basic metadata (i.e. information retrieved by stat(2))
is indexed.


on the n900, this particular field is not listed in the current configuration
file, but I will attempt to assign values here and monitor next time I have
media to media on.

Comment 2 Andre Klapper maemo.org

2009-11-11 20:58:45 UTC

Thanks for reporting this.

Hmm, I think in theory(TM) this should not happen and indexing should happen
less aggressive.

Comment 3 Urho Konttori 2009-11-16 12:34:27 UTC

THis is related to gstreamer demuxer issues. Forward to gstreamer guys. I think
they have fixed this already, but I don't want to say so without exact
knowledge.

Comment 4 Eero Tamminen nokia

2009-11-18 12:30:56 UTC

Does this happen with anything else than (large) AVI files?

Comment 5 Gary Birkett (reporter) 2009-11-18 17:22:54 UTC

(In reply to comment #4)
> Does this happen with anything else than (large) AVI files?
> 

Eero, 
not outside the expected bounds.
occasionally after saving images, screenshots and sometimes after copying code
it will catch for a second or two, but those are smallish files and practically
unnoticable from a user standpoint to file system activity.

its only been noticeable for an extended period when I first put large media
files on.
tracker seems well behaved outside of these times :)

mail me if you need some test files.

Comment 6 Eero Tamminen nokia

2009-11-18 18:48:38 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > Does this happen with anything else than (large) AVI files?
>
> not outside the expected bounds.

Thanks, I just wanted to verify this is a gstreamer issue, not Tracker one.
(partially also issue of the AVI format itself.)

Comment 7 Urho Konttori 2009-11-22 21:43:32 UTC

the avi demuxer has been improved greatly recently in gst, so expect
improvement in the near future.

Comment 8 Venomrush 2010-03-20 00:20:53 UTC

Is this just related to Media files?

(In reply to comment #0)
> a notification flashes up briefly saying how long it will take.

As I have this happen to me in Photos Viewer. 
I transferred some an image for testing the other day, less than 500kb to the
N900. Unplugged usb cable and opened Photos Viewer right away, upon opening, it
prompted to wait more than 1 minute. Found it was odd.

(In reply to comment #7)
> the avi demuxer has been improved greatly recently in gst, so expect
> improvement in the near future.
> 

Can you confirm this will be fixed in PR1.2?

(In reply to comment #6)
> Thanks, I just wanted to verify this is a gstreamer issue, not Tracker one.
> (partially also issue of the AVI format itself.)
> 

Moving component.

Comment 9 Eero Tamminen nokia

2010-03-22 19:59:45 UTC

(In reply to comment #8)
> I transferred some an image for testing the other day, less than 500kb to
> the N900. Unplugged usb cable and opened Photos Viewer right away, upon
> opening, it prompted to wait more than 1 minute. Found it was odd.

How large the image was in pixels and in which format it was?

Is this reproducible (if you e.g. remove the image)?

Could you run e.g. top in SSH connection (or on XTerm, but then you don't see
the whole time) to see whether there's any funny CPU usage?


Minute sounds still too much for thumbnailing an image even if somethings
taking all CPU in the background...  There are some conditions when tracker
will skip doing some of its work (I think these are there being a call in
progress, low memory situation or low battery) and currently there's no
mechanism through which it could communicate this to the user in any meaningful
way.  But in that case it would be separate issue, this bug is about CPU usage.