GNOME Bugzilla – Bug 164918
Remember current position when Pause is clicked
Last modified: 2009-11-09 22:22:04 UTC
This feature request comes from my girl friend, she's the most of a non-technical user as you can get. I'll try to write it up as a use case. Johanna (yup, actual name) watches a DVD. Halfway through, her mother reminds her she has to go to afternoon school. Johanna clicks "Pause" and shuts her computer down (she neither trusts "Save current session" nor Linux's software suspend feature, but those a different issues). When she comes back, she powers her computer back on again and opens Totem, which starts playing where it left off. Ten minutes later her little brother Sebastian comes along with a new DVD he just bought in the super market and demands it be put in. Johanna clicks "Pause" again and pops in Sebastians DVD. As he is a young buy, he prefers to take his DVD elsewhere half an hour later. Johanna clicks "Pause" again, knowing the he will want to continue watching when he comes back and goes on with her own DVD again. This would probably be called session management. Talking to "BBB" in #gstreamer I hear it is practically implemented and usable, but only turned on for Gnome sessions. You could tell me that Johanna should use these, apart from the case where you change DVDs within a Gnome session.
Hmm, that's a weird requirement, but QuickTime has something like that in the form of "cue points", but it has a weird UI. Essentially, we'd need to add a "bookmark" system where you can bookmark where you're currently at, and request the right CD/DVD/media when activating it. I don't think we should make a complicated bookmark system, but we could probably piggy back on the DND bookmarking system we have now.
That picture pretty much explains it: http://images.apple.com/macosx/features/dvdplayer/images/indexremembersb20050412.jpg It should also work for other disc types, and be foolproof, ie. it should also work with DVDs with broken labels, and such. Is there anything like a disc UUID on CDs/DVDs or when they have a filesystem?
*** Bug 301587 has been marked as a duplicate of this bug. ***
Hi, I'm pretty sure CDs/DVDs using iso9660 et. al. has a filesystem UUID but you can key this off the label or perhaps and md5/sha1 digest of the first few sectors (or the first few with data)? HAL uses the label to get the UDI of the device object representing the disc. HTH.
Bah, s/has a filesystem UUID/hasn't got a filesystem UUID/. Sorry.
*** Bug 359898 has been marked as a duplicate of this bug. ***
A think that the bug 39898 is not duplicate. When I sad "Open in last position" I was talking about the position of the window of totem. Not about the position of the movie. Please think again. Thanks
*** Bug 371962 has been marked as a duplicate of this bug. ***
*** Bug 393952 has been marked as a duplicate of this bug. ***
*** Bug 400913 has been marked as a duplicate of this bug. ***
*** Bug 447669 has been marked as a duplicate of this bug. ***
*** Bug 485651 has been marked as a duplicate of this bug. ***
I've reported Bug 485651 The present bug seems to refer to movies on discs. My point, quite similar, is about loading movies-files (.avi, .xvid, etc.) in Totem : When i load a PDF file in Evince, start the reading, close Evince and reload the PDF file, Evince shows the document page where i've stopped the reading and not the begining of it. I'd like Totem to behave the same way, remembering the moment when i stopped watching the movie, instead of behaving like Dory in Finding Nemo...
*** Bug 504481 has been marked as a duplicate of this bug. ***
I've made a similar report for bug 504481 http://bugzilla.gnome.org/show_bug.cgi?id=504481 But I think the bookmark system should be identical to the way a web browser works for consistency. Alternatively, the recent documents menu could launch it's recent files from the point they were left off at.
*** Bug 519403 has been marked as a duplicate of this bug. ***
from comment # 1 : "I don't think we should make a complicated bookmark system, but we could probably piggy back on the DND bookmarking system we have now." The feature that would allow Totem to automatically remember the point when the user stopped watching a movie (on a disc or in a file) should add no complication to the GUI and should be completly transparent like in OOo, Evince or Tomboy cases (the document is displayed at the page where the user stops his reading) : The user is watching a movie, stops his watching after one hour and closes his session. Later, he reloads the same movie and Totem start again automatically the movie at the same position (after one hour) (or Totem asks the user if he wants to start again at the same point than before) It's the application of the Persistence concept http://en.wikipedia.org/wiki/Persistence_(computer_science) Bookmarks doesn't seem useful to me if the feature above is implemented (and i'd love that)
i'm not sure how does GSOC works but having totem remembering when the movie was stopped before could be a GSOC project ?
Created attachment 127502 [details] [review] proof of concept for saving position with GtkRecent Here's a proof of concept patch (against trunk r5939) for saving the current position by using GtkRecent. It works as follows: - Don't save the recent item when starting playback of a file, but when the user closes the window. - Add a "--seek N" argument to the app_exec of the GtkRecentData where N is the current time. - When a new file is loaded, look up the MRL in the GtkRecentManager (which is a hash lookup and so shouldn't be slow) and if it exists, extract the seek time from the app_exec and store it in seek_to. - Later, Totem will seek to this time and pause the video. There is a threshold of 10 minutes, so the position is only saved for video/audio files longer than that. Also, right now it only works when closing Totem, not yet when the playing file is replaced by another one. And there seems to be an issue with GtkRecent in that it doesn't write the data immediately and so when you reopen Totem too fast, the new recent info won't be available. Using GtkRecent has some advantages such as not having to care about cleanup/file management and not duplicating efforts. On the other hand, it's kind of hacky. What do you think?
(In reply to comment #19) > Using GtkRecent has some advantages such as not having to care about > cleanup/file management and not duplicating efforts. On the other hand, it's > kind of hacky. What do you think? Well, how does Evince do it?
(In reply to comment #20) > (In reply to comment #19) > > Using GtkRecent has some advantages such as not having to care about > > cleanup/file management and not duplicating efforts. On the other hand, it's > > kind of hacky. What do you think? > > Well, how does Evince do it? It uses libxml to write a custom XML file to ~/.gnome2/evince/ev-metadata.xml and serializes the data "by hand". It stores additional metadata for documents such as the sidebar size or whether the window was maximized. The code is in shell/ev-metadata-manager.c.
*** Bug 572915 has been marked as a duplicate of this bug. ***
How about using GBookmarkFile and including the "--seek N" parameter in the exec value when calling g_bookmark_file_set_app_info ()? Seems a little less hacky than including it in the recent files list. That does mean we have to deal with an extra configuration (bookmark) file, but it shouldn't be that bad.
We could: 1) Write in the recent files only when pause is clicked 2) Use another group for it Note that this won't work with DVDs, which was the original request, but it would require some changes in the backends to work with DVDs anyway.
(In reply to comment #24) > We could: > 1) Write in the recent files only when pause is clicked The user would always have to remember to click pause if the position should be saved and some users would probably think it's a bug that "sometimes" the position is saved and sometimes not. Why not save the position when the video is stopped because the window is closed or another video is started? > 2) Use another group for it You mean using a group like "Totem position 3600" to save the time? Yes, I think that is cleaner than including it in exec. And in http://live.gnome.org/RecentFilesAndBookmarks it seems that groups were also intended for saving additional metadata/tags. > Note that this won't work with DVDs, which was the original request, but it > would require some changes in the backends to work with DVDs anyway. For DVDs we could set the is_private flag of GtkRecentData, that way they shouldn't be displayed in the recent files menu. And we could use an MRL with some kind of DVD ID as the URI.
*** Bug 582432 has been marked as a duplicate of this bug. ***
Created attachment 135635 [details] a "Resume position" python plugin
Today I tried coding a small python plugin for saving and resuming the file's position. The current version saves the position only when you close the Totem window (I could not find a nice way to get the current time while stopping the file..).
Created attachment 135640 [details] a "Resume position" python plugin
thank you that would be great to have the functionality within Totem
(In reply to comment #28) > Today I tried coding a small python plugin for saving and resuming the file's > position. I have worked on the same functionality for several days, and coded the "resume-playback" plugin (implemented in C, store info about all non ended played files (except DVD)). Believe it will be useful.
Created attachment 136911 [details] [review] totem-resume-playback plugin
iliya: I haven't taken a look at your plugin; it should get looked at when somebody takes the time to review all our options for fixing this bug. Another option (one which I quite like the look of) is to store the current position as a file attribute using gvfs: http://blogs.gnome.org/alexl/2009/06/24/data-about-data/ This means the position would persist even if the file's moved around your system, and could be shared between video players if named according to a cross-desktop standard.
(In reply to comment #33) > iliya: I haven't taken a look at your plugin; it should get looked at when > somebody takes the time to review all our options for fixing this bug. > > Another option (one which I quite like the look of) is to store the current > position as a file attribute using gvfs: > http://blogs.gnome.org/alexl/2009/06/24/data-about-data/ I like that. I like it so much that I thought of it when I started reading the bugmail, just before I got to your paragraph. Certainly better than overloading the recent files, or using yet another data store. I think Robin's patch but using the nautilus-metadata as the store would suit me fine. Needs a little option in the UI though.
(In reply to comment #33) > Another option (one which I quite like the look of) is to store the current > position as a file attribute using gvfs: > http://blogs.gnome.org/alexl/2009/06/24/data-about-data/ Yes, I also thought about that while reading the blog entry. But what to do with DVDs? Maybe one can attach metadata to the root directory of the DVD mount?
It would be great if not only the position was saved, but also the choice of subtitle and audio track.
(In reply to comment #35) > (In reply to comment #33) > > Another option (one which I quite like the look of) is to store the current > > position as a file attribute using gvfs: > > http://blogs.gnome.org/alexl/2009/06/24/data-about-data/ > > Yes, I also thought about that while reading the blog entry. But what to do > with DVDs? Maybe one can attach metadata to the root directory of the DVD > mount? DVDs was always going to be tricky anyway, we can't save the state machine, so any tricks that we might have done wouldn't have worked. Attaching the metadata to the root directory would probably work just as well... It could also be implemented slightly differently, in giosrc as a method signal for example, so rhythmbox would get that feature for nearly free. Sebastian, what do you think?
*** Bug 583236 has been marked as a duplicate of this bug. ***
please take a look here for some ideas: http://bugzilla.gnome.org/show_bug.cgi?id=583236 (bug was closed, but few of my notes can be usefull)
Created attachment 138691 [details] [review] totem-save-pos.patch Patch from Philip, with some fixes by me. Currently use xattrs (so you'd need to make sure the filesystem on which the file is supports xattrs to test it). Will be switched to metadata:: when committing though. The only thing missing as far as I'm concerned is a preference being added. Robin, want to go the last mile?
(In reply to comment #40) > The only thing missing as far as I'm concerned is a preference being added. > Robin, want to go the last mile? Note that the preference should be a simple boolean value; the user doesn't need to choose the threshold length of streams for saving positions.
I'd like to finish the patch, but xattrs don't seem to work here. The position is saved and I can see it with "gvfs-info -a 'xattr::*'". But when Totem tries to read it, the result is just NULL and when I read the type with g_file_info_get_attribute_type, it's 0 (invalid). Any ideas what might be wrong?
g_file_info_get_attribute_type()? Why do you need to use that function? xattrs are strings, and only strings. The code I posted definitely works in my cursory testing. Or did you mean that g_file_info_get_attribute_string() fails?
g_file_info_get_attribute_string returns NULL and g_file_info_get_attribute_type which should return that it's a string returns 0.
(In reply to comment #44) > g_file_info_get_attribute_string returns NULL and > g_file_info_get_attribute_type which should return that it's a string returns > 0. What's the error if any? What are the actual retvals of gvfs-info -a 'xattr::*'? If you have a 2.27 gvfs, you might as well switch to using metadata:: instead.
There's no error. gvfs-info lists the number nicely, so it seems to be saved correctly. I tried getting the 2.27 gvfs to work, but somehow the metadata DBus service doesn't want to work.. But I'll try to add the preference checkbox nonetheless. It has to be done before feature freeze on Monday right?
(In reply to comment #46) > But I'll try to add the preference checkbox nonetheless. It has to be done > before feature freeze on Monday right? Yes.
Created attachment 139241 [details] [review] totem-save-pos.patch with preference Here's totem-save-pos.patch with the preference checkbox added. Also note that I changed the metadata key from metadata::Totem.Position to metadata::totem::position as it seems that's more in tune with the other file attributes which already exist and it also seems to be what Alex suggests in his blog post. Does anyone have a better label for the preference checkbox than "Remember playback position"? Something a bit longer and more descriptive maybe?
Fixed, yay! I tweaked the preference checkbox label a little. commit 454c33d8762e8ed313994ebdf4f8b821596dd80c Author: Robin Stocker <robin@nibor.org> Date: Sun Jul 26 18:22:03 2009 +0100 Bug 164918 – Remember current position when Pause is clicked Add functionality to remember the current position of a stream when pausing or closing, by saving it in a GIO metadata attribute. Closes: bgo#164918 data/totem.schemas.in | 11 ++++++ data/totem.ui | 70 ++++++++++++++++++++++++++++++++++++ src/totem-object.c | 27 ++++++++------ src/totem-preferences.c | 42 ++++++++++++++++++++++ src/totem-private.h | 1 + src/totem-uri.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++ src/totem-uri.h | 3 ++ 7 files changed, 232 insertions(+), 12 deletions(-)
i can't wait to try this, many thanks !
maybe i missed something i'm running ubuntu 9.10 alpha 5 up to date (GNOME 2.27.91) I've downloaded & launched that video http://blip.tv/file/get/Framasoft-bien_commun_assaut_final350.ogv I've closed Totem while watching the video and reopened Totem and then the video (from the Film menu) and the video started from the beginning. i thought that the expected behaviour was that the video should have keep on from the moment when it stopped besides i didn't find any preference checkbox
(In reply to comment #51) > maybe i missed something <snip> > besides i didn't find any preference checkbox Then that means you don't have a new enough Totem.
(In reply to comment #52) > Then that means you don't have a new enough Totem. Bastien, has there been new a 2.27 release since the feature was committed? The newest tag I see in git is V_2_27_2.
(In reply to comment #53) > (In reply to comment #52) > > Then that means you don't have a new enough Totem. > > Bastien, has there been new a 2.27 release since the feature was committed? The > newest tag I see in git is V_2_27_2. Nope, will do a release now, too much procrastination.
What happens in the following case: I watched a file and stopped in the middle. Next time I open it and watch it to the end. What happens when I open it again? It should play from the start, but right now it will probably continue from the middle again. This is because we don't delete the position when we reach the end of the movie (or close it at the 5 % end). Bastien, can you confirm this?
Created attachment 143066 [details] [review] Remove a stream's saved position when we reach the end You make a good point. The attached *untested* patch should fix the problem. I can't test it, since my GVfs is completely broken. It unsets the attribute if the stream is not live and either too short, or within 5% of the end. It also converts the code from using g_file_set_attribute() to g_file_set_attribute_string(), just to make things a little clearer.
We don't have to unset the attribute if the stream is too short, right? Because then we would not have saved the position in the first place.
(In reply to comment #57) > We don't have to unset the attribute if the stream is too short, right? Because > then we would not have saved the position in the first place. We don't, but it doesn't matter if we do, so I saved the addition of another condition in the code by unsetting the attribute even if the stream is too short.
True. The patch looks good to me, though I can't test it either at the moment.
i was thinking of the implementation of that cool feature : Do we need to have an option to tick in Preferences menu or should we consider other things ? Having to set it in the Preferences menu has a few drawbacks : to start, i can't decide on a case by case basis. We could have imagine other implementations : 1°) Totem could be smart and guess by itself if the feature is needed : a) For instance if the user starts a video from the recent files list, he'd probably like to see the video from last position. In other cases he'd probably like to see the video from the beginning. Question : what if the user starts the video from Zeitgeist ? b) or if the video has been partially watched only some days ago, the user would probably like to see the video from last position. In other cases he'd probably like to see the video from the beginning. 2°) User could decide by itself if he wants Totem to remember on a case by case basis. A dedicated option could be added to the menu or tool bar which would allow user to save the current position of the current video. There would be no need to create a restore GUI : next time the user starts the video, Totem would starts from the last position (and delete the position for for the future). Only a few ideas, nothing more. Thanks for the feature
Why do the bookmarking on pause ? It would make much more sense to do it the evince way, when the file is closed. As it is, it's kinda hard to tell how it's supposed to behave. It would also be nice to be able to keep the position on crashes (simple example : laptop battery runs off). I also noticed (Ubuntu alpha 5) that this has the side effect of playing audio for a fraction of second, which is very unpleasant. I guess it has to do with the way it's implemented : seek then pause. Maybe do the reverse ?
Bastien, do we want to get that last patch in before 2.28, or can it wait? (In reply to comment #61) > Why do the bookmarking on pause ? It would make much more sense to do it the > evince way, when the file is closed. As it is, it's kinda hard to tell how it's > supposed to behave. The position is also saved when the file is closed. > It would also be nice to be able to keep the position on crashes (simple > example : laptop battery runs off). How often do laptop batteries run out without you getting notified plenty of time in advance? It's never happened to me. > I also noticed (Ubuntu alpha 5) that this has the side effect of playing audio > for a fraction of second, which is very unpleasant. I guess it has to do with > the way it's implemented : seek then pause. Maybe do the reverse ? Would you mind filing a separate bug about that? Thanks.
> > Why do the bookmarking on pause ? It would make much more sense to do it the > > evince way, when the file is closed. As it is, it's kinda hard to tell how it's > > supposed to behave. > > The position is also saved when the file is closed. It isn't here, both with the version shipped in ubuntu alpha 6 and latest svn. Should I file a bug report for this too ? > > > It would also be nice to be able to keep the position on crashes (simple > > example : laptop battery runs off). > > How often do laptop batteries run out without you getting notified plenty of > time in advance? It's never happened to me. That is probably a bad example. But if something goes wrong, either in totem or some other component (kernel, X, audio ...), or just a plain power outage on a desktop, it would be good to be able to keep the position. Is that feasible, or is it too much trouble ? > > I also noticed (Ubuntu alpha 5) that this has the side effect of playing audio > > for a fraction of second, which is very unpleasant. I guess it has to do with > > the way it's implemented : seek then pause. Maybe do the reverse ? > > Would you mind filing a separate bug about that? Thanks. Done, https://bugzilla.gnome.org/show_bug.cgi?id=595584
Is this a part of Totem with GNOME 2.28 or not? Attempts must be made to get it included in. Also IMHO the behaviour should be just like evince ie do the save automatically when the movie is closed either automatically like shutdown,battery finished or by the user. Having the user always click pause to save is a very bad idea and also defeats the purpose of this plugin. The save should be automatic and seamless.
(In reply to comment #1) > Hmm, that's a weird requirement, but QuickTime has something like that in the > form of "cue points", but it has a weird UI. As someone who watches a lot of movies and documentaries and serials etc, I can tell you this is not at all a wierd requirement. And would actually be a very good feature to have.
Comment on attachment 143066 [details] [review] Remove a stream's saved position when we reach the end Patch committed which prevents the situation described in comment #55, and also stops positions being saved if we're close to the beginning of the file. commit 72ef4e734960ebeb1b34a39320e3921cc1a3f103 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Mon Sep 21 16:49:04 2009 +0100 Bug 164918 — Remember current position when Pause is clicked Fixes a case where the position of a stream would be remembered if you paused and closed Totem, then reopened Totem and played the stream to the end. Next time you opened Totem, the old saved position would be used. Also prevents stream positions from being saved if the position is within a given percentage (of the stream length) of the start of the file. Re-closes: bgo#164918 src/totem-uri.c | 34 ++++++++++++++++++++++------------ 1 files changed, 22 insertions(+), 12 deletions(-)
(In reply to comment #63) > > > Why do the bookmarking on pause ? It would make much more sense to do it the > > > evince way, when the file is closed. As it is, it's kinda hard to tell how it's > > > supposed to behave. > > > > The position is also saved when the file is closed. > > It isn't here, both with the version shipped in ubuntu alpha 6 and latest svn. > Should I file a bug report for this too ? It's working for me, so could you try with Totem 2.28 (once it's released later today) and file a bug if it isn't working please? Thanks. > > > > > It would also be nice to be able to keep the position on crashes (simple > > > example : laptop battery runs off). > > > > How often do laptop batteries run out without you getting notified plenty of > > time in advance? It's never happened to me. > > That is probably a bad example. But if something goes wrong, either in totem or > some other component (kernel, X, audio ...), or just a plain power outage on a > desktop, it would be good to be able to keep the position. Is that feasible, or > is it too much trouble ? Could you also file a bug about this please? (In reply to comment #64) > Is this a part of Totem with GNOME 2.28 or not? Yes.
(In reply to comment #67) > (In reply to comment #63) > > > > Why do the bookmarking on pause ? It would make much more sense to do it the > > > > evince way, when the file is closed. As it is, it's kinda hard to tell how it's > > > > supposed to behave. > > > > > > The position is also saved when the file is closed. > > > > It isn't here, both with the version shipped in ubuntu alpha 6 and latest svn. > > Should I file a bug report for this too ? > > It's working for me, so could you try with Totem 2.28 (once it's released later > today) and file a bug if it isn't working please? Thanks. Make that 2.28.1. 2.28.0 was released earlier today.
https://bugzilla.gnome.org/show_bug.cgi?id=595847 for auto /manual closing of totem and remembering position.
It works perfectly fine with 2.28.
(The "remember position" feature for DVDs is now tracked in bug 601321.)