Also a nice idea.

yeah, saving them would be cool.

*** Bug 518711 has been marked as a duplicate of this bug. ***

ping.

maybe an option in plugins configuration, to automatically save them somewhere (and/or cache) when double clicking?

and drag'n'drop from results into desktop/directory...

I haven't had a chance to do any work on this, but I don't think automatically saving them's a good idea. Saving on drag'n'drop is good.

Note to self: see how this fits in with Wim's work on seeking YouTube videos.

*** Bug 525105 has been marked as a duplicate of this bug. ***

> I don't think automatically saving them's a good idea

Of course I mean downloading of results added to the playlist, not all results ;) .

I have another approach for what I want. When adding YT videos to playlist, they shouldn't be autoplayed, but buffered with little progressbar on playlist shown.

It's good for new feature request, since I made little off topic here.

Submitted: bug 527395.

PS: I'm silent beginning from now. EOOT (EndOfOffTopic)

*** Bug 539883 has been marked as a duplicate of this bug. ***

Created attachment 116199 [details] [review]
Add ability to save a video on localy

Here is a patch for implementing this feature. It adds a fourth option in the context menu called "Save as...".
By default the filename is the title of the video. In case the user select a file already existing, a confirmation dialog is displayed.

I think this is usable as it. However, I can see two possible improvement points:
* do the file retrieving in a background thread. I haven't found a way to keep the (python) thread running while no gtk event is occuring, and using idle_add() leads to 100% cpu usage. 
* by default propose to save in the "Video" directory (but I don't know how to do this independently of distro and locale)

Would be great to see this upstream.

> * by default propose to save in the "Video" directory (but I don't know how to
do this independently of distro and locale)

Read about XDG and bindings (pyxdg?).

Created attachment 116265 [details] [review]
Permit to save a video locally - update with correct default directory

This is an updated version of the patch, which display the file chooser by default in the same directory as the user last time opened a file. 

Jakub, thank you for the tip. Indeed XDG Base Directory Specification should give the correct info about the Video directory. Eventually, I found the "open_path" gconf key. It should fit even better the user, and this avoids to add a new dependency on totem :-)

The problem with this implementation is that it would conflict with playbin2's ability to create on-disk caches. I'll make this bug dependent on playbin2 for now, and see if we can generalise the saving of remote videos.

Hi Bastien, could explain more in what it would conflict with playbin2? This implementation simply download the file independently from what is happening in totem. While downloading a video, I can watch the same video or another video without any problem. I couldn't find much info about playbin2, and I can't find a reason why it would conflict with the implementation...

Once playbin2 is used by totem, we could make the implementation more clever and re-used on the on-disk cache instead of re-downloading the video. But that's only an enhancement.

Playbin2 can use an on-disk cache to provide YouTube style buffering for streams. So after playing the file back once, the full video would be available on the disk, saving it would be a matter of copying the buffer onto a new location.

I'd be happy to commit your patch as long as you made it more separate from the rest of the code so it can easily be ripped out when we get playbin2 support. Adding a few comments about that fact in the sources would also help.

Created attachment 124173 [details] [review]
Add "save as" for youtube videos

Here is an update of the patch. It's against latest svn revision.

In case of playbin2, the GUI part (menu + file-browser would stay as is), while the rest would be modified. I've added explicit comments about it in this later part.

Two problems I can see with that patch:
- We should also show the "Save as..." menu item in the Movie top-level menu, but only when playing videos from YouTube.
- I believe that we have a little problem with the video list widget, where the UI is shared, so adding a menu item to /ui/totem-video-list-popup would show it in all the plugins that use it (say MythTV or tracker). Am I wrong there?
- The progress should be a modal dialogue (so we can only download one stream at a time), and be cancellable.

(In reply to comment #19)
> Two problems I can see with that patch:
> - We should also show the "Save as..." menu item in the Movie top-level menu,
> but only when playing videos from YouTube.
I can have a try at it, but I don't know much about how to control the main menu, so it might take some time. That said, I think it can be implemented later on, and doesn't need to be present to add the feature to totem.

> - I believe that we have a little problem with the video list widget, where the
> UI is shared, so adding a menu item to /ui/totem-video-list-popup would show it
> in all the plugins that use it (say MythTV or tracker). Am I wrong there?
You probably know much more than me about this! I couldn't test the two other plugins you've cited. However, /ui/totem-video-list-popup is already used by the youtube plugin for "Opening in a browser", so I guess it's rather easy to check (and if there is a problem, it already exists).

> - The progress should be a modal dialogue (so we can only download one stream
> at a time), and be cancellable.
Yes, that's probably really the main problem in the current implementation. To fix it perfectly, it would require a complete implementation of a downloader (à la Firefox). I wish there could be a generic downloader utility in gnome, to which every applications could delegate all this work. Now, i'm not convinced by the modal dialogue because it would completely prevent the use of totem while downloading. What I can try to do is to disable the widgets of the youtube plugin while the downloading is in progress.

(In reply to comment #20)
> You probably know much more than me about this! I couldn't test the two other
> plugins you've cited. However, /ui/totem-video-list-popup is already used by
> the youtube plugin for "Opening in a browser", so I guess it's rather easy to
> check (and if there is a problem, it already exists).

The UI common to all TotemVideoLists is in data/video-list.ui, and doesn't include the "Open in Web Browser" entry, which is added in youtube.py:149. That's what you should do.

(In reply to comment #21)
> The UI common to all TotemVideoLists is in data/video-list.ui, and doesn't
> include the "Open in Web Browser" entry, which is added in youtube.py:149.
> That's what you should do.
Ah, great! "Save as" is added to the menu in exactly the same way as "Open in Web Browser" so with respect to this point, it should work fine :-)

Created attachment 125282 [details] [review]
Add "save as" for youtube videos

Here is a new version of the patch which disable the usage of the plugin while the video is downloading. It also handles exceptions while downloading, so that network errors don't block the plugin.

+		action = gtk.Action ("save-as", _("_Save as..."), _("Save the video locally"), "gtk-save-as")

The action's text should be "Save As..." (note the capitalisation).

+ 		dialog = gtk.FileChooserDialog(title=_("Save as"),

Similarly, the title should be "Save As...". Can you add spaces to the parameter initialisation too please? (e.g. "title = _(")

Also, there should be spaces after function names and before the opening bracket, for stylistic consistency. (e.g. "gtk.FileChooserDialog (")

+ 		while gtk.events_pending():
+ 			gtk.main_iteration()

You might want to add a comment (either here or above where you complain about threads in PyGTK :)) about this running in the main loop and manually dispatching pending events every so often. I'm not sure this is really the best way to do things, but it can be changed once this has been committed if it turns out to not perform well enough in real usage.

You might want to update the /apps/totem/open_path GConf key once a save location's been chosen.

To address the remaining issues from comment #19:
* You can use totem.get_ui_manager to get the GtkUIManager for the main window, which should allow you to add the Save As action to the main menu. Don't forget to remove it when the plugin's deactivated, or when the currently-playing URI is changed to a non-YouTube video.
* You should be able to cancel the download by throwing an exception in download_report_cb, then catching it in on_save_as_activated. This would mean redesigning the UI, though, so I'd be OK with this being done later, especially since it might be a good idea to add cancel functionality to the entire plugin (i.e. be able to cancel searches themselves) anyway.

Other than that, the patch looks good to me. Thanks for spending the time on this. :)

Now that we have on-disk buffering for QuickTime and FLV streams, this feature wouldn't be any different from saving the stream that's currently playing back.

*** This bug has been marked as a duplicate of bug 350261 ***

But can you save the same way a video which is not being played but only displayed in the playlist (as search result or related video)?