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 708660 - Screencasts limited to about 30 seconds
Screencasts limited to about 30 seconds
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: media-keys
3.9.x
Other Linux
: Normal major
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
3.10.1
: 708995 709633 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-09-24 05:20 UTC by Ankur Sinha (FranciscoD)
Modified: 2016-08-11 21:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
media-keys: Remove screencast limit (3.34 KB, patch)
2013-09-24 15:51 UTC, drago01
rejected Details | Review
media-keys: Use a gsettings key for the length (4.31 KB, patch)
2013-09-25 17:46 UTC, drago01
needs-work Details | Review
media-keys: Use a gsettings key for the length (4.43 KB, patch)
2013-09-30 16:12 UTC, drago01
committed Details | Review

Description Ankur Sinha (FranciscoD) 2013-09-24 05:20:44 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)
Comment 1 Jasper St. Pierre (not reading bugmail) 2013-09-24 13:50:54 UTC
This is intentional behavior.
Comment 2 Ankur Sinha (FranciscoD) 2013-09-24 14:19:53 UTC
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?
Comment 3 Jasper St. Pierre (not reading bugmail) 2013-09-24 14:35:05 UTC
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.
Comment 4 drago01 2013-09-24 14:59:38 UTC
(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.
Comment 5 Michael Catanzaro 2013-09-24 15:17:40 UTC
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)
Comment 6 Bastien Nocera 2013-09-24 15:20:49 UTC
Jasper can answer the reasoning behind the 30 secs limit.
Comment 7 drago01 2013-09-24 15:51:58 UTC
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.
Comment 8 drago01 2013-09-24 15:59:53 UTC
(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.
Comment 9 William Jon McCann 2013-09-24 16:24:27 UTC
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.
Comment 10 drago01 2013-09-24 17:26:30 UTC
(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).
Comment 11 Ankur Sinha (FranciscoD) 2013-09-25 00:31:55 UTC
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.
Comment 12 Bastien Nocera 2013-09-25 10:27:33 UTC
The functionality still works in gnome-shell, why doesn't someone work on writing a screencasting application instead?
Comment 13 drago01 2013-09-25 11:12:36 UTC
(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 ...
Comment 14 drago01 2013-09-25 11:18:53 UTC
(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).
Comment 15 drago01 2013-09-25 17:46:35 UTC
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.
Comment 16 drago01 2013-09-28 18:14:10 UTC
*** Bug 708995 has been marked as a duplicate of this bug. ***
Comment 17 Bastien Nocera 2013-09-30 15:46:39 UTC
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?
Comment 18 Bastien Nocera 2013-09-30 15:48:07 UTC
Review of attachment 255641 [details] [review]:

As per comments
Comment 19 drago01 2013-09-30 16:12:45 UTC
Created attachment 256110 [details] [review]
media-keys: Use a gsettings key for the length

Don't hardcode an arbitary 30 seconds limit.
Comment 20 Bastien Nocera 2013-09-30 16:16:46 UTC
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.
Comment 21 drago01 2013-09-30 16:22:24 UTC
(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.
Comment 22 drago01 2013-09-30 16:26:44 UTC
Pushed with suggested changes.
Comment 23 Ankur Sinha (FranciscoD) 2013-09-30 23:18:29 UTC
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
Comment 24 Michael Catanzaro 2013-10-01 00:04:04 UTC
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.
Comment 25 Jasper St. Pierre (not reading bugmail) 2013-10-08 14:28:34 UTC
*** Bug 709633 has been marked as a duplicate of this bug. ***
Comment 26 Kamil Páral 2013-10-09 08:52:04 UTC
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.
Comment 27 gnome.vrb 2016-08-11 21:47:38 UTC
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.
Comment 28 gnome.vrb 2016-08-11 21:49:01 UTC
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