mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 15:15:51 +03:00
[GH-ISSUE #895] Multi monitor recording problem #694
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#694
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gps7 on GitHub (May 14, 2021).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/895
Hi,
I have multiple monitors connected and always was recording on primary screen and was just fine. However, today I wanted to record on secondary monitor and recorder is writing wrong screen images, also after pushing record screen the borders getting shifted to primary screen and just disappearing. After stop using keyboard F8 the image is recorded for the wrong screen and wrong location. Setting up (aka move) on secondary screen is OK. Fun starts after request to record.
best regards,
Tomas
@NickeManarin commented on GitHub (May 15, 2021):
Hi, are you using the latest version? v2.30
Can you show me how your screens are positioned? (take a screenshot of the Windows Display settings)
@gps7 commented on GitHub (May 17, 2021):
HI,
Before retesting it I did an update to the latest version. Was same result.
Screen No 1: is latop's screen. Tried to record and it is looking fine.
Screen No 3: Is external DisplayPort connected screen, set as primary. Recorder is working fine.
Screen No 2: another external DisplayPort screen, which refusing to record correctly
External monitors are connected via thunderbolt connection.
@NickeManarin commented on GitHub (May 20, 2021):
I only have two monitors in here, so I can't test exactly with the same configuration.
I tested with my second monitor set as primary, while being at the left or at the right.
It recorded the correct position both times, using both the DirectX and Bitblt modes.
@gps7 commented on GitHub (May 20, 2021):
Is there any way I could produce the log files of position via appliation?
I've created simple C# application and got this cursor positions:
MessageBox.Show(Cursor.Position.ToString());
Top left corner positions for screens:
My guess is that app not dealing with negative coordinates. Try making primary screen on right hand side, this should make your secondary screen with negative coordinates. Maybe this will reproduce this problem.
@NickeManarin commented on GitHub (Jun 8, 2021):
You can get the source code and add logs in the
RegionSelectionclass, to watch its position.Also a video would be helpful too (you can configure to let multiple instances of the app run and use the full screen recorder option, it should still work).
@gps7 commented on GitHub (Jun 22, 2021):
Interesting, I've download the source code and compiled the application. I did not observed same problem as I described earlier using compiled application. All recording works fine and it does not jump. Not sure if there is any change affecting this behavior.
Additionally, mentioned RegionSelection is xaml code which is never got triggered. So I did not looked deeper into place.
@fz0000 commented on GitHub (Jul 23, 2021):
I have another similar problem.
I got blank images when recording on the secondary screen (the size is correct).
I'm using a laptop and my secondary monitor is a VGA monitor. So I connect to it via an HDMI-to-VGA adaptor. I'm not sure if it could cause this issue.
@NickeManarin commented on GitHub (Jul 24, 2021):
@fz0000 Which version are you using? Also which capture method?
@NickeManarin commented on GitHub (Jul 24, 2021):
@gps7 Should be the same, compiled or not. What can happen is that you could be running in Debug mode, which usually tends to be slower.
@gps7 commented on GitHub (Jul 26, 2021):
Strange, after reboot of the computer even standard program works fine as expected. So for me problem gone.
@fz0000 commented on GitHub (Jul 26, 2021):
@NickeManarin , I was using version 2.33.
Today I just remove all the config files and download the latest version 2.33.1 to make a clean installation. it works fine now. 👌
@myfonj commented on GitHub (Jan 31, 2026):
I also always got blank frames when tried to record anything on non-primary monitor, similarly to reports from here and #986.
Also, it seems to have trouble with vertical ("rotated") displays: even if I make rotated external display primary, the app only records its bottom part, and is not rotated properly.
@jokerfyy commented on GitHub (Jan 31, 2026):
收到啦，请放心，我马上就会看的
@fz0000 commented on GitHub (Feb 3, 2026):
@myfonj, if the vertical display issue is similar to #1408, you may check whether
BitBltmode could work.