maemo.org Bugzilla – Bug 1129
Media player doesn't save the timeposition on close for audio
Last modified: 2012-03-24 11:47:07 UTC
You need to
before you can comment on or make changes to this bug.
If I'm listening a long podcast and I need to close the media player or boot
device the position will be lost. So I suggest that there should be a way to
bookmark the position and continuing from the bookmark. Then I could also stop
listening an podcast and look an video and after that I could continue from
where I was before. To make it easy to implement there should be only one
bookmark per file/playlist and files which go missing would lose their
bookmarks. In the library there would be fourth icon for bookmarks and and
that would be the unfinished files/playlists.
Quim Gil added to CC-field
I wish to add that I have the same problem with video files. I watch my videos
on the bus and at similar locations on the go and usually have only a few
minutes to watch them.
My suggestion is not to use a manual bookmark feature. The media player should
remember the location on the file when the user last used "stop" or "close" and
should return to it.
The vdr (Linux video disk recorder) has done this in a very user-friendly way:
It always remembers locations and has a menu item to start the file from 0:00 again.
It would be nice if we could manually select the starting point from which to
resume viewing a long video too!
On vdr, the player resumes playback from a few seconds before the bookmark.
is very practical.
This strikes me as a fairly fundemental need in a media player.
Please consider the following proposal:
By default, save the timeposition of the media file whenever the user stops
playback or closes the media player. You might save the position in a .-file in
the same directory as the media file (e.g. ".feature-film.avi.pos").
When the user starts playback, the media player should look for the .-file and
resume playback from, say, 15 seconds before the stored position. (A new
position should not be stored when it is less than 15 seconds before a
previously stored position for the same file.)
*** Bug 1225 has been marked as a duplicate of this bug. ***
Picking this one.
I would also like to have this feature. This would be one of the features the
N800 needs to replace iPods. For playing podcasts (or listening to audio
books), this feature is really needed. I would also need it for playing long
To add my vote: this is clearly a MUST HAVE.
FYI: A GStreamer-based Resuming Audiobook/Podcast player is now available for
Chinook and Diablo: http://thpinfo.com/2008/panucci/
Thanks for the link to the resuming player but that player lacks any other
functionality (no 'rewind', 'fast forward' nor seeking despite the really
I would still like to see this feature coded into the existing Nokia media
player. On that note--has there been any attention on this feature from Nokia?
(In reply to comment #12)
> Thanks for the link to the resuming player but that player lacks any other
> functionality (no 'rewind', 'fast forward' nor seeking despite the really
> useful bookmarking.
Actually that's just a bug on first run. If you press the "Play" button while
it's playing, the audio will pause, if you resume (via the "Play" button)
again, the seeking buttons will become active again. The Double-arrows will
seek forward/backward one minute and the Single-arrows will do the same in 10
second steps. I've deliberately not included a seek bar, so one does not
accidentally move somewhere into the audiobook/podcast and have a hard time
coming back to the original position. You can still move pretty quickly (and
precise) with the seek buttons.
there are more issues with that program then just the seek bug. like say no
file history, or having to relaunch the program ech time one wants to listen to
a new file.
In Fremantle the media player will rememember the time position you left your
(In reply to comment #15)
> In Fremantle the media player will rememember the time position you left your
Will the media player be available for N8x0 devices/Diablo, too?
Just so that this feature isn't implemented partially in Fremantle: As the
original poster suggested, it would be nice to have a per-file time position
remember function, not just "open last file and resume playback from there"
(which is what the bug title suggests).
In the mean time, the player mentioned in comment #11 has been moved forward to
a complete open source project (http://panucci.garage.maemo.org/) which might
be helpful for Diablo users wanting that feature right now, or for N8x0 users
in general should Fremantle not be available for N8x0 devices :/
(In reply to comment #16)
> Will the media player be available for N8x0 devices/Diablo, too?
Too soon to tell. First we need to have Midas out (soon hopefully, and you will
be able to make it work in Diablo). Then let's have Fremantle alpha released
(before the end of the year).
> Just so that this feature isn't implemented partially in Fremantle: As the
> original poster suggested, it would be nice to have a per-file time position
> remember function, not just "open last file and resume playback from there"
> (which is what the bug title suggests).
This is what Midas should provide, yes.
I got more details about the implementation and in fact the whole
timepositioning will be dealt by Midas together with Meta Tracker (also open
source). This means that if you are unhappy about the details of the
implementation you can always propose a patch. :)
Resolvinf as fixed in Fremantle
(In reply to comment #19)
> Resolvinf as fixed in Fremantle
This is not really fixed for audio files in Fremantle's Media Player yet. Media
player does resume *Video* files quite nicely, but it does not yet work for
audio files (which the initial request was all about).
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)
Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).
There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates.
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
Please note: The Maemo CSSU project is not related in any way to Nokia.
( Tag for mass-deleting bugmail: [cleanup20120324] )