GNOME Bugzilla – Bug 708660
Screencasts limited to about 30 seconds
Last modified: 2016-08-11 21:49:01 UTC
Description of problem: When I make a screencast, it switches off by iteslf in about 30 seconds. Version-Release number of selected component (if applicable): gnome-shell-3.9.92-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1.ctrl alt R to start recording 2.just, do stuff 3. Actual results: after about 30 seconds, the recording icon disappears and the recording stops Expected results: shouldn't stop. I should be able to hit ctrl alt R again to make it stop Additional info: No errors in journalctl: [asinha@ankur Videos]$ journalctl /usr/bin/gnome-session --since "2013-09-23 15:00:00" --no-pager | egrep Recording Sep 23 18:04:26 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 23-09-13 18:04:26.webm Sep 24 14:56:57 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 24-09-13 14:56:57.webm Sep 24 14:57:30 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 24-09-13 14:57:30.webm Sep 24 14:58:06 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 24-09-13 14:58:06.webm Sep 24 15:02:40 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 24-09-13 15:02:40.webm Sep 24 15:03:21 ankur.pc gnome-session[1185]: Recording to /home/asinha/Videos/Screencast from 24-09-13 15:03:21.webm [asinha@ankur Videos]$ ls Screencast\ from\ 24-09-13\ 1* Screencast from 24-09-13 14:58:06.webm Screencast from 24-09-13 15:02:40.webm Screencast from 24-09-13 15:03:21.webm Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1011320 (Also has three recording attachments if required)
This is intentional behavior.
Er. Could you clarify why this is so? Is this a temporary change, or a permanent one? It'll be better to remove this functionality from the shell completely and force users to install another too right to begin with, won't it?
We've never advertised screencast functionality; it was always a little easter egg meant for developers to show off bugs they found in gnome-shell or in apps. It's not meant for professional screencasting or similar. If you want to record a full screencast, you can do it with the command line like: $ gdbus call --session --dest org.gnome.Shell.Screencast --object-path /org/gnome/Shell/Screencast --method org.gnome.Shell.Screencast.Screencast my_screencast.mkv {} This should record a screencast until you hit ^C without any 30 second time limit.
(In reply to comment #3) > We've never advertised screencast functionality; This is no reason to break it (make it useless for pretty much any serious use). > it was always a little easter > egg meant for developers to show off bugs they found in gnome-shell or in apps. You can still do that with the old behavior just stop the recording once you are done demonstrating your bug. > It's not meant for professional screencasting or similar. It has many use cases it is not a bug reporting tool. > If you want to record a full screencast, you can do it with the command line like: [...] If you want to do a 30 second screencast just stop after 30 seconds. So please revert that change.
I'm also a big fan of the awesome screencast feature and I'm disappointed to see this change. Is the purpose of this to prevent users who don't know what they're doing from filling up their hard disk with massive screencasts? (If not, what is it?) I hope there can be another solution; maybe display a warning notification after a recording has lasted n seconds? (Probably something much longer than 30s, I would think)
Jasper can answer the reasoning behind the 30 secs limit.
Created attachment 255641 [details] [review] media-keys: Remove screencast limit Commit 1ae70dc6 has limited the screencasts to 30 seconds having a specific use case (short casts for bug reports) in mind. This breaks a lot of other valid use caes so revert this change and go back to the toggle behaviour that we had before. A user that wants to do a short cast can simply stop after a short duration while one that wants to do a longer cast can simply leave it running. Given that both cases are not mutally exclusive there is no reason to hardcode a time limit in the code that severely limits the usefullness of the recorder.
(In reply to comment #6) > Jasper can answer the reasoning behind the 30 secs limit. Neither the bug (https://bugzilla.gnome.org/show_bug.cgi?id=704435) nor the commit message even talks about this change. If it did I would have commented earlier ... I though the bug was just about moving the keybinding to gsd not about crippling it like that. I don't only disagree with the change as such ... I also dislike the way it was made.
I don't think we want to revert this change. It was discussed for a long time. I'm sorry that the commit that made the change didn't refer to any of that. Some of it may be found here: https://wiki.gnome.org/GnomeOS/Design/Whiteboards/ScreenRecording The feature is not designed to replace screencasting apps. Those apps should have the facility to trim and edit longer recordings. This is narrowly focused (like the screenshot tool) to serve the need for us get short clips that demonstrate bugs. Clips that are small enough to upload easily and not need a separate app for trimming or editing. Clips that are long enough to demonstrate exactly one problem. Clips that may be made using a fire and forget hotkey without the need for watching the clock or fumbling to turn the video off. Clips that if accidentally triggered won't fill up the disk. There is surely room for improvement. We probably want to do something better with the recording status indicator. Perhaps a progress meter, perhaps an OSD before the recording starts in order to give better feedback - especially in case of an accidental trigger. We may want to consider a second press of the key combination to add time to the recording - like a +30 button on a microwave oven. It is a separate issue if we want to allow screencast applications to use the shell recorder as an implementation detail to perform recordings of unbounded length. However, that does not mean we want the entry point for that to be the hotkey triggered clip recorder.
(In reply to comment #9) > I don't think we want to revert this change. It was discussed for a long time. You have mentioned it a couple of times on IRC but we never really had a discussion. Pretty much all other screencasting solutions suck for various reasons ... so lets not break the only one that actually works without having a replacement. > I'm sorry that the commit that made the change didn't refer to any of that. Yeah indeed we shouldn't sneak in changes that way. How can a "lets move this to another component" turns out to be "move this *and* limits its usefulness for lots of valid use cases". > Some of it may be found here: > https://wiki.gnome.org/GnomeOS/Design/Whiteboards/ScreenRecording "Record a short video of the entire screen" is all that is on that page ... > The feature is not designed to replace screencasting apps. Actually the feature has not really been "designed" at all. So it wasn't designed to be a bug reporting tool either. > Those apps should > have the facility to trim and edit longer recordings. This is narrowly focused > (like the screenshot tool) to serve the need for us get short clips that > demonstrate bugs. This was possible with the old way as well. I don't see a reason why we suddenly must restrict it like that? Are there any bug reports or any other reports of the old one being problematic due to the length? I mean we had it since 3.0 and I didn't see any single report in that direction (and I do pay attention to recorder bug reports). > Clips that are small enough to upload easily and not need a > separate app for trimming or editing. You shouldn't have to. Just start recording reproduce your bug and stop. > Clips that are long enough to demonstrate > exactly one problem. why? > Clips that may be made using a fire and forget hotkey > without the need for watching the clock You don't have to watch the clock once you are done demonstrating your problem (or whatever else you want to record) stop it. > There is surely room for improvement. Indeed but I don't really see this particular change as an improvement at all. > We probably want to do something better > with the recording status indicator. Yes one solution to the "forget" thing would have been for instance to change the look of the indicator. Make it bigger so that it can not be easily forgotten or something else. We could have had this discussion and come up with something that's better. But we didn't because of the way the change has been made. That alone is reason enough for reverting it and have the discussion now, come up with a proper solution and implement it for 3.12. > Perhaps a progress meter, perhaps an OSD > before the recording starts in order to give better feedback - especially in > case of an accidental trigger. We may want to consider a second press of the > key combination to add time to the recording - like a +30 button on a microwave > oven. Well this is even worse if you miss the "deadline" you will end up with multiple videos ... > It is a separate issue if we want to allow screencast applications to use the > shell recorder as an implementation detail to perform recordings of unbounded > length. That's possible but that's not the issue here. We don't have any such app. We have made our only working recording solution to be only useful for a very limited use case (there aren't even that many bug reports with screencasts attached).
Funny story: I ran into this limit while trying to make a screen cast to report a bug against evolution. Screencasting is generally done in two phases: - record your stuff - chop/edit/add effects and whatnot. For example, pitivi does not record the video for you. It's a video *editor*. If the gnome shell recorder isn't causing any usability issues, I request you to please let it be as it were. As drago said, you can work on improving it's interface etc., but please do not break this functionality. It's really good to have, and a lot of users that know of it will be disappointed when they hit the 30 second limit.
The functionality still works in gnome-shell, why doesn't someone work on writing a screencasting application instead?
(In reply to comment #12) > The functionality still works in gnome-shell, why doesn't someone work on > writing a screencasting application instead? Because nobody got informed about any change. It got sneaked in an unrelated commit. So we ended up noticing that it got crippled two days before release ...
(In reply to comment #13) > (In reply to comment #12) > > The functionality still works in gnome-shell, why doesn't someone work on > > writing a screencasting application instead? > > Because nobody got informed about any change. It got sneaked in an unrelated > commit. So we ended up noticing that it got crippled two days before release > ... And that aside ... just pressing a keyboard combo is way more convenient than starting an app a dedicated app. It worked fine before (even for the use case Jon wants to optimize for). So we just "fixed" a problem that did never exist (see my comment re bug reports / complaints).
Created attachment 255712 [details] [review] media-keys: Use a gsettings key for the length Don't hardcode an arbitary 30 seconds limit. --- <mclasen> drago01: I guess I could be convinced to make the maximum time configurable This does not revert it but instead adds atleast a bit of flexibility.
*** Bug 708995 has been marked as a duplicate of this bug. ***
Review of attachment 255712 [details] [review]: ::: data/org.gnome.settings-daemon.plugins.media-keys.gschema.xml.in.in @@ +184,3 @@ + <default>30</default> + <_summary>Maximum length of screen recordings</_summary> + <_description>The maxmimum length of single screen cast recordings in seconds</_description> "Maximum". What happens with 0? ::: plugins/media-keys/gsd-media-keys-manager.c @@ +585,3 @@ + GsdMediaKeysManager *manager) +{ + manager->priv->screencast_length = g_settings_get_int (settings, "max-screencast-length"); Just call g_settings_get_int when adding the timeout. @@ +2034,3 @@ NULL, NULL); + manager->priv->screencast_timeout_id = g_timeout_add_seconds (manager->priv->screencast_length, What happens with 0?
Review of attachment 255641 [details] [review]: As per comments
Created attachment 256110 [details] [review] media-keys: Use a gsettings key for the length Don't hardcode an arbitary 30 seconds limit.
Review of attachment 256110 [details] [review]: > Use a gsettings key for the length Length of what? > Don't hardcode an arbitary 30 seconds limit. limit of what? Rest looks fine. ::: data/org.gnome.settings-daemon.plugins.media-keys.gschema.xml.in.in @@ +184,3 @@ + <default>30</default> + <_summary>Maximum length of screen recordings</_summary> + <_description>The maxmimum length of single screen cast recordings in seconds or 0 for unlimited</_description> Can you please fix the typo I already mentioned in the previous review? ::: plugins/media-keys/gsd-media-keys-manager.c @@ +2016,3 @@ screencast_start (GsdMediaKeysManager *manager) { + guint max_length = g_settings_get_int (manager->priv->settings, "max-screencast-length"); Separate the declaration and assignment please.
(In reply to comment #20) > Review of attachment 256110 [details] [review]: > > > Use a gsettings key for the length > > Length of what? > > > Don't hardcode an arbitary 30 seconds limit. > > limit of what? > > Rest looks fine. OK. > ::: data/org.gnome.settings-daemon.plugins.media-keys.gschema.xml.in.in > @@ +184,3 @@ > + <default>30</default> > + <_summary>Maximum length of screen recordings</_summary> > + <_description>The maxmimum length of single screen cast recordings in > seconds or 0 for unlimited</_description> > > Can you please fix the typo I already mentioned in the previous review? Oops was to much focused on the "0" thing so that I forgot about it ... fixed. > ::: plugins/media-keys/gsd-media-keys-manager.c > @@ +2016,3 @@ > screencast_start (GsdMediaKeysManager *manager) > { > + guint max_length = g_settings_get_int (manager->priv->settings, > "max-screencast-length"); > > Separate the declaration and assignment please. OK.
Pushed with suggested changes.
Thanks for the quick fix. Can this please make it to a 3.10.x release? It'll be great to have it working as before asap :) Thanks again, Ankur
I still don't think this was a good idea, but thanks for making it configurable - that makes it much harder to complain. (In reply to comment #23) > Thanks for the quick fix. Can this please make it to a 3.10.x release? It'll be > great to have it working as before asap :) This change will be in 3.10.1, which will be released in about two weeks.
*** Bug 709633 has been marked as a duplicate of this bug. ***
The biggest problem here is that there's no good screencasting app available, and therefore having this one crippled really hurts. If you look for good screencasting apps, they either a) don't record to webm b) are CLI based (which is problematic when you want to record a GNOME bug for which you need no windows visible) c) are not packaged in Fedora or distro of your choice. Thanks drago for trying to revert an unhelpful change.
I am on "GNOME Shell 3.20.3" ( Debian Unstable ). My first experience of this screencast was "Wow .. awesome". And when I was screen recording for a bug on gnome-maps, the recording stopped midway. I was checking the logs to see if there was a crash. Nothing. Then I checked when does the crash stop. Exactly after 30 seconds. So I googled and landed here. Even 30 seconds in gsettings sounds harsh. It should be atleast 5-10 mins ( which is more meaningful ), given the fact that webm file is approx only 2.5 MB per minute ( even on my 1920 x 1200 screen ). No limit is all better. I am pretty sure that most end users, who come across this feature searching for gnome-shell shortcuts, would be left clueless wondering why the recording stopped. Honestly, I thought it was a crash. I never thought anyone would make a time limit on a recording software. I have been a linux user for 12 years, and I just wanted to convey to the developers of this feature, that this is a really cool feature ( well integrated into gnome ). Now, you might have designed this with developers in mind, but it is more great for desktop users. Users don't need to search, select ( from one among many recorders - not wondering which is good ) install, open and learn a separate software. I am not a big fan of gnome-shell, but this feature was still cool.
For those of you who are facing this issue, and still wondering how this bug got marked as fixed ( like me ), the "30s" limit was moved away from the code ( hard coded value ) to a configurable value. That means, doing the following in a terminal: dev@unstable:/$ gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length 600 increases the value from 30 seconds ( default ) to 10 minutes. You can also check your changes by using the below command: dev@unstable:/$ gsettings get org.gnome.settings-daemon.plugins.media-keys max-screencast-length uint32 600