New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Recording" itself isn't happening (for some users, still unclear who/why) #55
Comments
Is this using 0.1.9? Is this MacOS 14? Out of curiosity, is ffmpeg installed on your computer? Maybe there's a missing dynamic lib that's getting picked up automatically on your mbp. |
I've tried both the 0.1.9.dmg and the compat-13.dmg; and the iMac's currently on Sonoma 14.0. Good call on the ffmpeg -- just installed it, but running Rem still doesn't seem to record anything for some reason. Empty mp4 files in my 'data'. |
That comment above was a link to an unknown website. Clearly phishing or spam. Reported and deleted. |
MBP M2 Max +1 to all this, identical behavior. |
Thanks for this project! I'm seeing the same issue as well, but only with an external display connected. I realize multiple displays are not yet supported, but I'm not sure what the current expected behavior is. (I would assume it records the primary display and ignores secondaries?) With the external display connected, OCR still seems to be happening since there's valid text content in "Recent Context", but all the output video files are empty as prithsr described. With the external display disconnected, pixels start landing correctly in the mp4 files and screenshots appear in the timeline. Strangely I'm not seeing the system-level screen recording notification in the menu bar in either context. Running on an MBP M3 Max, macOS 14.2.1, rem v0.1.10 built from source, ffmpeg 6.1 via homebrew. |
Interesting! The fact that OCR is working means the screenshot is successful. Why that would not get streamed to ffmpeg is mind boggling to me. Clearly missing something… |
I've been having (similar? identical?) issues on my M1 Pro MBP Specs I was getting good recordings for a while - according to the data folder I've been getting recordings when i've been (intermittently) running rem since 2023-12-30. Then I got Zero bytes mp4s on 2024-01-10. On 2024-01-11 I have a few with content, and then starting again later in the morning of 2024-01-11 the mp4 are empty again, with entries on the 11th, yesterday, and today. I am running rem built-from-source. I have ffmpeg 6.0 installed. I'm also running rem sometimes with multiple, external monitors (expecting that the results would be at least incomplete for now), but the content of the mp4s doesn't seem related on the surface to the behavior - for example the content-ful files on the 11th were just after midnight when my laptop was almost certainly not connected to external monitors, but right now while my MBP is not connected to any other monitors I am getting Zero bytes files. My shell history isn't helping me confidently find all the times I built new versions, but I feel fairly confident I didn't build a new version between 00:15 and 06:00 on 2024-01-11 rem is doing something appropriate, because when I open up Search and look for Restarts also don't seem to matter - I restart this machine nearly daily and have stopped and restarted rem numerous times. Update; two hours or so laterSame machine and everything. I've moved to my office and jacked into my setup, which has a closed laptop lid connected to a TS4 hub and thence to two external monitors. After that i restarted rem, and it's collected a screenshot with content of the ginormous "default" monitor. But only the one, even though i've been active on that monitor (that's where i'm typing this). About 5 mins have elapsed and stil just the one mp4 (with content) It occurs to me that my settings my be impacting rem's ability to do all the stuff it has to do. This is what i have right now and what i switched to before initially posting my comment before that i had and have just switched back to that and restarted rem. Several minutes later and still no mp4 results at all, empty or otherwise.... Since I'm running this from source if there's a debug bit i can flip and rebuild I'm happy to do so. I am a complete and utter Swift newbie (as in rem is literally the first thing I've built from source in XCode), but i can probably manage to change a few settings or type a few lines of code ;-) |
Thank you for the very thorough report. Which commit are you currently on? (Last build) —- My immediate suspicion is related to the screenshots being different sizes causing problems. Assuming that’s the case… First thing I’d try is resizing the screenshots to always be the size of your monitor (without messing up the aspect ratio)- not the best solution but it’s a very tricky problem. Otherwise we’ll need to start a new video file whenever your focus changes monitors- maybe that’s the right solution. —- if it’s not that… when you say “ginormous”, is it 5k? Even so, doesn’t seem that crazy- should only be 4x the pixels (not even). I would put a breakpoint to see if it’s trying to take subsequent screenshots or not. And another breakpoint right before the video is rendered and check the size of the image buffer to see how many there are. lemme grab those lines… Line 347 in 6f1d981
Line 468 in 6f1d981
—- to do this, you’ll need to run it from the Xcode and it will say it doesn’t have permission, and you’ll need to remove rem from granted screen recording permission then rerun and regrant. When you finish debugging, you’ll need to do it again to regrant your built version permission. Not sure why this happens- kinda frustrating. —- lemme know if that was nowhere near enough information. I’d love to get this working for multi-monitor scenarios. |
I'm currently running I think I may have misspoken earlier insofar as i believe I misinterpreted what I should see in the data folder - I do have Zero byte mp4s, but I expected to have more of them generated at closer intervals but upon reflection i have no idea how often rem generates the mp4s. "Ginormous" in this case probably really isn't - it's 48" but just a 4k. I may be a good edge case here, or perhaps a bad one - my desk setup is the aforementioned 48" 4k and a portrait-oriented 32" 4k running at a bit less than that. I switch from monitor to monitor quite often and a lot of my heavily-OCR-able stuff is on the portrait monitor (maybe that's natural?) and I spend perhaps 25% of my time disconnected on just the laptop screen. I can work on getting a build running with those breakpoints hopefully this evening. |
MP4s are generated every 30 frames (every 60 seconds). I’ll start investigating this when i get home from work this evening! |
possibly-unrelated to the Zero byte mp4s, it seems likely that switching monitors causes this build at least to stop recording. I was able to reproduce
a few times. |
huge news. got a fix. will open pr soon. |
this is def an improvement as far as empty recordings - when tested on my MBP screen it worked great. When I moved to my desk and "jacked in" tho, it seems to have stopped recording at all similarly to what i saw from switching monitors above - when watching the data folder i infer i can see rem doing "stuff" by vitrtue of the sqlite journal file. After connecting just now that activity stopped. After a restart in my connected state everything appears to be working fine, and I am getting recordings that have both monitors and follow focus including resolution and orientation. Thanks a ton - this is super amazing! |
Rem worked great on my M1 MBP, but it isn't functioning as intended on my M1 iMac.
Toggling 'timeline' shows:
And using the 'search' feature shows:
Searching a specific query does show results matching that word(s), but without the actual thumbnail/recording of it. Clicking on any search result shows image 1 all over again.
'Show me my data' opens finder with several mp4 files, but I'm unable to open any as it says these files are incompatible with quicktime (and all of these also weigh 0KB). Unsure why the recording isn't occurring as I've granted screen-recording permissions
The text was updated successfully, but these errors were encountered: