You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently goprox only supports a single storage hierarchy even though portions of the library can be distributed across multiple storage volumes by leveraging links for subfolders of it. For example imported can be located on one dedicated SSD while processed can be located on another SSD and archive can be mapped to an internal drive. Distributing the media file structure can help with growing libraries and leverage the full throughput of current MacBooks or similar.
However, in cases where processing is performed in multiple physical locations - for example, mobile - on-the-road capture and import vs home/office post-processing a more complex storage hierarchy might be required.
While out on set or on the road, capture from SD cards needs to happen rapidly and often involves minimal infrastructure, commonly with external HDD or SSD devices.
When back in the production studio or office, additional storage devices with much larger capacities are often used to collect all the media files for an entire or even multiple projects.
Currently, the workflow is rather manual and requires goprox configurations that are different from field/road to office/home which in turn requires manual copying and transferring of media.
Proposed solution
Add the principle of mobile vs home configuration setups to goprox and select the environment at runtime or potentially even autodetect the environment based on the availability of certain storage devices connected to the computer.
In Mobile mode archive/import and optionally process media data into staging devices eg external SSDs connected to the laptop.
Once back in the office/home migrated these staged media files into the permanent storage hierarchies.
Related
In addition, expand this capability through the support of AWS S3 Glacier storage #11 for long term archival of no longer actively required media files
The text was updated successfully, but these errors were encountered:
Currently
goprox
only supports a single storage hierarchy even though portions of the library can be distributed across multiple storage volumes by leveraging links for subfolders of it. For exampleimported
can be located on one dedicated SSD whileprocessed
can be located on another SSD andarchive
can be mapped to an internal drive. Distributing the media file structure can help with growing libraries and leverage the full throughput of current MacBooks or similar.However, in cases where processing is performed in multiple physical locations - for example, mobile - on-the-road capture and import vs home/office post-processing a more complex storage hierarchy might be required.
While out on set or on the road, capture from SD cards needs to happen rapidly and often involves minimal infrastructure, commonly with external HDD or SSD devices.
When back in the production studio or office, additional storage devices with much larger capacities are often used to collect all the media files for an entire or even multiple projects.
Currently, the workflow is rather manual and requires
goprox
configurations that are different from field/road to office/home which in turn requires manual copying and transferring of media.Proposed solution
Add the principle of mobile vs home configuration setups to
goprox
and select the environment at runtime or potentially even autodetect the environment based on the availability of certain storage devices connected to the computer.In Mobile mode
archive
/import
and optionallyprocess
media data into staging devices eg external SSDs connected to the laptop.Once back in the office/home migrated these staged media files into the permanent storage hierarchies.
Related
In addition, expand this capability through the support of AWS S3 Glacier storage #11 for long term archival of no longer actively required media files
The text was updated successfully, but these errors were encountered: