Digidelivery For Post

[Rick Sanchez]

I have not read anything about OMF delivery through Digidelivery. I assume that since you can drag and drop files, that sending and receiving OMF or AAF from an Avid to Protools is possible. Anyone doing this and how well is it working?

[Rock_Artist]

DigiDelivery sends ANY file you desire.
Works fine and even add its own compression to make the u/l - d/l faster...

[bigbadhenchman]

We've used it in a Post setting, and it works great.

[Jason Vreeman]

We have been using the appliance for a short time. The server tends to corrupt larger files (exceeding 1.5Gb) and downloads end up crashing the client software. The crash is indifferent to the OS the software is on. Since the problem is intermittent, it is very hard to nail down the where's and why's. The same sender can repost the file 5 times and it may crash the client software on 2 of the downloads. There is some question as to whether this is related to posting to the recipients digi box as opposed to posting to the senders own box and forcing the long distance download.

There is also a question as to fragmentation and how to "defrag" the drive. We have probably pushed 10 projects through the server in the past month and the drive has to be pretty frangmented. I just haven't found the "defrag" button. This may need to be an option in a future software upgrade.

One last concern (and I don't mean to rant, we like the box and the service) is the security of the plain text email system. It may be worth while to look into a second line of defence by adding an authentication password to the login for download. The user would be sent a second (separate) email with an authentication password that will need to be used once the hyperlink is clicked on but before the client software begins the actual download. If not this way, then the sender would need to set up a password login system and communicate this to the recipient. Just an idea.

[Pythagor]

Do you have relay on? We managed to receive 99% deliveries without problem switching it off...

Leo

[Gordon Lyon]

RE File corruption: Please see the post labeled 2.1 Client Update. Though rare for most users, a few have had regular problems. This update should address that problem. Relayed deliveries also have the same error correction and reliability.

RE Defragmentation: I'll bring this up with engineering - thanks for the suggestion.

RE Secondary Authentication: If, when sending the delivery, you uncheck the box labeled "Include encryption key in email", you will be prompted to save the summary, which contains the encryption key for each recipient. You will then need to transmit that key to each recipient in a way that you feel is secure (phone, fax, etc.). When they attempt to download the delivery, each recipient will need to enter the key manually.

Thanks, Gordon

[Jason Vreeman]

Thanks Gordon. The new Client Software helps tremendously. I updated as soon as I was prompted (BTW the Mac based software does not prompt, whereas the PC version definitely did...is this consistent with your findings?)

I understand that the encryption key can be sent separate from the delivery notification. My only thought, as an end user, is that this is a bit cumbersome and timely. It is not exactly "user friendly" in its execution.

Best regards.

[Gordon Lyon]

"the Mac based software does not prompt, whereas the PC version definitely did..."

Any chance the Mac system had already been updated to bld 390? If so, then it would not prompt you to update to 393, which just has some minor bug fixes (see update notes on digidelivery.net)

RE transmitting the key manually, we know this is a bit cumbersone and time consuming, and we're considering some simpler options.

Thanks for teh feedback.

-- Gordon

[Jason Vreeman]

Gordon,

No we were definitely using an older version of Client Software. We had some struggles downloading from a customer using the new build and couldn't put our finger on the problem. As it turned out, by upgrading to the new build the problem went away.

Thanks

Jason