Film-Tech Forum ARCHIVE: Dolby DSS200 File format

This is topic Dolby DSS200 File format 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=002964

Posted by Abdullah Shamsi Basha (Member # 9894) on 03-06-2017, 06:53 AM:

Hello, Thank you for having me here.

I would like to screen my movie in a cinema theater equipped with Dolby DSS200 server. I have two questions.

Dose the DSS200 accept hard drive input throw USB port, in other words, can I play my film with a normal USB3.0 Hard drive throw USB port?

What file formats of the hard drive that can be readable by the DSS200 ?

I have already exported my film to DCP.

Thank you.

Posted by Mike Schulz (Member # 4297) on 03-06-2017, 08:19 AM:

If you've already turned your film into a DCP then you should be good to go as long as it's the standard framerates and it's Interop or Smpte. The external USB3 hard drive should be partitioned with Ext2 or Ext3 ideally but that server will also accept Fat32 and to a lesser, not so reliable, extent NTFS. It will not accept the MAC/Apple file systems.

Posted by Jim Cassedy (Member # 4115) on 03-06-2017, 09:00 AM:

Also - be aware that you can not "live play" content through the USB port.
The content must be ingested into the server first, & played back off of
the server's internal RAID drives. So you need to allow time to do that.

Mike gave you basically good advice about the file systems, but I
must say that my personal experience is that I've never had any
problem using NTFS on a Dolby DSS 200, and I've done this several
dozen times on at least half a dozen (and possibly more) servers at
many different locations.

Posted by Leo Enticknap (Member # 534) on 03-06-2017, 10:06 PM:

quote: Mike Schulz
but that server will also accept Fat32 and to a lesser, not so reliable, extent NTFS. It will not accept the MAC/Apple file systems.

From my DSS200 trials and errors, I'm pretty sure that the situation is as follows.

Your drive HAS to have a MBR partition table: it won't read any drive with a GPT partition table, even if the content partition is one it can support.

Assuming that the drive has a MBR (MS-DOS) partition table, then the DSS200's filesystem compatibility appears to be as follows:

Will read: ext2, ext3, FAT32, NTFS, HFS+
Will not read: ext4, exFAT

For ext2/3, the DSS200 is not fussy about the inode size. ISDCF specs state that it must be 128 bytes, but mke2fs uses 256 as the default. I've occasionally formatted drives and forgotten to add the "-I 128" tag, and they've still read without problems in a DSS200.

Also, if a drive has multiple partitions, the DSS200 will only see the first. This can cause problems when first time DCP makers buy a flash stick or portable hard drive from Office Depot, that has an EFI partition on it, thereby preventing the DSS200 from seeing the content partition. These drives need to be totally nuked (as in, the partition table rewritten and then a single content partition created, occupying the entire drive) in order to be usable in a DSS200.

Posted by Steve Guttag (Member # 268) on 03-07-2017, 07:05 AM:

Really good info Leo!

Posted by Antti Nayha (Member # 4980) on 03-17-2017, 01:26 PM:

Some additions/updates, based on my experience of inspecting & handling about a thousand festival DCP's each year:

1) exFAT is supported since Dolby System 4.7. Still a terrible choice for distribution media: prone to corruption, slow when used with spinning hard drives, and many (most?) DCI servers don't support it anyway.

2) Hard drives / USB sticks with a GPT and a single HFS+ partition (the default Mac combination) are supported at least since v4.4.

3) Out of all these options, you can only write to FAT, ext2 or ext3 drives. (Some of the more obscure *nix filesystems such as xfs will also work. Incidentally, I think xfs is what the DSS uses for its internal RAID drives.)

For what it's worth, I do receive a higher percentage of corrupt NTFS and HFS+ drives compared to ext2/3 drives. HFS+ is generally a crappy and outdated filesystem, so no surprise there... NTFS, on the other hand, is supposed to be fairly robust. My best guess is that NTFS filesystems sometimes get corrupted when unmounting them from Linux DCI servers without an eject/unmount button in the software. [Shrug]

Posted by Mike Schulz (Member # 4297) on 03-17-2017, 06:31 PM:

quote: Antti Nayha
My best guess is that NTFS filesystems sometimes get corrupted when unmounting them from Linux DCI servers without an eject/unmount button in the software.

In my experience working with Linux whether it be cinema servers or my personal PCs and Laptops, if you don't unmount an external drive that is formatted with NTFS, the system sometimes won't be able to mount NTFS again until you reboot. This can be problematic somewhat when you're ingesting a lot of content for a festival and going from one drive to the next.

It is possible that some of the NTFS drives you thought got corrupted somehow might have been fine but it was your cinema server itself that got hung up after a drive got yanked without a proper unmount.

This leads me to another question. How come the server manufacturers don't have an unmount button/option built into their UI's? Is it really as simple as they think it would cause too much confusion to a majority of managers/operators and they are trying to make it as simple as possible?

Anyway, unless I'm copying something small like a trailer or an under 10-minute short, I always use ext2/3 just to be on the safe side. I believe it's always better to use the native OS formats.

Posted by Antti Nayha (Member # 4980) on 03-18-2017, 04:48 AM:

quote: Mike Schulz
It is possible that some of the NTFS drives you thought got corrupted somehow might have been fine but it was your cinema server itself that got hung up after a drive got yanked without a proper unmount.

Actually, I wasn't talking about drives that won't mount in a DSS... Yes, some of those problems can be fixed by a reboot or running a simple fsck/chkdsk/etc. on the drive.

Rather, I meant cases where the drive does mount but the ingestion/verification fails, or where dcp_inspect's hash check fails even before connecting the drive to a DCI server.

Of course, this kind of data corruption does happen with all file systems. It just seems to be more common with NTFS, HFS+ and exFAT.

quote: Mike Schulz
How come the server manufacturers don't have an unmount button/option built into their UI's?

The Linux-based DCI servers are supposedly designed to handle "dirty" unmounts gracefully, at least when the drive is not active when unplugged. Furthermore, unplugging while writing is more dangerous than unplugging while reading.

Still, at least most CRU docks have a soft unmount/power button, which I like to use before unplugging a drive just to be safe. No such luck with USB drives.

quote: Mike Schulz
I believe it's always better to use the native OS formats.

Absolutely agreed.

Posted by Marco Giustini (Member # 4544) on 03-18-2017, 04:57 AM:

quote: Mike Schulz
How come the server manufacturers don't have an unmount button/option built into their UI's? Is it really as simple as they think it would cause too much confusion to a majority of managers/operators and they are trying to make it as simple as possible?

The Sony 500 series server has the unmount button. All the others don't. To be honest I thought the software was designed to automatically unmount the drive once the reading/writing operations had finished? I am not sure the button on the CRU tells anything to the OS but I also use it as well.

Posted by Steve Guttag (Member # 268) on 03-18-2017, 09:37 AM:

GDC servers have an unmount...it is called "Closed" They have it for both USB and CRU ingests.

For Dolby, the only time a drive may be removed is when its icon is no longer flashing red in the upper right of the UI. If you do, it will not unmount properly and will no longer mount any new drives (of that type) until the server is rebooted.

Posted by Leo Enticknap (Member # 534) on 10-10-2017, 11:20 AM:

Just encountered an intriguing glitch with a DSS220.

All the drives have been showing SMART errors and reallocated sectors and one of them registered a severe overheat warning in the log, so I'm replacing all the hard drives (existing ones are five years old, have been running 24/7, and the site is a remote location).

In preparation for doing this, I'm outgesting all their content onto an CRU drive (connection is via eSATA), so that I can put it straight back again once the new RAID is in and the software reinstalled, to make things easier for the customer.

I arrived with a 3TB drive in a CRU cartridge, formatted as GPT/NTFS. When I selected everything on the local RAID in the local content tab and pushed the left-hand arrow, it copied one DCP and then said "failed" for all the others. Further experimentation established that copying DCPs individually works, but if you select two or more, it'll copy the first and then fail on the others.

After trying various things, what eventually worked was to repartition the drive with a MBR partition table and reformat it (it could only see 2TB that way, but that's more than I need anyways). That fixed it. I selected the entire RAID contents (about 100 CPLs): it's now copied 7 and has the others pending.

Software version is 4.9.0.96.

Conclusion: Although they might be able to read drives partitioned this way under some circumstances, DSS servers can be flaky with GPT drives.

Posted by Steve Guttag (Member # 268) on 10-11-2017, 03:30 AM:

Why not let the DSS220 format the drive? There is a CLI format command that will have the server format the CRU drive the way it likes it.

Posted by Leo Enticknap (Member # 534) on 10-11-2017, 10:29 AM:

Because I wanted to know what will and won't work for future reference, rather than run an automated script that wouldn't tell me precisely what sort of partition table it's using, what partition(s) it's creating, what size and format they are, etc.

I had a nagging doubt at the back of my mind that GPT might be a cause of trouble (on the way to the airport I thought "Oh bugger, that spare drive I stuck in a CRU is 3TB ... that means GPT"), but was expecting the server either to reject it entirely or for it to work normally. I wasn't expecting what actually happened.

Posted by Carsten Kurz (Member # 5396) on 10-11-2017, 12:05 PM:

It would be quite interesting to see what format Dolby's own command will create on a 3TB drive.

- Carsten

Posted by Steve Guttag (Member # 268) on 10-11-2017, 03:28 PM:

Dolby formats EXT2. The script goes back to 4.5.1.14 and I'd be surprised if they have done much with it since. I recently formatted a 2TB drive with it. Never tied a larger one.

Posted by Carsten Kurz (Member # 5396) on 10-11-2017, 03:44 PM:

Well, the one larger than 2TB is the interesting one...

- Carsten