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 519355 - constant hard disk usage when playing music
constant hard disk usage when playing music
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: dont know
0.10.x
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-28 18:34 UTC by Nicolò Chieffo
Modified: 2009-01-29 09:26 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Nicolò Chieffo 2008-02-28 18:34:14 UTC
When playing music/watching videos, gstreamer should cache the file content into the RAM, so that it will not access the disk every second. this will preserve battery and hard disk life.
Comment 1 Wim Taymans 2008-03-03 14:50:42 UTC
I thought this would be the job of the Operating system. We prefer to just keep as little media in memory instead. I can see how we could read bigger chunks in one go from disk (configurable) but we don't currently.
Comment 2 Nicolò Chieffo 2008-03-03 15:57:47 UTC
How is it possible to do this in the O.S.? maybe using laptop mode?
What is the advantage of keeping little media in memory?
If the media is an mp3 of 4MB there's no point to prevent from keeping it RAM. On the other hand, if it's a video of hundreds of MB you are completely right.

What do you think of my opinion?
Comment 3 David Schleef 2008-03-05 22:01:40 UTC
The only advantage for preloading media (mostly sound files) is so that the hard drive can spin down.  I have yet to see a Linux laptop configured in such a way that the hard drive is stopped a significant fraction of the time.  Usually, I observe that the drive spins down for about 2 seconds, then spins up again.  Until HD spindown is useful in the rest of Linux (or whatever OS), it's merely a waste of developer time to add support in GStreamer.

Assuming that that problem has been solved, this ends up being mostly an issue of writing a library for applications (such as rhythmbox) to use that allows the media player to hint which media files will be needed soon, and load them into memory.  The media player can then use appsrc instead of filesrc to play the file from memory instead of a file.

As always, we don't keep track of enhancement requests in bugzilla unless someone is actively working on the problem, or a GStreamer developer wants to look after it.  So unless someone steps forward, this bug should be closed.
Comment 4 Edward Hervey 2009-01-29 09:26:47 UTC
After a bit of investigation, with a default gstreamer setup + rhythmbox, the pipeline only does bursts of reads every second or so.

Considering an average duration of 5mins for a track, you would still have to wake up the hard drive every 5mins. That would be roughly the average spin-down timeout on most distros. And spinning up/down a hdd costs a lot of energy.

These issues should be solved in levels lower than GStreamer (like... the kernel ???).

As David warned, I'm closing this bug due to lack of maintainership.