GNOME Bugzilla – Bug 172389
Extra Prefetching
Last modified: 2018-05-24 10:43:10 UTC
On many systems such as laptops, spinning the disk is expensive in terms of power. On my desktop, which is playing lots of music, I have an issue with heat and hard disks. Rhythmbox should prefetch enough data from disk to fill a buffer of a given set length. When that buffer is no longer filled, i.e. below 5% usage, the process should repete atomically to fill to 100%. This should precalculate shuffle and even bring in parts of files if the whole file doesn't buffer (think 100 minute MP3). No idea how this'd work; most stuff relies on streaming from disk, not memory. Gstreamer may be smart enough though. . . Definitely don't pre-decompress it!
*** Bug 138818 has been marked as a duplicate of this bug. ***
*** Bug 148820 has been marked as a duplicate of this bug. ***
*** Bug 157890 has been marked as a duplicate of this bug. ***
Agreed, this makes sense. It'd cause more hdd activity if you decide to play something else on a whim, but if it could preload a certain amount of kb/mb for the current and next song, that should reduce hard drive seeks. However, just blindly pre-reading "one song" would not do, since if that song is a .flac it'd could take quite a bit of RAM
well prefetching what whould be played starting now to some end time, end time would be limited by buffer memory... and buffer memory must be configurable (at least via some gconf key)... unfortunately that would all mean to not only focus on the current song to be prebuffered but also on the upcoming songs up to some point. so I am not sure one would really want to do this as this is just an enhancement... if you look at #157890 (which was made a duplicate of this bug here) it should become clear that buffering is not an enhancement but needed for continuous sound playing over slow / unreliable media... so this bugs severity would be normal or larger even. Also one would need to prebuffer only parts of the current song... and the buffering strategy would be different, i.e. one would always try to keep the buffer filled to the max... if it drops <90% -> read ... (mplayer is exactly doing that, has anyone checked what xmms is doing?) so we would need two settings here: buffersize & bufferthreshold which would be >60M , 1% for this bug and 500k, 90% for #157890
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/60.