User Functions
Don't have an account yet? Sign up as a New User
Who's Online
Guest Users: 10
|
| View previous topic :: View next topic |
| Author |
Message |
Toby@ITV partially protected

Joined: 02 Dec 2008 Posts: 9
|
Posted: Thu Jul 15, 2010 1:55 pm Post subject: The ever expanding Proxy Bundle |
|
|
Hi there-
We have a major concern down the pike for us. We are about 6 months into what I would describe as a "full on" FCS usage. It's no longer an experiment, but it's something our facility of 8 editors, 2 compressionists, 3 gfx guys and 10 producers are using everyday.
We have an assistant editor who on average ingests 50 XDCAM HD discs into FCS every month. Sometimes it's less, sometimes it's alot more.
Currently our Proxy Bundle is tipping the scales at 1TB. Several months ago I reduced our proxy bitrate to approx 1800 (h.264) and that I imagine has helped considerably, but we really can't go much lower quality-wise. At our current rate of work and proxy expansion, I see the proxy bundle needing it's own RAID or JBOD within the next 1.5 years. This strikes me as absolutely nuts. A small company like ours that happens to do "big company" volume simply cannot keep up with that sort of rapid expansion. Apparently the word is that FCS does not replace proxies, it's merely adds more. I did a test one day by reanalyzing the same proxy over and over again to see if the bundle would stay the same size, but no...after every re-analyze, the thing grew and grew. I wish there was a way to manage these versions under the hood.
-Are there any rumblings from Apple about a way to manage proxies in the future?
-Is there any way to do so now?
-COULD I dispose of the proxy bundle and take a long weekend to re-analyze the thousands of HD clips in there into a new lower res proxy? (Like I said, I just changed the h264 bandwitdth into something more manageable...but 90% of the proxies were encoded considerably higher).
In regards to a re-do of the proxies, I've heard two conflicting opinions. One person has suggested I simply toss the bundle and re-analyze. (It would take days, but if it saved me 500 gigs of expensive Raid 6, it would be worth it). ANOTHER expert has told me NO, I cannot just toss the bundle and start recreating new ones...I'd need to begin with an empty bundle in it's place. Would changing the proxy device location in FCS prefs recreate an empty bundle for me?
What do you guys think? I opened the proxy bundle today to see the contents, but it was pretty indecipherable as to locating duplicates.
-Toby |
|
| Back to top |
|
 |
MattG Xsan Master

Joined: 15 Apr 2005 Posts: 456
|
Posted: Thu Jul 15, 2010 11:09 pm Post subject: |
|
|
While I'd be reticent to give you on an opinion on what you should do, I can shed a little more light on the Proxy bundle and its function.
It's a bundle only for the reason that a bundle is somewhat protected from further digging into via the Finder by the average Joe. Really, it's just a staggeringly large number of folders and subfolders, eventually with single files in each folder. The folder names correspond to an ascending counter in Final Cut Server that assigns these names to hidden fields for each asset. This is how Final Cut Server "finds" the derivative representations of its assets. Remember, the Proxies bundle not only contains H264 proxies, but also thumbs and poster frames as well.
Given this, if you simply blow away the bundle, and recreate another one by simply naming a folder "Proxies.bundle" in the same place*, that's all FCSvr will need to "start again" with its process of storing more proxies and thumbs and poster frames. The counters won't reset, and all links to what FCSvr thinks used to be in the old bundle will of course be broken. However, reanalyzing each asset will get you new derivative representations.
Please let us know if you've found another way, but the biggest problem of all is that of reanalyzing all your assets. The best practice here is to select them as an admin user and select Regenerate All Proxies from the contextual menu. Now in 1.5.X, you could set your search return to the maximum 2,500 assets, select the first asset in a search, go to the last page, shift-click the last, and ask for 2,500 assets' proxies to be remade. But I can almost predict a crash of the fcsvr_stored process if you attempt that.
So, let me offer the last sane idea, which is simply to relocate the current Proxies bundle to another location, like a newly puchased DAS hanging off the FCSvr. All you need to do is ditto the bundle to the new location, and then in the Device pane of the Admin window in FCSvr, just edit the path of the device. As soon as you save, FCSvr will source the proxies, etc. from the new location and write new ones there as well. Through the magic of relative pathing, everything is still accessible.
In all the classes I teach on FCSvr, I stress the importance of planning out a relatively permanent place for the proxies, but also mention the relative ease by which you can move them in the future. Yes, it was always the intention of the engineers for the bundle to grow and grow, especially since accessing proxies of assets long archived was a critical feature that most shops want to have.
*If you actually do this, it's important that the bundle is owned and has rw permissions for the same admin user that you used to install FCSvr. |
|
| Back to top |
|
 |
Toby@ITV partially protected

Joined: 02 Dec 2008 Posts: 9
|
Posted: Fri Jul 16, 2010 10:03 am Post subject: |
|
|
Matt-
Thank you for responding. I'm going to share this letter with our FCS integrator and come up with a game plan.
Do you you personally have any clue why Apple chooses to keep creating new proxies instead of blowing over old ones? We were informed by Apple that they create "transient" proxies....every time any asset moves in or out of server that new proxies are being created. There could theoretically be 100 proxies for the same clip depending how many times it's been checked in and out.
Also, using this logic:
So, let me offer the last sane idea, which is simply to relocate the current Proxies bundle to another location, like a newly puchased DAS hanging off the FCSvr. All you need to do is ditto the bundle to the new location, and then in the Device pane of the Admin window in FCSvr, just edit the path of the device. As soon as you save, FCSvr will source the proxies, etc. from the new location and write new ones there as well. Through the magic of relative pathing, everything is still accessible.
....could I move the current proxy bundle to a new location for safe keeping (we currently have them mirror to a RAID 0 G-RAID for backup), then simply DELETE the bundle in it's current location, place a new "proxies.bundle" folder there and then begin a well paced process of re-generating the proxies? (You are right though, doing 2500 at once would burn our building down).
Thanks again Matt....it's really cool to have you answer this!
-Toby
| MattG wrote: | While I'd be reticent to give you on an opinion on what you should do, I can shed a little more light on the Proxy bundle and its function.
It's a bundle only for the reason that a bundle is somewhat protected from further digging into via the Finder by the average Joe. Really, it's just a staggeringly large number of folders and subfolders, eventually with single files in each folder. The folder names correspond to an ascending counter in Final Cut Server that assigns these names to hidden fields for each asset. This is how Final Cut Server "finds" the derivative representations of its assets. Remember, the Proxies bundle not only contains H264 proxies, but also thumbs and poster frames as well.
Given this, if you simply blow away the bundle, and recreate another one by simply naming a folder "Proxies.bundle" in the same place*, that's all FCSvr will need to "start again" with its process of storing more proxies and thumbs and poster frames. The counters won't reset, and all links to what FCSvr thinks used to be in the old bundle will of course be broken. However, reanalyzing each asset will get you new derivative representations.
Please let us know if you've found another way, but the biggest problem of all is that of reanalyzing all your assets. The best practice here is to select them as an admin user and select Regenerate All Proxies from the contextual menu. Now in 1.5.X, you could set your search return to the maximum 2,500 assets, select the first asset in a search, go to the last page, shift-click the last, and ask for 2,500 assets' proxies to be remade. But I can almost predict a crash of the fcsvr_stored process if you attempt that.
So, let me offer the last sane idea, which is simply to relocate the current Proxies bundle to another location, like a newly puchased DAS hanging off the FCSvr. All you need to do is ditto the bundle to the new location, and then in the Device pane of the Admin window in FCSvr, just edit the path of the device. As soon as you save, FCSvr will source the proxies, etc. from the new location and write new ones there as well. Through the magic of relative pathing, everything is still accessible.
In all the classes I teach on FCSvr, I stress the importance of planning out a relatively permanent place for the proxies, but also mention the relative ease by which you can move them in the future. Yes, it was always the intention of the engineers for the bundle to grow and grow, especially since accessing proxies of assets long archived was a critical feature that most shops want to have.
*If you actually do this, it's important that the bundle is owned and has rw permissions for the same admin user that you used to install FCSvr. |
|
|
| Back to top |
|
 |
JonE RAID 5

Joined: 22 Sep 2005 Posts: 17
|
Posted: Mon May 09, 2011 10:50 am Post subject: Has anyone had a go at this? |
|
|
| MattG wrote: |
So, let me offer the last sane idea, which is simply to relocate the current Proxies bundle to another location, like a newly puchased DAS hanging off the FCSvr. All you need to do is ditto the bundle to the new location, and then in the Device pane of the Admin window in FCSvr, just edit the path of the device. As soon as you save, FCSvr will source the proxies, etc. from the new location and write new ones there as well. Through the magic of relative pathing, everything is still accessible.
|
Hi, it looks like we need to have a go at this for one of our installs. I'm not sure what MattG means by 'ditto' to the new location. Ideally we'd like to move the bundle to a bucket of some description and tell FCSvr where the bundle is.
any suggestions will be gladly received |
|
| Back to top |
|
 |
JSamuel Xsan Master

Joined: 05 Jan 2011 Posts: 169
|
Posted: Mon May 09, 2011 11:21 am Post subject: Re: Has anyone had a go at this? |
|
|
| JonE wrote: | Hi, it looks like we need to have a go at this for one of our installs. I'm not sure what MattG means by 'ditto' to the new location. Ideally we'd like to move the bundle to a bucket of some description and tell FCSvr where the bundle is.
any suggestions will be gladly received |
JonE,
Ditto (Terminal - 'man ditto') is a copy command. You could achieve the same with a well flagged rsync etc... Moving the FCSvr DB isn't as clean as changing the device location, you have to create a symlink ('man ln')
I personally prefer the FCSvr DB onto a HW RAID1 set of raptors or the like... |
|
| Back to top |
|
 |
abstractrude Xsan Master

Joined: 13 Mar 2008 Posts: 860
|
Posted: Mon May 09, 2011 11:27 am Post subject: |
|
|
i always dedicated a raid 5 lun for my proxy bundles. usually in xsan integrated environments i would have the customer purchase the half full promise raid. two drives for metadata for the san volume, a hot spare and the other 5 drives as a lun for the proxies for FCS. works pretty well. you can use lum affinties on the raid controller to make sure your proxy traffic doesnt affect san performance.
when saying ditto he means use the ditto command to copy the data. its ussually the best way to copy mac os x data. its also nice that it keeps your modification times and permissions intact and all extra filesystem metadata too. i used to symlink the fcs database other places but it turns out i didnt see a performance increase. |
|
| Back to top |
|
 |
JonE RAID 5

Joined: 22 Sep 2005 Posts: 17
|
Posted: Tue May 10, 2011 5:39 am Post subject: |
|
|
Hi JSamuel and Abstractrude...
Thanks for your replies. I might be over-thinking this - so sorry if that's the case.
So once the proxy.bundle has been ditto'd to the new location, i can tell FCSvr to run the proxies from this new location and then safely delete bundle from the old location?
Thanks,
Jon |
|
| Back to top |
|
 |
JSamuel Xsan Master

Joined: 05 Jan 2011 Posts: 169
|
Posted: Tue May 10, 2011 5:49 am Post subject: |
|
|
| JonE wrote: | | So once the proxy.bundle has been ditto'd to the new location, i can tell FCSvr to run the proxies from this new location and then safely delete bundle from the old location? |
Backup, Backup, Backup
Yes, change the device location, FCSvr should re-scan it and pick everything up in the new location. Once you've verified this is working, you can delete the original. |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|