We are running into a really frustrating bug.
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.
I've posted this to UserVoice here:
A bit more detail on the issue:
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 this wasn't happening 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)
Windows 10 (1903)
64 GB RAM
Nvidia RTX 2070 (431.36)
iMac Retina 5k, 27-inch, late 2014
4 GHz i7
32 GB RAM
AMD Radeon R9 4GB
If you need any further information, please don't hesitate to ask. I'm happy to provide whatever might be needed. This is definitely something that is concerning us.
Are you using a Shared Project process and project structure?
Hey there Neil,
Nope to Shared Projects. We never use that functionality at all.
After saving the project, the user would either quit Premiere completely, or close the project, and only then would it be opened on the other system.
The other user is opening the same project file, so the structure, etc, is the same (I may have misunderstood this part of your question though 😛 ).
Use the blue reply button from the too post or this forum nests them.
I don't understand why you're not using the Shared Projects process. With each user having their login name, and any part in use automatically locked, it makes for a very handy and safe process. And is built to do exactly what you need, easier and safer than everyone opening up the same project with unknown bits saved locally and not on the server. Which I suspect is at issue here.
In my experience "shared" changes are pretty solid too.
Hahaha, we gave shared projects a go a while back, and ran straight into trouble, and have been pretty gun shy since 😛
Regarding locations, that's the thing, none of these files are stored locally. They're most commonly saved right next to the original files. Sticking with the music example earlier, let's say that we have our standard project folder structure on the server, we'll have a music folder, and the licensed file is saved right into there next to the demo track (different file name, and different extension, of course).
I wish that it was a case of the file being saved locally, but it definitely isn't. Thinking about it, even if it was a case of something saved into the wrong place, wouldn't that trigger the "reconnect media" dialog? It should be looking for a file with a different name, so I really don't know why it would be reverting back to an old file.
This is something we have only seen since introducing both Macs and PCs into the environment.
Adding a bit more info - I just remembered another bizarre bit of behaviour:
When we replace the footage, save, and close, and then open on OS B, the timeline will show the updated filename, but will definitely be using the wrong file.
If we reveal that clip in project, it shows the correct file in the bin, however if we reveal in Finder/Explorer, it takes us directly to the incorrect file.
So, yeah. Weird. Premiere will be showing that it's using the correct file, but heading to the actual file shows that things are not right in Denver.
I really do think the problem is the wrong project format. Individual projects assume they are saving things locally. You got by on one OS probably after a fair amount of experimentation.
But individual projects are not coded for how you are using them.
Shared projects are coded differently assuming all critical files are on the server. Try the Shared project system and see if it works better. I'm pretty sure it will.
"You got by on one OS probably after a fair amount of experimentation."
There really wasn't a lot of experimentation at all, to be honest. It was actually really straight-forward, which is why this has started to frustrate 😛 We basically behaved as though the server was the local drive, and it worked fine.
I really don't see how this is happening though, regardless of shared/individual projects, I just can't see how it is reconnecting to the incorrect media (but then showing different media within the project itself). For a moment I thought that it might be a media cache issue, but revealing in Finder/Explorer put that theory to pasture.
It just seems bizarre, which is why I've logged it as a bug, because I can't see it being anything but that.
Premiere individual projects use a mix of places they store data. Shared projects is a tighter process, especially when using a server.
I cannot think of a single reason for using individual projects formatting in a group working the same project on a server.
You're trying to make it work in a way it was never meant just because you were able to do it before in one way.
Shared projects is precisely what you should be doing. It is BUILT for group use across a server. Individual projects in the use you are making of them will have these issues. Pushed long enough.
Just riffing off of Neil here, as to the potential of "why" this is happening...
This is nothing I've tested by any means (we switched from Mac a while ago), but my line of thinking here is maybe source clips have 2 different directories in the backend. One for Mac and one for PC. If you think about it, PCs do use a different directory structure than a Mac. Your file may be D:\Premiere\Assets\mygreatvideo.mp4 on Windows, but that means nothing on a Mac. On a Mac it would be /MediaDrive/Premiere/Assets/mygreatvideo.mp4. Clip Names would appear to be correct as you mention however, as Clip Names aren't contigent on any directory, it's just an arbitrary name saved in the Project file.
The thing about all of this is, I don't know if you even CAN get around this. Would a backslash translate to a forward slash? I'm hardly a Mac/PC intercompatibility expert. The only thing I could think of is: are your servers mapped to a drive letter on PC? If so, I wonder if you tried bookmarking an unmapped drive and used that so it is \\X.X.X.X\Directory, and then replicated the same on Mac /X.X.X.X/Directory, I wonder if they would be able to read it. This is contingent on Premiere even bothering to do this though. Like I said, Premiere might just have seperate directories for a Mac and PC instance of a clip.
I wish I could offer something beyond that, but I do still believe that Neil's suggestion of working within Shared Projects, which is at least built with some sort of interoperability and shared assets in mind.
EDIT: Another idea to maybe try if you really don't want to use shared projects. Maybe for any media that you intend to sub out, put that into a nest instead, edit with the nest, and then have the editor import the final media as a NEW clip, and make the swap in the nest as opposed to replace footage. If for some reason importing NEW clips works without issue, maybe this could work.
I hear you on Shared Projects. Loud and clear 🙂
That doesn't change the fact that something bizarre is going on, and is that bizarre thing not worth investigating? If it's happening in this instance, where else could it be happening? That's why I've filed a bug about it. We're not the only people who have come across this either.
Let's say you're working by yourself, and you have network storage. You're on a PC, and then you decide to get a Mac and dive into the land of OS X, and leave Windows behind, or vice versa. You're just as likely to run into this problem , and at that point working in a Shared Project probably wouldn't have occured at all.
Again, I'm not saying that Shared Projects aren't a good thing, but I am saying that there is something weird being triggered, and that's worth filing as a bug. Or at the very least I definitely think that it is.
BTW, is there somewhere that we can file a bug for how this forum lays things out? 😛
I hear you, and am not saying it shouldn't be looked into if it can be improved, but as I mentioned there might be a genuine issue regarding the directory differences between PC and Mac.
I guess a good example is: say both workstations were PCs, and they both were connected to the same server. However, one server was mapped as M: and one was mapped as N: or they had different names (which sometimes is the case with server workflows when using multiple gateways to the same mediabase). There's a good chance that if you opened the same project across those two machines, media would either go offline or not be updated correctly because of how they have different relative directories.
Now obviously you would work to avoid this, but when switching between PC and Mac, this may be a bigger version of that problem. The project is saying "the file is here" but those instructions are relatively different on a per-OS basis.
You're correct about the individual user scenario, but they'd probably be one and done. They'd relink their footage accordingly with their new workstation, and go on using that. I'd call that regular and expected behavior of an OS change, unfortunately I think those issues are being exploited when going back and forth as often as you are, and doing so with a shared project file.
Like I said: if there's a way to perfectly translate PC directories to Mac directories, then I'll be all for it if Adobe can implement that in a future release. I just don't know if that will happen in a timeframe that is satisfactory to you for your work. Like I said, the nesting approach might work if you didn't want to use Shared Projects.
When opening up a new project for the FIRST TIME on the "other" OS, do you have any issues with the previously imported media? Or is everything there perfectly without the need to link?
Maybe the solution is to simply replace the original source file with the new media using the same file name. Probably smart not to have Premiere running at the time. And probably smarter to make sure codec, etc match. Someone would need to be in charge of this cause if you have multiple editors screwing with stuff, things could get messy. Keeping a log of all such changes is probably key.
I was just typing out a reply, and...it's gone. I have no idea what just happened. So...if a randomly unfinished response shows up, my apologies.
Anyways, thanks to all for their thoughts and suggestions. I'm still curious to hear from Adobe on whether the switching could be done more seamlessly (like with AE, where the worst issues we've encountered with switching might be fonts, or plugins not available on the new system), or if that's just something of a pipe dream. Or, if they have more of an idea on how things show one way, but are actually another.
I've become pretty interested in seeing what will happen if I try a couple of different things (more out of curiosity than anything else). I'm interested to see what happens if I delete the old file after linking to the new, and seeing if that forces system 2 to either see the correct file, or bring up a missing footage dialog.
When I get time over the next week I shall take a look, and can post back here if anyone else is curious? If you would like me to test anything else, chime on in, and I'll get my lab coat ready.
AWH11, yeah, I think both you and Neil are definitely correct there about the backends. I'm still curious as to why it's looking for one clip, showing that clip in Prem, but linking to a completely different one. Regardless, I do appreciate your responses, and thoughts. All very helpful! 🙂
Just to touch on your suggestion MrGrenadier, the watermarked files are typically MP3s, while we far prefer using WAV or AIFF for the final files, so that explains the codec difference. Also, having matching file names would probably be a bit too close to tempting fate, and having someone unwittingly grab a watermarked file when they're thinking it's a licensed file is not really worth it, especially if it's a fast turnaround scenario were they can easily miss the watermark.
Again, thanks all. Neil, I see that you had a cool response in my E-Mail notifications, but I'm not seeing it in the actual forum posts. So...go forums, go! 😛
To post something as a bug, they have the UserVoice system which goes directly to the engineer's system and also to upper managers (that part in a collated format).
Adobe UserVoice Bug /Feature form: https://adobe-video.uservoice.com/forums/911233-premiere-pro
This forum does paginate ... so scroll down, and you can see the page numbers ... select an earlier one to go back and look through earlier posts.
Thanks, Neil. Do you mean for this whole relinking thing? I made the UV post before posting here - link in my original forum post.
I tend to post in both places, as I'm always keen to hear if anyone else has any ideas/workarounds, or run into similar issues, and UV in the hopes that it gets to the engineering side 😛
Yea, glad to hear you'd posted this on the UserVoice system. Which is a VAST improvement over the previous system.
If you just hit the 'reply' button at the bottom right of each thread, you get a nested one-paragraph reply box. Hit the enter/carriage return key on your keyboard, it sends the reply. Nested. Which is why using the blue Reply button for the top of each page is SO much better. Sigh. Stupid forum structure ...
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.
Definitely got something stuck in the cache or cache database files. On the originating system AND the B system, close Premiere and manually delete all Premiere cache and cache database files.
Maybe even completely remove the project from the B system.
Then at the A system, launch the project and as it's rebuilding cache file make sure the correct files are in place and referenced. Then move the project to the B computer as if it was just seeing it.
Hey there Neil,
Cheers for the suggestion! I'm giving it a try now. Will post back shortly.
Hey there Neil,
No luck unfortunately. Manually deleted all of the Media Cache, and Database files on both systems. Started up System A, and let it do its thing. Closed out and started up System B, but no luck.
Perhaps I missed something? Deleted all of the Peak files as well, just in case. Emptied trash, and recycle bin.
Unfortunately I'm just about to head out of the office for the weekend, but any suggestions you might have I will dive into first thing next week.
Thanks heaps, as always!
Got me dry on this one Darren. Sorry!
Thanks anyway, Neil. Always appreciated!
Hopefully we hear something from Adobe at some point.
Product Support manager Kevin Monahan added a thread linking to a clear and concise article on using Shared projects over a server. Here:
I really do think you need to go read through that article and try out the Shared projects. It is no more difficult that using the individual projects you have been using, but ... as said before ... it IS designed to accomplish exactly what you need reliably.
Individual projects ... are just not designed for your workflow. "It worked under X circumstance" ... well, you aren't on a mono-ecosphere for computers anymore. This is the process designed by the engineering staff particularly for your needs.