amiaopensource / vrecord

Vrecord is open-source software for capturing a video signal and turning it into a digital file.
https://github.com/amiaopensource/vrecord
154 stars 45 forks source link

Auxiliary files not being moved when capture occurs on external drive #849

Open iamdamosuzuki opened 1 day ago

iamdamosuzuki commented 1 day ago

For some reason I'm getting errors when auxiliary files are being moved to their final location, but only when using external drives. These errors don't seem to be happening when capturing on the system drive. Here's the output from vrecord, you can see the mv errors at the end.

Hit enter to start recording

Close the playback window to stop recording.
Guessed Channel Layout for Input Stream #0.0 : 7.1
[Parsed_pan_0 @ 0x7faea5706040] [SWR @ 0x7fae88ec8000] Input channel layout has a different number of channels than the number of used channels, ignoring layout
Input #0, matroska,webm, from 'pipe:':
  Metadata:
    ENCODER         : Lavf59.27.100
  Duration: N/A, start: 0.000000, bitrate: 9216 kb/s
  Stream #0:0: Audio: pcm_s24le, 48000 Hz, 8 channels, s32 (24 bit), 9216 kb/s
    Metadata:
      ENCODER         : Lavc59.37.100 pcm_s24le
  Stream #0:1: Video: v210 (v210 / 0x30313276), yuv422p10le(bottom first), 720x486, 29.97 fps, 29.97 tbr, 1k tbn
[Parsed_pan_0 @ 0x7f844c01f700] Pure channel mapping detected: 0 1
[Parsed_pan_0 @ 0x7f844b720e40] Pure channel mapping detected: 0 1
[Parsed_pan_5 @ 0x7faea6007980] [SWR @ 0x7fae98f88000] Input channel layout has a different number of channels than the number of used channels, ignoring layout
 300.31 A-V:  0.239 fd=  16 aq=    0KB vq=    0KB sq=    0B f=0/0   
mv: /Volumes/CaptureDisk01/20251105/Test01_vrecord_input.log: set owner/group (was: 501/0): Operation not permitted
mv: /Volumes/CaptureDisk01/20251105/Test01_vitc_frame_timecodes.txt: set owner/group (was: 501/0): Operation not permitted
mv: /Volumes/CaptureDisk01/20251105/Test01_frame_eia608data.txt: set owner/group (was: 501/0): Operation not permitted
iamdamosuzuki commented 1 day ago

I was wrong about this. The files are being properly created and placed where they need to be. However, those mv errors still appear.

iamdamosuzuki commented 1 day ago

I did a little digging, the error appears to be caused by the fact that the external hard drive's owner:group is set to VideoLabMini:staff instead of root:wheel. However, so far I've been unable to change the ownership to root:wheel, despite disabling SIP and whatnot. I'll see if there's any way to reliably change ownership on the later macOS, I'm currently on Sonoma.

privatezero commented 23 hours ago

Thanks for double checking! That was the behavior I was able to reproduce on a mac on our end (files are moved, but errors get thrown). I'll poke at it a bit more if I have a chance, but let me know if you find some kind of work around to silence those errors.

iamdamosuzuki commented 22 hours ago

Thanks for looking into this! I did a bit of poking around it seems that ownership of any external drives will automatically be set to the user:group of the logged in user. I tried seeing if I could go into the folder options (cmd + i) and give root read/write access, but that wasn't an option. I tried giving read/write access to Everybody as well as Administrators and neither of those seemed to help. There wasn't an option to give root access or ownership. I think this might be something baked at the OS level with later versions of macOS, so anything you can do to silence the errors would be helpful. I'll continue to ignore them for now, I just swear there was a time a few versions ago that the files actually wouldn't move, which would definitely be a real problem. For now, it's just a nuisance.