GNOME Bugzilla – Bug 430151
Audio recording inhibits save to file dialog
Last modified: 2018-07-02 10:50:51 UTC
Please describe the problem: When audio recording is activated, the file saving dialog window is not displayed when recording is finished and Istanbul is lost in a random state. Steps to reproduce: 1. activate audio recording 2. start recording 3. stop recording Actual results: The status icon changes to a hard disk. Expected results: The status icon should change to a hard disk and a file chooser window should appear. Does this happen every time? Yes Other information: Patch following.
Created attachment 86405 [details] [review] Patch fixing the issue It works for me. (tm) A lost clock message is passed on the gstreamer bus and not an end of stream. Do not ask me why :/
That is a big hack of a patch! My guess is the oggmux GStreamer element is not handling eos correctly sometimes. We have had this issue with the flumotion transcoder before and Wim said that oggmux needs a rewrite.
I agree. What should be done in the meantime for end users of Istanbul ?
Very good question, will investigate whether your hack makes sense to use as a workaround.
Your hack is not a correct workaround. But a 30 second timeout may be suitable.
Bad workaround or not, either way, it would be nice if this were fixed. :/ [Confirming because I'm seeing the same behavior in 0.2.2, and marking major because this means that the entire feature doesn't work.]
FWIW, the patch works (so thanks, Florian!), but I can see why a patch that is effectively 'ignore an error condition' is not acceptable ;)
Ok, maybe, more than criticism about the current proposed patch, it can be useful to propose the other way (the one that be good). I can confirm the bug remain, even with latest svn fetching (checked since 10 minutes). I can also confirm using the patch from Florian as workaround work properly under Ubuntu/Gutsy. A++
*** Bug 505471 has been marked as a duplicate of this bug. ***
*** Bug 418841 has been marked as a duplicate of this bug. ***
Ok, I have committed this patch in [172] but not happy with resolving this bug, because underlying bug still remains.
has there been any progress on this bug?
Review of attachment 86405 [details] [review]: where are the instructions to use this patch. Does this file replace screencast.py or is it screencast.py patched by it. We are not all highbrow and to pretend otherwise or make people ask is just showing off.
(In reply to comment #13) > Review of attachment 86405 [details] [review]: > > where are the instructions to use this patch. Does this file replace > screencast.py or is it screencast.py patched by it. > We are not all highbrow and to pretend otherwise or make people ask is just > showing off. Isn't that quite obvious? The file is a patch. So it is supposed to be applied to the istanbul source code. (Preferably using the "patch" command line tool.)
istanbul is not under active development anymore and has not seen code changes for eight years. Its codebase has been archived: https://gitlab.gnome.org/Archive/istanbul/commits/master See https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html for screencast video options that are available in GNOME 3. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.