The basic problem is this: When working in one OS, if you replace an asset, save the project, and open the same project in another OS, the "replace footage" command will have been forgotten, and you will have reverted back to the old asset. Pretty scary if you're working in a team, and all of a sudden the next person dealing with the edit is inadvertently working with incorrect media.
In our office environment, we edit off of a server, and have done so for a long time now, without issue.
All systems used to be Macs, but we've started introducing some PC systems into the mix, and now we're starting to run into complications.
This is one of the more gnarly complications. To recreate the bug, we just follow this simple procedure:
1) Create a project in OS A (could be Mac or Windows), and then edit something. 2) Replace an asset in the timeline. 3) Save the project. 4) Open the same project in OS B (the opposite of whichever you chose in Step 1). 5) Marvel as your clip (replaced in Step 2) is linked to the old media.
Please note that the file name for the new media is completely different to the original, and often the codec is different as well.
A typical edit sees us using watermarked music in the early stages, and then once the client has approved the music, we will license the track, and replace the watermarked asset. So, it's not uncommon for the file names to change like this:
"demo_music.mp3" changes to "final_music.wav".
This only seems to happen with media that has undergone the "Replace Footage" treatment, and this never used to happen when we were only using the single OS.
One thing which I haven't previously mentioned is that thiswasn'thappening before the most recent update.
We've tried testing with Shared Projects as we were advised that this could help, but we had no luck, and ran into the same issues.
We also tried brute forcing our way around the issue, but unfortunately failed again. I'll explain, using the music example again.
When replacing demo music, instead of putting the licensed file into the same folder as the demo track, create a new folder, and put the licensed track in there. Within Premiere, use the replace footage command to link to the licensed track in the new folder. This should make Premiere look for 1) a new filename, and 2) a new folder.
No luck, unfortunately.
All systems are running the latest Premiere release (13.1.5)
I hate to say it folks, but we've since been trying with Shared Projects, and no luck. We're still running into the same problem. I'm more than happy to take any suggestions there.
One thing which I haven't previously mentioned is that this wasn't happening before the most recent update.
In addition to testing with Shared Projects, we did try one thing which I really thought would have brute forced its way around the issue, but unfortunately it was also a failure. I'll explain, using the music example again.
When replacing demo music, instead of putting the licensed file into the same folder as the demo track, create a new folder, and put the licensed track in there. Within Premiere, use the replace footage command to link to the licensed track in the new folder.
I really thought that this would have worked, as Premiere would now be looking for a different filename, in an entirely new location, but no dice. When we open the project on OS B, the files appear to be correct, but when you look at their properties, they're clearly looking at 1) the wrong file, and 2) the wrong location.
In the screenshot above, you can see an example from System B.
This is the audio bin in Premiere, which shows the clip "DX_JAPAN_020.WAV". When the project started, we were using the file JAPAN_020.WAV, but I eventually ran that file through external software for noise reduction, and saved it as a new file, "DX_JAPAN_020.WAV". This was saved in a new folder, as part of my brute force testing to get around this bug. I then used "Replace Footage" to change out the original JAPAN_020.WAV in the project.
This was all performed on System A.
The project was then opened on System B, and this is where the screenshot comes from. I've brought up the Properties for the clip, and although it is showing as being correct in the bin itself, you can see that it is linking to the incorrect file. For what its worth, it's also linking to the incorrect folder as well.