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 529300 - [giosink] [PATCH] Allow overwrite
[giosink] [PATCH] Allow overwrite
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-22 00:03 UTC by Michael Terry
Modified: 2009-07-08 14:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (4.70 KB, patch)
2008-04-22 00:03 UTC, Michael Terry
needs-work Details | Review
Overwrite using property (3.59 KB, patch)
2008-04-23 23:11 UTC, Michael Terry
needs-work Details | Review

Description Michael Terry 2008-04-22 00:03:12 UTC
Attached is a patch to allow the use of g_file_replace if appropriate.  It is modelled after gnomevfssink's support for same.

Namely, giosink emits a signal asking if it can overwrite the file.  If yes, it uses g_file_replace.
Comment 1 Michael Terry 2008-04-22 00:03:41 UTC
Created attachment 109663 [details] [review]
Proposed patch
Comment 2 Sebastian Dröge (slomo) 2008-04-22 07:46:24 UTC
Hi,
something like this is definitely needed but it was decided that it is a bad idea to emit signals from the elements to query the application for information.

The signal is emitted from a random thread and the application has to care about proper dispatching to the thread running the Gtk main loop for example and then can show a dialog and has to dispatch the result back to the other thread.

What we need is a general mechanism for asking the application for information... probably something going over the bus like a message with a new flag to mark it as requiring an answer, add a gst_element_post_message_with_reply() that waits until a reply is there (or a timeout happend?), etc...
Comment 3 Michael Terry 2008-04-23 23:11:19 UTC
Created attachment 109791 [details] [review]
Overwrite using property

Fair.  Would you accept this patch, which uses a property to set the default overwrite behavior?  For my needs (sound-juicer's port to gio), this is sufficient.  And it doesn't preclude one day having the more powerful 'asking' behavior.
Comment 4 Jonathan Matthew 2008-12-06 22:40:25 UTC
The approach I took in rhythmbox was to create the output stream myself and use a giostreamsink, rather than letting giosink do it.  This way, if g_file_create returns a G_IO_ERROR_EXISTS error, we can ask the user if they want to overwrite and then use g_file_replace to create the stream.  Once this is all done, we set the 'stream' property on the sink element.  This all takes place during pipeline setup, so there's no need for communication between app and streaming threads.

See the attach_output_pipeline function here: http://svn.gnome.org/viewvc/rhythmbox/trunk/backends/gstreamer/rb-encoder-gst.c?view=markup

Comment 5 Sebastian Dröge (slomo) 2009-07-08 13:59:38 UTC
IMHO the best fix would be a custom element message posted on the bus. Applications can catch that and ignore the following error message, delete the old file and then start the pipeline again.
Comment 6 Sebastian Dröge (slomo) 2009-07-08 14:57:51 UTC
This has to be handled similar to missing plugins, i.e. if the message is on the bus ignore all error messages, do something (remove the file, use a different location) and then the pipeline can simply be started again.

commit 6025412707d687bd8e1b3117409662a16c877258
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed Jul 8 16:55:41 2009 +0200

    gio: Post a custom file-exists message on the bus if the file already exists
    
    An application can handle this message, remove the file in question
    and restart the pipeline again without showing an error.
    
    This fixes bug #529300.