hey all. I’ve had to shift a job to a new SSD. using path translation cant get it to see the new stuff. im sure I’ve made this work before. so I was on say driveA/Aprojects/project and now im on driveB/Bprojects/project. so im never sure what’s the source and what’s the destination. so I’ve tried it both ways round and its not finding the new footage. I assumed the source was the original clips path and the deistination is the new clips path. so I did a translation that said. driveA/Aprojects to destination driveB/Bprojects. I’ve even tried the specific project name as well. I thought it was smart enough that you just had to point it in the right direction.
Source is driveA/Aprojects/ and destination driveB/Bprojects/ . I assume that you are talking about archive/restore project, aren’t you?
hi. no everything is non cached. just trying to point the clips to a different destination. the menu is in the storage menu in preferences - autodesk very bad implementation of a relink function!
I´ve only used translation path restoring non-cached projects by using archive. No idea how translation path can work with clips already imported. I would say that change paths in conform tab (it can be edited) should be enough, but it never worked to me. In addition, it would only be useful for sequences not for individual clips. Indeed, I agree with that relink footage is unnecessarily obscure in flame.
For lack of anything better, I would suggest archive/restore the project. It’s works to me for move uncached projects among flames:
If you can connect the original SSD again and open the project in its original state, archive (without caching, sure) the project, and restore a copy having set the translation path. The new project will point its footage using new path.
2 Likes
I’ve had it in the past where the new drive was mounted differently and no matter what I did the path translation wouldn’t work. Ended up reconforming instead.
Hey there @Jonhollis. I recently had to figure out path translation and I’m with you that there some aspects of it that are a little strange.
Where I landed is that in order for path translation to work I discovered that I needed to do an archive restore and ensure the setting “convert to local path” was enabled during the restore. Once I did that, I found path translation was finally working but wouldn’t work if I didn’t restore it this way.
3 Likes
thanks for that - I think I’m going to try this. it is a truly woeful part of the software to be honest. every other NLE on the planet can auto relink search and replace etc etc.
1 Like
and thanks for the amazing flame tutorials by the way
3 Likes
its also super annoying that its not stored on a project by project basis
1 Like
It sucks. It works for us in one location (Auckland) but not at all in another (Sydney). Super infuriating.
Probably not it: but I spent forever with a path that didn’t work. The entire time I was missing a slash at the start of the path name.
I’ve recently used it successfully. What I would try is rebooting your compute, mount each drive if they dont already and when you go to the flame prefs/storage, use the browse source and destination buttons.
Source = original path as seen when you alt-click on a file
Destination is the new path.
*** paths ARE case sensative
If that doesnt work try defining a path 1 level back
I just tried this with and without Pattern Browsing and it seems to work, maybe other versions have issues:
Import clips from the old and new locations.
Splice those 2 clips, then unlink. Open the two unlinked clips as a sequence, in the conform list select each file location name from the file location column to get the paths into the name buffer.
In Prefs-Storage-Path Translation, enter the old location as source, new location as destination, press refresh. Also on the Desktop maybe try Refresh Thumbnails.
If you wish to make the path changes permanent, unlinking the clips, open as sequence,
choose “Link to Media File”, then the path translation isn’t needed for that media
Instead of path translation, you can also edit the paths of unlinked clips in the conform list “file Location”.
Other times it may be easier to add a symlink (ln -s source destination) from the terminal with Mac OS.
Yes! was going to say to try this!
Hey @Jonhollis, reviving this topic since I decided to give path translation another try this weekend–last time I gave it a whirl, things didn’t seem to be working at all. This time, 2024.2 it seems to be working exactly as expected. But there’s a catch. It seems to only be working correctly on a Mac.
My test was copying a project over from Lucid to the NAS. Adding a path translation of →
…and disconnecting from Lucid, works fine on the Mac. Batches load, openclips version, the whole 9 yards–everything that was published to Lucid happily loads directly from the NAS with that one simple rule set.
Now, there are some other issues with it that I’d like to see resolved, but for what it’s supposed to do at its core it works. I then took it for a spin with Synology drive, mounting the project share in a user home directory, updating the destination path in preferences and that too just worked, with the added benefit of syncing results back to the NAS. And this is really what I’m here fucking around with–getting remote artists to have access to shots with no need for worrying about pathing once the rule is set. So hey we’re good right?
So I hopped over to one of the Linux flames. All of the machines have the same pathing, so I copied and pasted the rule over to the Linux box and whomp-whomp–checkerboard city, the second I disconnected from Lucid. Nothing worked as it had on the Mac. Nothing.
Big fat defeated sigh. @Slabrie even if we don’t do tokens right now it would be great if the path translation capability worked on both platforms.
1 Like
hey there - yes im getting similar results - im only on Mac. I still think it’s not good enough though. needs to be like Resolve. Relink button that searches for the footage.
1 Like
Hello Chris!
What error do you get on the Linux side? What are the source & destination paths?
Salut @Slabrie. Source and destination paths are the same on Mac and Linux as all the volumes are mounted on the same paths on both sides.
Lucid mounts at: /Volumes/cloud on both Mac/Linux and the NAS mounts at /Volumes/projects on both Mac/Linux. The project directory is at the root level of my Lucid filespace, so the path translation I’m mapping is :
SOURCE - /Volumes/cloud/projects
DESTINATION - /Volumes/projects
which looks like this on both platforms →
Next I verify that the source and destination paths contain the same data. First a listing from the Mac that’s working followed by a listing from the Linux box that’s not. As you can see, both source and destination paths have the same frame on both machines.
Next, in the Linux Flame, I unmount the Lucid filespace where the project originally references its media. Immediately the Linux Flame goes to checkerboards →
…and errors flood the shell →
Remember though that this path is verified from our earlier step. There’s no reason for it to error. Hope this helps.
The plot thickens, @Slabrie. So I did the same thing in reverse. This time I published an edit from the Linux machine. Added the same path translation rule as above, disconnected from the Lucid filespace and this time the Linux Flame happily switched over to the destination pathing no problem.
So then I switched over to the Mac. I added the same path translation rule as I had on the Linux Flame, unmounted the Lucid filespace and everything published from the Mac earlier showed up, but nothing that the Linux Flame had published worked–it was all errors like these in the shell:
'/Volumes/cloud/projects/VFX_test_15/_04_shows/gv3/gv_020/FLM/images/plates/gv_020_bty_L01_v00/gv_020_bty_L01_v00.0991.dpx' not found [Filesystem operation failed] (/Volumes/raid/AutodeskMediaStorage/stonefs0/ManagedFolder0/8/0xc84002a60000003d.mio)
Cannot access frame 34: '/Volumes/cloud/projects/VFX_test_15/_04_shows/gv3/gv_020/FLM/images/plates/gv_020_bty_L01_v00/gv_020_bty_L01_v00.0991.dpx' not found [Filesystem operation failed]
Resize : Cannot access frame 34: '/Volumes/cloud/projects/VFX_test_15/_04_shows/gv3/gv_020/FLM/images/plates/gv_020_bty_L01_v00/gv_020_bty_L01_v00.0991.dpx' not found [Filesystem operation failed]
Anyhow–I’m going to give up for now. This is just too strange.
Thanks a lot Chris for all the details!
Looks like a macOS vs Linux configuration challenge more than a Flame issue.
As you can see in the error message, “Filesystem operation failed” is displayed.
Are you able to browse the location of the media files in MediaHub?
Could you have a look at the file permissions?
I suspect user / group permission between you macOS and Linux environments. If you are using the same user identity between your Linux and macOS, make sure they have the same data. In a shell, type this command:
id
And make sure they primary groups and group UID is the same.