Productions Auto Save destination gets reset

[POwens]

1.  Premiere v 24.0.0 Build 58

2.  macOS 13.6, all media on LucidLink

3.  Every day after starting up, I need to reset my machine's Auto Save location to my system drive - it resets to align with all the other scratch disk settings, which target the LucidLink.

[POwens]

Turns out it's a little more complex than this.   I'm working with a large team of remote editors and AE's, and the Scratch Disk assignments are set for any given project by the person who most recently that project.  As other editors open the project and re-save it, the Scratch Disk assignments change to their own settings, meaning that, for example, Auto Saves are set to inaccessible locations if an editor has set theirs to a local drive.  This means that Auto Saves either don't happen, or default to the system disk, or to the Productions root folder, and things get complex and messy.   It would be ideal if there was a way to lock the scratch disk assignments so they do not change as they shift from editor to editor.   Perhaps a toggle between "Lock / Set scratch disks"?

[R Neil Haugen]

@mattchristensen  ... assistance, please?

[mattchristensen]

Are you working in a Production? If so, individual settings (including Scratch Disk locations) of each component project are ignored, and instead the Production's settings and Scratch Disk locations are used for every project in the production. You can find these in File > Production Settings.

To get to the bottom of this we'll need to figure out how and why you're seeing Auto Save directories being created inside your production folder. A little more description of your team's workflow and where things live on storage might be helpful.

[POwens]

Thanks Matt.   We are a group of about ten editors and AE's, all working remotely and within a Production.   Some of us are on PC's, most of us are on Macs.   We did indeed set up the Production Scratch Disk Settings at the start of the project, and set them to be within a 'Premiere Scratch' directory, at the same level as the Production directory itself, i.e.

LucidLink > Edit Projects > Premiere Scratch.

The actual Production  edit projects are one level below that, at

LucidLink > Edit Projects > Production > Edit Project A, Edit Project B, etc

One of the issues we noticed with LucidLink was that the local cache seems to be very FIFO and until it has been fully flushed out to the cloud (I'm guessing here with my terminology), some file system operations didn't complete properly.   Specifically, we noticed that, for example, if a user was busy copying a lot of media into the cloud, at the same time as they saved a project, that project would not be fully updated on Lucid until everything before it in the queue had been could saved.  However, the file had been touched, so another computer would see that the file had been created but could not overwrite it.  So we started to feel that everyone's Auto-Saves were 'colliding', and so would change our Auto Save directory to be local instead.   But when another user opens that project, the Auto Save directory was now in an inaccessible location, and the new computer would default the Auto Save location to the default 'home directory' location on the internal drive instead, or sometimes elsewhere on Lucid.   So we started noticing the usual set of Premiere Scratch directories appearing like this:

LucidLink > Edit Projects > Adobe Premier Auto-Save

LucidLink > Edit Projects > Adobe Premiere Video Previews, etc

(It's possible these were created by the editor simply making the usual mistake with Scratch Disk assignment of point to the folder rather than within the folder.  These Premiere scratch disk folders continue to be one of the messiest things about Premiere media management to control!)

Does this help explain things?   I know there's vagueness in this, which I'm trying to get to the bottom of, since it's kind of impossible at this point to know which editor did what to their Scratch Disk settings, and why.   We feel there may be a PC/Mac aspect to this too.   But we're continuing to investigate and I'm happy to provide as much info as you need.

[mattchristensen]

@POwens Thank you, that was exactly what I was looking for in terms of more information. I'll make sure to share this with the team in case they know something I don't here. I agree with your hunch that having LucidLink be in the middle of syncing up large amounts of data could potentially put other changes in a waiting queue (things like changing scratch disk in the production settings, or making a new project).

I wonder if it is a case of auto-saves colliding, if lowering the auto save interval might help? I understand why you may not want to do that, but, I'm curious what your systems have it set at.