GIF recording is being cut off, entire recording is not saved
jkwuc89 opened this issue · 34 comments
When I attempt to create a recording of a Google Chrome window with a purchased/licensed copy of Gifox, the resultant GIF is not capturing everything that I am recording. My reproduction steps are rather simple:
- Press Cmd+Shift+7 to start a window recording
- Select Google Chrome
- Interact with Chrome
- Stop the recording and wait for the GIF to be generated.
The .mov file link below shows how I am using Gifox to record something within Chrome. The .gif file attached below is the resultant GIF generated by Gifox. Observe that the GIF is not capturing everything I recorded.
- Google drive pink to .move file mentioned above is here.
I am also experiencing this same issue. The ability to record GIFs is critical to the support we provide to our customers.
Can you please advise if there is an update available on this?
I could not be without the ability to record screencast GIFs so I went back to using LICEcap and requested/received a refund for Gifox.
Thanks for the info. I am hoping a member of the Gifox team can give me an update as, similar to you, recording GIFs is critical.
Apologies for the lagged reply, I started looking into this the other week and got sidetracked with something else. @jkwuc89 would you be able to send through the diagnostics data?
I have @kmayhew-cf logs (thanks for sending them through!) and can't quite figure out what might be wrong. I'll post my thoughts and ideas here for transparency and in case if you can think of something relevant. The key log entries for the last recording are:
2023-10-20 09:51:45.676 [EVENT] Pressed ⇧⌘6 hotkey associated with ToggleScreenRecordingSessionCommand command.
2023-10-20 09:51:45.679 [INFO] Screen recording session changed state: ready → selecting.
2023-10-20 09:51:48.534 [EVENT] Started making new selection.
2023-10-20 09:51:50.469 [EVENT] Finished making new selection: ScreenSelection(mode: area, frame: <x:1796 y:1074 w:1887 h:935>, screen: <non-main, x:1792 y:1120 w:1920 h:1080>, scale: 2.0, config: none).
2023-10-20 09:51:51.376 [EVENT] Pressed ␣ key captured in Screenware.ScreenSelectorKeyboardManager.
2023-10-20 09:51:51.376 [INFO] ScreenCaptor updating screen link with current state: idle
2023-10-20 09:51:51.379 [INFO] Screen recording session changed state: selecting → recording.
2023-10-20 09:51:51.383 [INFO] Recorder updating state from: ready, to: recording
2023-10-20 09:51:51.556 [INFO] ScreenCaptor starting capturing, current state: idle
2023-10-20 09:51:51.556 [INFO] ScreenCaptor creating screen link for screen id: 722500243, selection: ScreenSelection(mode: area, frame: <x:1796 y:1074 w:1887 h:935>, screen: <non-main, x:1792 y:1120 w:1920 h:1080>, scale: 2.0, config: none).
2023-10-20 09:51:51.560 [INFO] CIContext creating with metal device: <GFX10_MtlDevice: 0x7f78f0008000>
name = AMD Radeon Pro 5500M
2023-10-20 09:51:51.560 [INFO] ScreenLink starting display link…
2023-10-20 09:51:51.560 [INFO] ScreenLink updating state from: idle, to: running
2023-10-20 09:51:51.560 [INFO] ScreenCaptor synchronizing with screen link state from: idle, to: capturing
2023-10-20 09:51:51.561 [INFO] Enabling ⌘⎋ shortcut associated with StopRecordingSessionCommand command.
2023-10-20 09:52:41.437 [EVENT] Pressed stop recording button in screen selector toolset view.
2023-10-20 09:52:41.437 [INFO] Screen recording session changed state: recording → finishing.
2023-10-20 09:52:41.437 [INFO] Recorder updating state from: recording, to: finishing
2023-10-20 09:52:41.438 [INFO] ScreenCaptor stopping capturing, current state: capturing
2023-10-20 09:52:41.438 [INFO] ScreenLink stopping display link…
2023-10-20 09:52:41.438 [INFO] ScreenLink updating state from: running, to: idle
2023-10-20 09:52:41.438 [INFO] ScreenCaptor synchronizing with screen link state from: capturing, to: idle
2023-10-20 09:52:41.441 [INFO] Recorder updating state from: finishing, to: finished
2023-10-20 09:52:41.443 [INFO] Disabling ⌘⎋ shortcut associated with StopRecordingSessionCommand command.
2023-10-20 09:52:41.453 [INFO] Screen recording session changed state: finishing → finished.
2023-10-20 09:52:41.734 [INFO] Exporting composition: Composition(size: <w:1887.0 h:935.0>, fps: 12.0, duration: 40.1, tracks: 1 [0.0:40.1], storylines: 1 [0.0:40.1])
2023-10-20 09:52:41.735 [INFO] Setting up palette transcoder with configuration: Configuration(size: <w:1887 h:935>, colors: 256)
2023-10-20 09:53:03.720 [INFO] Palette transcoder did terminate with state: finished
2023-10-20 09:53:25.358 [INFO] GIF transcoder did terminate with state: finished
In plain language:
- Selection in area mode: OK
- Recording for 40 s: OK
- Start exporting 40 s of video: OK
- Creating GIF palette: OK
- Exporting GIF: OK
From @jkwuc89 video everything also checks out. Because he does window recording – there can be really weird situations. For example, browser tabs visually live in a single window. But technically each tab has a unique window ID. My initial guess was when you click on Deal tracker the address changes, perhaps that would result in a window ID change… but that happens a few moments later after the GIF cuts off. Also, @kmayhew-cf uses area recording mode, so that shouldn't be happening at all in her case. So, that idea doesn't really check out and probably not what's going on.
It would help immensely if I can bother you with some testing, as none of us can reproduce this locally… 🙏
- Can you confirm that there are no error of any kind?
- If so, can you open the captured video in editor and verify it's complete and doesn't cut off?
- Can you export it as a GIF from the editor? What happens?
- Can you export it as an MP4? Does it cut off there?
- Can you also check if your output folder or any folder above (like Documents) is iCloud synced or synced via any other cloud service (Dropbox, Google Drive, etc.)?
Again, apologies for the lagged response and the troubles. I'll try to sort this out for the upcoming release.
For what it's worth, I've also noticed this issue and am happy to help troubleshoot. I'll try some tests above and provide more info when I'm back at my work computer tomorrow.
@iby For a little more information, it appears this may be an intermittent issue. I was able to create gifs without a problem this morning but am now unable to create complete gifs again.
I am unsure what you mean when you say "confirm there are no errors of any kind". Nothing unusual happens when recording the gifs, Gifox behaves as expected when recording a complete gif.
I am not able to view the full recording in the editor. The version here is also cut short.
As an example, I just recorded a 32 second gif. After processing, the gif is 24 seconds long with 8 seconds cut off the end.
Here is a fresh set of diagnostic data which should show this latest attempt.
I am unsure what you mean when you say "confirm there are no errors of any kind". Nothing unusual happens when recording the gifs, Gifox behaves as expected when recording a complete gif.
@kmayhew-cf yes, that's what I wanted to check – want to make sure there are no any visible errors or warnings.
I am not able to view the full recording in the editor. The version here is also cut short.
This is interesting. A broken original recorded video would explain the issue with the exported GIF. Would it be possible to get any of those cutting off raw recordings (GIFX files) for inspection?
- Go to Finder and select
Go → Go to Folder…in the main menu. - Paste and go to
~/Library/Application Support/Gifox 2/Compositions. - Find the file corresponding with the corrupted recording (might be a slightly different timestamp).
- ZIP it up and either attach here or via Dropbox or using any other convenient way.
@brycekunkel, @jkwuc89 if you're also observing the same issue and have a chance to send through the raw files, would be very handy, thank you!
@iby I have deleted the broken GIFs and their associated files. The next time I run into the issue, I'll send an example across.
We're also starting to believe that this issue might be limited to Intel-based Macs. Can you 👍 or 👎 this comment to confirm if this is your case? Also, if anyone can send us a raw-recording for investigation (instructions are above), would be very helpful! 🙏
@iby, added here the diagnostic data for the issue where the GIF is being cut off and not showing the click-mouse interaction.
Also added the original recorded video via Dropbox.
I'm on an Apple Silicon Mac and still experienced this today. Here are my three docs (which were not found in Application Support but rather at ~/Library/Containers/com.gifox.gifox2-appstore/Data/tmp/Gifox 2. There was no folder at ~/Library/Application Support/Gifox 2.
System Info.txt
App Settings.txt
App Logs.txt
Also note, I went into the gif editor screen and the end of the recording is not available there either.
Anecdotally, I seem to notice it most often when recording a GIF of a window, rather than the whole screen. Havent done must testing to confirm that though.
Hi @iby, is there any news regarding this issue? Was our raw recordings helpful? Or do you need other details?
Thanks in advance.
Regards,
George
Hi @iby,
I have just uploaded a corrupted file example via Dropbox.
Just a bit more information, one of my colleagues is now also having this issue since he upgraded to MacOS Sonoma 14.0.
I have also noticed this morning that I was able to record correctly on one of my external monitors but not on the other. This does not seem to be consistent as I have previously been unable to record correctly on both external monitors but I just thought the additional context might help.
Hey folks, sorry for the laggy reply – had a troublesome week being away and a stolen laptop… @GheorgheSacultanu @kmayhew-cf thanks for the samples. I reviewed both and I seem to have more questions than answers… 🤔
- I can see that Gheorghe's video is 8 seconds and Katie's is 18 seconds long.
- They both match the recorded composition's length and the recorded video open's up fine for me (in Gifox and in QuickTime).
- Exporting them also produces valid duration GIFs.
You're saying that video also cuts off for you in editor, can you verify exactly what happens with it? Is it just shorter than it should be or perhaps part of it is blacked out or something else?
Also, when you run into this issue next time, can you right-click on the GIFX file → Show Package Contents → Library and open the MOV file in standard QuickTime Player to see if it opens up and plays correctly to compare if it's any different from how it appears in Gifox editor.
I incline to relate the issue to Intel + Sonoma, was really hoping the last week's update would solve it (along with another regression #266), but it hasn't… Right now there are two things that might be going wrong:
- Recording: the recorded raw video would be shorter than expected. Based on logs and from provided samples they seem to match. But clearly some of you are having issues, so to confirm if this is happening or not, checking the raw MOV (from GIFX) from the composition is a good way for verifying it.
- Video compositing: prior playback and export the video gets "prepared". There's pretty heavy logic there and it's possible something got broken. If the raw MOV file (from GIFX) looks legit, but doesn't show up correctly in Gifox or doesn't get correctly exported – this would be the issue. Also, if this is the case, it's possible that after restarting Gifox the video may appear (and get exported) correctly in Gifox.
I also find interesting the fact that most reports seem to say that the video is shorter by a constant number of seconds, rather than a percentage or a random value.
@brycekunkel you must be using the Mac App Store version. It uses sandboxing and the correct path for that is ~/Library/Containers/com.gifox.gifox2-appstore/Data/Library/Application Support/Gifox 2/Compositions. I should have mentioned that from the start, sorry.
@iby Sorry to hear about your issues with the stolen laptop.
The outputs of the recording in Gifox, the editor and the MOV file are all the same length (in my case 18s). The recorded clip was 20+s (I can't remember the exact length). What is seen is the same in all 3 locations, the recording just stops early.
Something I have noticed that may be of interest, when I use the keyboard shortcut (cmd+esc) to end the recording, you can see the keyboard interaction for me pressing cmd come up on the output before it stops, even though I didn't press the key at that time.
Also, my recordings don't seem to be shorter by a consistent number of seconds. It appears to be somewhat random on my machine, while my colleague is having the same issue but the videos always seem to be 2 seconds shorter than expected.
@iby, I did another round of testing. I have recorded 31 seconds (you will see it on my phone screen recording) but gifox is showing it only as 10 seconds (which is random). I will attach again the diagnostic data.
Phone video recording -> https://drive.google.com/drive/folders/1-WoPOGIK5QFv3gY0u4ec1YOLQoXG9hzp?usp=drive_link
@GheorgheSacultanu Thanks for that. Yes, there's definitely something wrong with the recording itself.
2023-11-03 12:46:21.645 [INFO] ScreenCaptor synchronizing with screen link state from: idle, to: capturing
// ... 32 seconds elapses
2023-11-03 12:46:53.859 [INFO] Screen recording session changed state: recording → finishing.
// ... Only 11.7 seconds get recorded
Exporting composition: Composition(size: <w:1383.0 h:877.0>, fps: 17.5, duration: 11.70167, tracks: 1 [0.0:11.70167], storylines: 1 [0.0:11.70167])
@kmayhew-cf That is an interesting detail, thank you… 🤔
I don't have any actionable ideas at the moment. We have an update ready to roll out with other improvements. I am going to include extra debugging information and release it, so we can see what's going on under the hood during the recording. There are no errors or warnings or anything else that could provide any hints. I managed to find an Intel-based laptop, but it's a little old for Sonoma. Keeping looking for another one… I'll keep you posted. Sorry for the troubles.
I've been able to successfully reproduce the issue.
- Launch Gifox from the menu bar. Record the Google Chrome window.
- Tap the spacebar to begin recording.
- Record a few seconds
- Take note of the time, then cmd + R to refresh the page.
- Continue recording
- End recording by clicking the timer on the Gifox menu bar.
The recording stops a the point the page is refreshed using Cmd + R.
Updated to the latest version Gifox 2.6.2 and the issue of the video being cut off is still reproducible + not showing the click-mouse interaction.
I have recorded ~ 36 seconds but in the end is displayed only as ~ 13 seconds.
@brycekunkel @GheorgheSacultanu thanks for updated reports! Yes, 2.6.2 is out – the release comes with additional logging and unfortunately doesn't address this issue as we still cannot pinpoint the problem, apart from some internal API change affecting Intel machines.
@brycekunkel I did try the exact steps and on M1 machine this isn't happening. My initial suspicion was based on the fact that reloading the tab may change the window ID that's being recorded, but when a window disappears the recording should immediately stop, which isn't happening. That said, this still can be related to window rendering and GPU processing behavior, that somehow affects the recording.
I reviewed @GheorgheSacultanu logs from 2.6.2 release – thanks again for the quick turnaround! It does give additional clues into where the recording is failing. I'm planning to review this closer and release a Beta version next week, where we could test possible fixes for this bug.
Again, apologies for the dragging issue and thanks for the feedback. Hopefully we'll have a workaround very soon! 🤞
I was able to replicate the issue again consistently this morning with other cmd + key actions. For example, in the gif attached, I used cmd + k to insert a link into this comment. The total recorded time was around 15s, but the recording only returned 9s. You may also notice from the keylogging that it is not synced with the video - the keylogging shows that I typed "Wiring more text" (mistype) but it doesn't show in the recording.
System Info.txt
App Logs.txt
App Settings.txt
I really hope this helps!
Thanks for sharing this @brycekunkel! @kmayhew-cf mentioned something similar, but your GIF really shows the issue – looks like the video and interaction streams are completely out of sync… I have a couple of ideas I want to exercise – hopefully one of them solves this.
Hi, any updates on this issue? Having the same problems? I just bought a licence because I need to record the screen for more than 30 sec. But my gif recordings are just lasting 5 seconds.
Regards,
Samuel
Hello friends, a quick status update… I said that we'll be publishing a Beta this week, but I underestimated the amount of work, sorry. We're aiming to make a release by Wednesday 22nd Nov, hopefully a little sooner. While fresh logs were helpful, we still cannot pinpoint where things are going wrong, so we decided to take a different route and implementing an alternative screen capturing approach for Sonoma, which will hopefully solve this issue.
In the meantime, not the best solution, but should keep your "GIF operation" running… you can try creating recording with the standard Screenshot.app and drag-and-dropping the captured video from the corner popup straight into Gifox status bar item for quick conversion.
Again, I'm sorry for the troubles and that it's taking awhile to sort out. This and #266 are very frustrating issues, with a couple of similar reports from other developers and app users. The existing screen recording implementation has served Gifox very well for several years and most users are not running into any issues. There are other performance-related reports for Sonoma on Intel Macs, including usage of external monitors, which Apple is aware of. There's another macOS Sonoma 14.2 update around the corner with Beta 3 already available – I'm also hopeful it will addresses these issues if we don't fix it first.
Another update… I'm still unable to crack… 😣
I'm sharing some progress into what's going on to not leave this just hanging around. Apple released not that long ago an alternative ScreenCaptureKit framework / technology, which significantly simplifies the mechanics of screen capturing compared to how we've been doing it, which is great. My approach was to utilize that for Sonoma systems to work around some complexity, which might be breaking it on Intels.
Unfortunately, to support all of the capturing features, it still requires using pretty much the same code, which invalidates the original idea. I'm still planning to finish this, as there is a chance that something will work differently. Will share more soon.
Just to add one important point: this is not limited to Intels. I am on a MBP 14 M1 Pro with Sonoma 14.1.1 and I have consistently the exact same problems.
Since I use Gifox multiple times a week and can safely say that the problems occurred when I upgraded to Sonoma. Hope this helps - just want to make sure the fixation on "Intel" does not derail the solution finding ;-)
And thanks for the great work - it's a great tool I recommended multiple times to others already!
Hello everyone! Good news at last! 🥲
I figured out the most likely origin of the troubles and was able to simulate an "artificial" situation resulting in incomplete recordings. I still cannot test this to full extent, but very confident this should be fixed from here on. With @jnw-vlcs's and some earlier comments, there were very abrupt reports of this happening, but I guess the latest Sonoma release has really highlighted and amplified it.
@jkwuc89 @kmayhew-cf @GheorgheSacultanu @brycekunkel @BigSamu @jnw-vlcs:
Please enable pre-releases or get the latest beta directly from our website here. If you're using the Mac App Store or Setapp versions, please email us at team@gifox.app and we'll set you up with a license for the direct-download build.
I'm going to keep an eye on the beta for the next couple of days and will review how else this can be improved, along with another other Sonoma-related bug. Will aim to make a public release early next week.
Please reach out if you're running into any troubles and include latest logs. Again, thanks everyone for patience and information, and apologies for this taking awhile. Hopefully things run smoothly from here on! 🤞
Hi @iby, I was testing the new pre-release version, and seems to be better now. I will attach the diagnostic data as a reference.
All the length of the recording is displayed in the gif.
Also, I would like to see if for other guys the issue was fixed before closing it.
Hey @GheorgheSacultanu, thanks for giving it a go and sharing the logs. I can see that the fix is doing what it supposed to, which confirms that this was the cause, hopefully the only one!
Installed 2.6.3-beta and that resolved the issue for me. Intel. Sonoma 14.1.1. Thank you.
Installed 2.6.3-beta and that resolved the issue for me. Intel. Sonoma 14.1.1. Thank you.
I take it back. It worked 1x. Now instead of retaining the first N seconds it's retaining the last N seconds of recordings. I'll try and experiment a bit more later when I have time and come back with logs.
@taptapdan thanks for the follow up. If you can provide logs shortly after a failure, that would be the most helpful to understand why that might be happening! 🙏
Howdy friends! The new Beta has just been published, it comes with some general capturing improvements and addresses glitchy mouse interaction capture. If you can give it a go and report any issues, would be much appreciated! 🙏
Everyone, thanks for the feedback and patience! Based on the Beta comments and discussions it seems the issue is resolved. Version 2.6.3 was released yesterday – please get the update. If you're still running into any troubles, please do let me know? 👍🙏