This makes a lot of sense, I've been getting the status "WARNING: Low work storage! The job will continue when you have at least 6 GB free storage." in FFAStrans when transcoding a lot of the IV heavy days (very long takes so the cache gets full), but I had read that message to mean it would continue after space was freed up?
I'm going to try moving the cache from the 300GB SSD to the 90TB RAID (stores all the media, so it will save on transfers at least) to see if this prevents the issue.
Yeah, working on a "too small" disk is problematic. Even if ffastrans checks the space before a process starts, it cannot foresee how much space is needed for your transcode format, then what about multiple paralell processes etc...
If you switch your "cache" to the storage where your files go in the end, make sure you check the "move instead of copy" checkbox at the deliver nodes, this way you save a lot of I/O and time.
Yes it's definitely a lot quicker to transfer these large files when set this way and I think it may actually be faster in total job time to. Best part is that now after moving the cache I am no longer having the "short" transcodes issue. Every batch since has been perfect. Thank you so much for you help emcodem! I wouldn't have got this far without your very generous in depth help on these issues. I'm thrilled to have it working smoothly and can now work on automating even more of the workflow.
Thanks for the flowers Vinny
As a result of this topic, thankfully the bmx guys added a commandline switch to bmxtranswrap "--umid-type" which should be set to "uuid".
The changes are currently only in the code, we will need to wait until they released a new public available build before we can ask steinar here for utilizing this new feature of bmxtools.
