Film-Tech Forum ARCHIVE: Exporting subtitled DCPs from Doremi servers

This is topic Exporting subtitled DCPs from Doremi servers in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.

To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=002588

Posted by Pietro Clarici (Member # 4937) on 02-15-2016, 10:32 AM:

We often need to move content from one of our sites to another - we don't always have access to hard drivers, and each satellite transfer is enabled only at the specific site that the movie opens at: if/when we need to move a DCP to our smaller venue or viceversa, we're on our own.
(Yes, our local distributors are crap.)

Since we have never been able to export a file successfully via the "Export" option, the way we manage this is a bit of a workaround: we have a MacBook running an FTP client and server. We connect to one of the Doremi servers via FTP and we copy the relevant content in /assets to the internal SSD. At the other site, we get the Mac on the LAN and configure it as a source in Content Feed Manager and we ingest via FTP.

This works great, except with DCPs that have XML subtitles. I've tried countless times, but the XML subtitles files seem to lose a few bits during the transfer. Note that every other file is copied 1:1, this includes MXF audio/video tracks and other XML files like CPLs . As a result, every ingest fails, with the server reporting "file size is x (should be Y)". I tried to edit the PKL to mirror the "new" file size, and the ingest process manages to start but obviously fails at the CRC control.

I have no idea why this happens, and I can't manage to change the subtitle track back to its intended size - the file itself, by the way, doesn't look to be corrupt: it is perfectly readable in a text editor.

I know this is kind of specific, but I was wondering if anyone ever had the same experience and solved this. Thanks!

Posted by Marco Giustini (Member # 4544) on 02-15-2016, 11:03 AM:

I've been having similar issues transferring ASCII files via FTP. You can configure your client to transfer in ASCII or Binary mode. If set to auto I believe it should default to ascii when dealing with a text-only file.
You may want to try in binary - or maybe in ASCII if by chance the ftp client is always use binary. I'll admit I can't remember what the difference is but it just happened that backups I was taking of a website were simply unusable because of that.

Posted by Harold Hallikainen (Member # 5405) on 02-15-2016, 12:56 PM:

I also suggest using Binary ("Image") mode. With ASCII mode, line terminations can be changed between CR, CRLF, and LF depending on the FTP client. Binary mode just transfers the data as is.

Harold

Posted by Carsten Kurz (Member # 5396) on 02-15-2016, 06:55 PM:

The export function does work, it is just painfully slow.

- Carsten

Posted by Tim Sherman (Member # 569) on 02-15-2016, 11:52 PM:

Direct from Doremi

If you have a slow transfer rate when exporting a DCP / clip in the Content Manager to a eSATA drive.
Please try the following and see if makes a differance.
Insert a CRU drive. Then unmount it, then remount it and try to transfer a picese of content that you have
already transfered and not what the time should be.
The commands, are as followed.
Once the drive is mounted, you will need to unmount it.
Open a terminal window or use PUTTY.
Login, root / root password
Type mount <enter> to see what the path is.
For example: /dev/hdg /media/usb0
umount /media/usb0 <enter> for a USB connected drive
umount /media/esta0 <enter> for a CRU / esata connected drive
Then, you need to remount
mount /dev/hdg /media/usb0 <enter>
Then transfer the same content that you transfered eariler and see if the transfer rate has improved.

Posted by Pietro Clarici (Member # 4937) on 03-17-2016, 01:18 PM:

Can confirm that switching my FTP client to "binary" mode fixed it, FileZilla was indeed defaulting to ASCII for XML files.

Thanks everyone!