Skip to content
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

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

Open
iamdamosuzuki opened this issue Nov 5, 2024 · 6 comments

Comments

@iamdamosuzuki
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@iamdamosuzuki iamdamosuzuki removed the bug label Nov 6, 2024
@privatezero
Copy link
Member

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
Copy link
Contributor Author

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.

@iamdamosuzuki
Copy link
Contributor Author

The files are now moving, but the 501 error persists on the output. Not a huge deal. Let me know if the ticket should be closed at this point or if it should stay open until that error is suppressed.

@privatezero
Copy link
Member

Thanks for the continued testing! I'd say let's leave this open for now as it is probably helpful for others to see that this is a known issue (and not a big problem).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants