Glitch on macOS

[Tango]

I think this is an OS issue, not a MakeMKV issue and I don't think anything can be done about it - unless someone has a really good friend at Apple.

I've been ripping two TV series in the past few days (WKRP and Green Acres) and there were several times MakeMKV notified me it was done and I checked on what was showing in the Finder window and saw that the last episode ripped was showing 0 bytes. I'd delete those files and note them as bad. Then I had to check the Trashcan for another reason and saw the deleted files, but showing a non-zero file length.

It turns out the files ripped just fine - but there was a delay in Finder reporting the file length on the hard drive. I've never seen this before. I'm using Catalina and it could be that version where the problem starts, or it could be something funky I'm doing. I just thought I should report it in case others notice it or to warn people so nobody else deletes files under this situation.

(In the past, I've been able to watch a file in the Finder window as the size increases while MakeMKV is ripping it, so it seemed odd to me that looking at a file in a Finder window, when it's stored on my iMac, not on a server, didn't get it's size updated immediately.)

[Woodstock]

Neither Finder on the Mac nor Explorer on Windows are guaranteed to update in "real time". We just get used to them doing so, right up to the time they don't. Explorer sometimes falls several files behind when ripping, to the point where I have to use a command prompt to see what's in a directory.

A portion of the issue can be attributed to write caching; the writing program (doesn't have to be MakeMKV) finished and closed the file, but the operating system hasn't completed the writes. I end up using the F5 key to refresh Exploder a lot.

[dcoke22]

Starting in Catalina there have been lots of complaints about stale metadata in Finder and other APFS related oddness. Those complaints have persisted in Big Sur. I haven't seen them repeated on the recently released Monterey, but it is probably too new for those complaints to have surfaced yet.

https://daringfireball.net/2020/02/what ... be_correct
https://eclecticlight.co/2019/04/04/qua ... sed-space/
https://mjtsai.com/blog/2020/02/26/what ... e-correct/
https://mjtsai.com/blog/2019/04/11/quan ... sed-space/

As Woodstock has suggested, modern file system implementations are fairly complicated. The actual APFS layout of modern macOS is sorta mind-blowing with the 'signed system volume' synthesized with the writeable area of your user directory. 'Macintosh HD' looks the same as it ever has in macOS X and beyond, but underneath it is nothing of the sort. I often experience Finder being out-of-date, but I've never seen a directory query in Terminal return bad data.

Code: Select all

ls -lh

That command will list the files and directories in the current directory and use useful units of measure for file sizes.

https://eclecticlight.co/2021/09/07/whe ... -15-11-12/
https://eclecticlight.co/2020/06/25/big ... rotection/
https://eclecticlight.co/2021/05/28/why ... an-m1-mac/

[Tango]

I have a terminal window (I use iTerm2) with multiple tabs open at all times. I'm frequently using ssh to connect with my media server or with any of several Raspberry Pis I have on my system, so checking with any variation of ls is easy and natural for me. I just got caught the first few times because I didn't realize this was becoming an issue.

I'm glad to know it's not just me, but sorry that we're now encountering this as a regular issue. But once one knows about the issue, it's easy to not be fooled by it.

[Woodstock]

You MAY want to verify the network cabling to the server - I've had two cables fail on me to where the NAS was only communicating at 10Mb/s instead of gigabit. Ripping went fast, until MakeMKV's buffer filled, then slowed down. And writes continued for a minute or so after the disk spun down, writing the buffer to the network.

This can be another factor in delayed directory information.

[Tango]

You MAY want to verify the network cabling to the server - I've had two cables fail on me to where the NAS was only communicating at 10Mb/s instead of gigabit. Ripping went fast, until MakeMKV's buffer filled, then slowed down. And writes continued for a minute or so after the disk spun down, writing the buffer to the network.

This can be another factor in delayed directory information.

I've had that kind of thing happen with servers before, but this issue with MakeMKV is on my desktop - all on one system. (I use MKV to extract to my desktop, then Handbrake to process and save to my media server.)