Feature #12723

GNOME screencast feature stops after 30s

Added by muri 2017-06-15 12:53:07 . Updated 2018-09-01 11:31:19 .

Status:
Rejected
Priority:
Low
Assignee:
muri
Category:
Target version:
Start date:
2017-06-15
Due date:
% Done:

0%

Feature Branch:
feature/12723-unlimited-screencasts
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

When looking for screencast solutions I stumbled over a Gnome3 functionality that I didn’t know before: when pressing Alt+Ctrl+Shift+R Gnome3 starts recording the screen and saves the video in $XDG_VIDEOS_DIR. I tried that multiple times and the recording starts after a few seconds (indicated by a red dot in the notification area). But it stops after 20-30 seconds. According to the gnome documentation the recording should stop when pressing the Alt+Ctrl+Shift+R keycombo again.
> Control+Shift+Alt+R keybinding starts and stops the recording. (Note: this functionality is currently missing in some distribution packages.) A red circle is displayed in the bottom right corner of the screen when the recording is in progress. After the recording is finished, a file named ‘shell%d%u%c.webm’ is saved in your Videos directory. In the filename, %d is the date, %u is a string that makes the filename unique, and %c is a counter that is incremented each time a recording is made within a single gnome-shell session.
and
> Ctrl+Shift+Alt+R: Start and end screencast recording
(from https://wiki.gnome.org/Projects/GnomeShell/CheatSheet)

on the other hand there is https://askubuntu.com/questions/919807/how-to-change-screencast-duration-in-gnome3-screen-recorder which says:
> Find org.gnome.settings-daemon.plugins.media-keys in the tree of settings
> Find the setting named max-screencast-length (the default value is 30 seconds)

I didn’t have the dconf key, added it, but it didn’t change the behaviour. As the length my recordings is not an exact number, but varies between 20 and 30 seconds, I don’t think its a max-length setting that stops the screen recorder.

I think this functionality could be helpful for debugging (and documentation), on the other hand it could have privacy implications to have such a functionality. either way, if it is enabled, I think it should work as advertised in the gnome documentation.

So, should screen recording be built in? Sorry if this has already been discussed elsewhere…
PS: (and maybe its not even possible to disable it)
PPS: (i don’t know how to debug gnome-shell to find out why it stops, pointers welcome)


Subtasks


Related issues

Related to Tails - Bug #10656: Document the use of recordmydesktop for UX testing sessions Resolved 2015-11-24
Related to Tails - Feature #8666: Explain how to take screenshots in Tails Needs Validation

History

#1 Updated by intrigeri 2017-06-22 14:17:20

  • Assignee set to muri
  • QA Check set to Info Needed

Can you please try to reproduce this behaviour on a Debian Stretch (possibly live) system?

#2 Updated by muri 2017-06-25 11:22:56

  • Subject changed from Make Gnome3 screencast functionality work to Discuss if Gnome's screencast functionality has privacy implications
  • Assignee changed from muri to intrigeri

intrigeri wrote:
> Can you please try to reproduce this behaviour on a Debian Stretch (possibly live) system?

On a Debian-Live system Gnome does nothing when pressing the Control+Shift+Alt+R keybinding; I’ve watched journalctl -f while doing this, but there was no error message; in the keyboard settings the keybinding is present;

But on a installed Debian Stretch system I was able to reproduce the behaviour. And I was able to figure out the correct dconf syntax to change the length of the recording:

dconf write /org/gnome/settings-daemon/plugins/media-keys/max-screencast-length "uint32 500"

Tried that also on Tails and it worked, so apparently the culprit was the max-screencast-length setting and the screenrecording works as advertised, but has a bad UI for setting the maximum length of screencasts and i think there is still the question if screenrecording is a wanted feature - changing title accordingly.

#3 Updated by intrigeri 2017-06-25 12:52:37

  • Subject changed from Discuss if Gnome's screencast functionality has privacy implications to Discuss if GNOME's screencast functionality has privacy implications
  • Assignee changed from intrigeri to muri
  • QA Check deleted (Info Needed)

I suggest adding this topic to the agenda of the next monthly meeting :) I won’t lead this discussion myself, so reassigning to you.

#4 Updated by Anonymous 2017-06-27 12:29:41

I’ve added the ticket to the agenda of the next monthly meeting.

It currently looks to me like there is no way to disable this feature. But on the Arch wiki one reads “In order to use the screencast feature the gst plugins need to be installed.” So if they are not, the screencast might not work.

1. Do we want this screencast to work? It might be useful for allowing users to debug but also for creating Tails how-to videos.
2. If yes, we need to research privacy implications (metadata, local exploits) -> subticket to create
3. If yes, we need to document this. Where should we document that? -> subticket to create
4. If yes, we need to adjust the dconf setting in Tails. -> subticket to create

#5 Updated by Anonymous 2017-06-30 11:30:36

  • related to Bug #10656: Document the use of recordmydesktop for UX testing sessions added

#6 Updated by Anonymous 2017-06-30 14:24:14

  • related to Feature #8666: Explain how to take screenshots in Tails added

#7 Updated by intrigeri 2017-07-05 17:07:02

  • Type of work changed from Discuss to Research

Conclusions from https://tails.boum.org/contribute/meetings/201707/:

  • We decided that we’re fine with this feature.
  • We agreed we don’t have to document this feature.
  • We will let muri investigate on potential security implications, although we didn’t go through this process for taking screenshots with PrintScr. It was mentioned that the screen resolution is leaked in such screencasts.

#8 Updated by Anonymous 2018-01-19 10:41:25

  • Priority changed from Normal to Low

Sounds like we could probably close this ticket?

#9 Updated by sajolida 2018-05-16 16:52:02

  • Subject changed from Discuss if GNOME's screencast functionality has privacy implications to GNOME screencast feature stops after 30s

Going back to a more generic title.

It would be useful for me to be able to use that during user testing.

The limitation of 30 s is the default setting from GNOME. See:

#10 Updated by sajolida 2018-05-16 17:06:42

  • Assignee changed from muri to sajolida
  • Priority changed from Low to Normal

To unset the limitation:

gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length 0

#11 Updated by sajolida 2018-05-16 17:22:27

  • Target version set to Tails_3.9
  • Feature Branch set to feature/12723-unlimited-screencasts
  • Type of work changed from Research to Code

#12 Updated by sajolida 2018-05-16 17:36:18

  • Priority changed from Normal to Low

Actually, the resulting screencast has no sound and there’s no easy way to record it. That becomes less useful for recording user testing → Low prio.

But I’ll still try to remove the 30s limitation now that I have some code for that..

https://bugzilla.gnome.org/show_bug.cgi?id=665548

#13 Updated by sajolida 2018-05-18 20:26:49

  • Assignee changed from sajolida to muri
  • Target version deleted (Tails_3.9)

My branch builds and the dconf setting is applied correctly:

https://nightly.tails.boum.org/build_Tails_ISO_feature-12723-unlimited-screencasts/lastSuccessful/archive/build-artifacts/

If I execute:

dconf dump /org/gnome/settings-daemon/plugins/media-keys/

I get

max-screencast-length=0

I tried to record 5 screencasts. The first one stopped at 18 seconds. The other 4 stopped at 31 seconds. I tried to reboot and got similar results.

My conclusion is that the first screencast is always shorter because it takes some more time to get started. The other 4 have a reliable length that doesn’t obey the max-screencast-length setting for some reason.

That proves to be more complicated than I thought and I’m not interested in debugging this further so I’m reassigning to muri.

muri: Feel free to also drop the ball and reject that ticket :)

#14 Updated by muri 2018-09-01 11:31:19

  • Status changed from Confirmed to Rejected

> muri: Feel free to also drop the ball and reject that ticket :)
there are better screencast solutions and with the improved additional software thingie its easier to use them, so yeah, rejecting