Issue with Productions showing projects as locked when they are not.

[atedwards]

Hi all,

My organization has been using a Productions workflow for a few months now. This morning, one of our editors had Premiere Pro crash (unexpected error) during work. They then restarted their computer.

After restarting their computer, relaunching Premiere and opening the same Production, all of the projects inside that Production show as locked. A few things of note:

1. The folders do not show prlock files
2. If the editor opens the projects, they show as completely blank
3. If the Production is opened on another machine, the projects are there, open, and full

We have tried resetting all Adobe preferences, granting read/write access to the software and clean installing the Adobe Suite.

Specs:
Mac Studio M2 Ultra
64GB RAM

all files are on a QNAP NAS. All software and operating systems are up to date.

Any ideas?

[Bruce Bullis]

>1. The folders do not show prlock files

That's very strange, as the presence of .prlock files is the only determinant for the lock state of projects, in a Production. If there isn't a .prlock file for a given .prproj, that project is not locked. 

> If the editor opens the projects, they show as completely blank

What are the differences between that editor's system configuration, and the other system where all the projects open normally?

>If the Production is opened on another machine, the projects are there, open, and full

If the projects are open on another machine, there are .prlock files next to each open project, right? 

[atedwards]

> That's very strange, as the presence of .prlock files is the only determinant for the lock state of projects, in a Production. If there isn't a .prlock file for a given .prproj, that project is not locked. 

I agree! It's super bizarre. Even though we don't see prlock files from any machine's view of the NAS folder, the machine in question still can't open the project without a warning. Once we bypass that warning the project is empty.

> What are the differences between that editor's system configuration, and the other system where all the projects open normally?

As far as I know the systems are configured identically. Is there something specific you'd like me to check?

>If the projects are open on another machine, there are .prlock files next to each open project, right? 

Yes. If we open the projects on another machine the .prlock files appear. Closing the project removes those files. The projects still show as "locked" in the Productions window on the machine in question

[Todd_Reeder]

Very interesting, all other machines appear to behave correctly...but the machine in question remains in a bad state even if the lock files are removed from another machine?  If another machine opens a project, what state does the bad machine show on that project in the production panel as well which machine is shown to own the lock?  If the good machine releases the lock, does the bad machine show there is no lock?  If a good machine renames a file, or adds a folder in the production panel, does the bad machine see that in the ppro production panel?  does it see it on the desktop?

Are the clocks on the bad machine in sync with the QNAP's clock?

[atedwards]

>If another machine opens a project, what state does the bad machine show on that project in the production panel as well which machine is shown to own the lock?

If another machine opens a project, the bad machine doesn't show a change in state. That is, it still shows it as "locked". The machine that owns the lock doesn't change though, so that's interesting. (ie, the bad machine shows that "edit01" owns the lock. If we open the project on "edit03", the bad machine still shows that "edit01" owns the lock)

>If the good machine releases the lock, does the bad machine show there is no lock?

Unfortunately it still shows as locked (and that, in the above example, "edit01" still owns the lock)

>If a good machine renames a file, or adds a folder in the production panel, does the bad machine see that in the ppro production panel?

We didn't test this but I'll update with more information when we have it.

>does it see it on the desktop?
The Finder view of the Production folder always mirrored what other machines were seeing. That is, it would show .prlock files when other machines truly had the projects open. It would not show .prlock files when those projects were closed, but Premiere still showed them as locked.

>Are the clocks on the bad machine in sync with the QNAP's clock?
You've hit on an oddity of our setup. Our QNAP clock is about 10 minutes ahead of all of our machines. Our machine clocks are synced but the QNAP has been living 10 minutes in the future since it was set up several years ago (and before my time). As far as I know this has not caused any issues but it could be contributing to this one.

A few additional notes/tests:

- Opening the troubled projects outside of a Production on the bad machine showed the full project in its most recent state. Doing this also seemed to have the effect of "unlocking" the project when re-opening the Production.

- The issue only appeared in one Production at first, then disappeared. It now appears across multiple random Productions without rhyme or reason. If "edit02" opens Production A it may show that all projects are locked. The next day "edit02" may open Production A and it may be unlocked, but Production B may show locked. It's truly bizarre.

- We are also having issues with connecting that machine -- and that machine only -- through any sort of remote desktop software (TeamViewer, Parsec, etc). We're now thinking it may be a problem with the ethernet port? We have switched to a USB-C to Ethernet adapter and have (so far) not run into any issues. I'll update as this continues.

And as a quick aside, thank everyone so much for helping resolve this issue! Hopefully we get it dialed in soon

[Todd_Reeder]

Please sync the clocks and let us know if that fixes the issue.  Having the clocks that far out of sync have been known to cause all sorts of issues.  

[atedwards]

>Please sync the clocks and let us know if that fixes the issue.  Having the clocks that far out of sync have been known to cause all sorts of issues.  

We synced the clocks yesterday after this comment. Things seemed to work normally until we came in today, when the editor experienced the same issue.

Updates:

When the bad machine tries to open a Production, it gives an error that the "folder is not a Production." Once he "converts it to a Production" it shows that all projects are locked.

Looking at Finder, there are no prlock files.

Opening the Production on a different computer (than the one that "owns" the lock) shows that the projects are not locked.

Opening a project within that Production on the third computer ("edit03") does not change the lock status in "edit02"'s Production window. It does create a .prlock in the Finder view though.

[Bruce Bullis · Accepted solution]

>We synced the clocks yesterday after this comment. Things seemed to work normally until we came in today, when the editor experienced the same issue.

What changed, between yesterday and today? Did someone reset the clock? Did some network process access the files? 

>Once he "converts it to a Production" it shows that all projects are locked.
>
>Looking at Finder, there are no prlock files.

The only thing that will make PPro think a project is locked, is a .prlock file. 🙂

Does the user account from which you're seeing "no .prlock files" have full privileges, to the volume containing the Production?

>Opening the Production on a different computer (than the one that "owns" the lock) shows that the projects are not locked.

That's very, very strange. 

Computers do not own locks; users do. If you look in PPro Prefs --> Collaboration, you'll see how the .prlock User Name is specified. If you open a .prlock file in a text editor, you can see the user name in use. 

When you access the Production from that different computer, what user name are you specifying in the prefs?

[Todd_Reeder]

>When the bad machine tries to open a Production, it gives an error that the "folder is not a Production." Once he "converts it to a Production" it shows that all projects are locked.

Normally that would only happen if PPro is not seeing a .prodset file inside the production folder on the desktop.  If that happens again, can you manually verify if the computer shows a .prodset file?  if not, but the other machines do, for some reason the bad machine is not getting the right data pushed to it.

[Kevin-Monahan]

Hello @atedwards ,

Thanks for the message. It’s been a while since you filed this bug. Are you still having this issue? If so, can you provide the info the product team member requested?
 
I'll move your post to the Discussions board while we await your information.
 
Thanks,

Kevin

[Dyana27563610pyds]

I am also experiencing this bug. Did anyone find a solve? I just updated to the newest v25.1 and my project opens perfectly except for the productions window which is blank and says 'project locked' in the tab. I've tried all the steps above, reset saved layout etc... nothing is working. 

Thank you!

[bbb_999]

Is the project that's opening, within a Productions directory?

If the Productions window is blank, where are you seeing "project locked", in what tab? 

In the OS, is there a .prlock file next to the project you're opening?

[Dyana27563610pyds]

I believe the problem is that my computer doesn't have enough memory to fully upgrade my production to this new version. I'm now trying to roll it back to the old version. What a nightmare. 🙈

[bbb_999]

> I believe the problem is that my computer doesn't have enough memory to

> fully upgrade my production to this new version.

What leads you to believe that?

[atedwards]

We found a few common issues:

1. When Premiere crashes it does not delete the prlock file for open projects. They will need to be manually deleted.
2. One particular editor was, somehow, opening the Production alongside their recycle bin. This made Premiere think that the prlock files (that had been appropriately placed in the recycle bin by the OS) were still active. We don't know how or why this editor was doing that but we solved it by telling them to double check their project locations.

Beyond those two issues we weren't able to find consistent sources of the problem.