View Single Post
  #9  
Old 10-21-2021, 07:11 AM
Tweakhead Tweakhead is offline
Member
 
Join Date: Aug 2000
Posts: 2,122
Default Re: Document could not be opened because it was created with an older version of Prot

I've seen Ben's tip work in the past too.
This error is now obviously just sheer file corruption . . .
which begs the question as how on earth backups can get keep getting written from a live functional session into a stream of corrupted files. Could it be a memory error that's triggering this kind of thing ? or just the physical storage drive itself ?

I'd also still like to know exactly what kind of drive this was. That's why I brought up the subject of that SMR-based drive type, which is typically ok for writing once and putting the drive away as an archive, but endlessly re-updating the same file causes the entire block to get re-read and re-written regardless of whether it's just a tiny piece of data within that block. There are some horror stories about those drives worse than this. Some major drive companies are now hiding the fact that they are using SMR behind the scenes.

I'd love to know the file size difference from Brad's last working session to the one immediately after.
Surely there are some checksums going on in the background that a save has been successfully written, and if there's a discrepancy - alert the user so that they don't keep writing and working on a corrupted session. It might have enabled him to use "Save Session Copy In" instead (to a different location) - maybe that might have written a useable file. who knows. obviously what he had in RAM was functional, so I don't see why it couldn't be written to a good storage device once alerted about failing media. At the bare minimum he could have consolidated his working audio tracks.

I personally never use auto-backup, and simply save version #'s (v1.0, v1.1, etc) throughout the day each time I do a major change that I might want to revert to - combined with muscle-twitch memory of Command+S every minute or two. I realize that audio-post users like to simply work one on one ready-named session.

Brad also asks an important question:
"If it's writing the session backups corrupt, how can I trust ANYTHING?"

Does that itself point to a RAM-based error ?

Is the only solution to periodically close the session and see if it will re-open?
or have an assistant occasionally copy everything over the network to another system and see if it'll open ?
seems pretty lame.

Last edited by Tweakhead; 10-21-2021 at 07:52 AM.
Reply With Quote