Unable to ingest to DSS 100 via HD caddy

[Peter Foyster]

Today when I attempted to ingest from a hard drive into a DSS100, the server would not recognize the drive. Thinking that it might be a faulty hard drive (I have never encountered one yet) I tried it in another DSS100 that I keep as auxiliary storage. The drive was still not recognised.

Just to be sure, I tried another HD but it was not recognised by either of the units. Ingesting trailers via USB was not a problem.

I tried rebooting the DSS100 but it made no difference. It seems odd that both the DSS100s refuse to recognise the same DCPs.

I have been ingesting to the main unit for 5 years without a problem. Am I missing something?

[Carsten Kurz]

You mean you only tried ingesting from that single CRU drive? Don't you have any other CRU drives on site currently? Didn't you plan to use a Doremi now?

Oh, I see, you DID try a different drive? Do you have one of those CRU Movedocks on site (USB to CRU slot)? The latter could rule out an actual CRU slot issue. But, even if two drives seem to be affected, I still think there is something wrong with these drives. Maybe defective, maybe a bad format or DCP.




- Carsten

[Peter Foyster]

Thanks Carsten

I will take out the drive and attach it to another docking station with a USB output.

I did plan to use a Doremi but i have been comfortable with the Dolby unit so I just haven't got around to it.

Gotta go, the movie finishes in 2 minutes and I have work to do.
I shall report back tomorrow,

Happy New Yar everyone!

[Carsten Kurz]

8 hours to go here...

[Leo Enticknap]

I've experienced issues with DSS100s whereby if there are a large number of CPLs on a drive, it won't read the drive at all. I have a CRU cartridge containing a 2 TB drive of test content: 129 CPLs in total. A DSS100 won't read it. Every other model of server I've ever used will. The drive is partitioned and formatted in complete compliance with ISDCF requirements: MBR partition table, a single ext3 partition occupying the entire free space, inode size = 128 bytes, all content files either in the top level folder or only one level down.

This is DSS100-specific (running 4.7.8.7): a 200 and a 220 will read it fine, as will both variants of DSL (100 and 200).

I've also had sporadic complaints from customers experiencing the same thing. Upon examination, the cause has turned out to be that the drive had a bunch of trailers, multiple language VFs, or some other cause for 5-10 or more CPLs on the drive. I once tried a Deluxe "trail mix" drive in a 100, and it wouldn't read that, either.

The other possibility is that Peter's drive is not partitioned and formatted per ISDCF specs. If I remember correctly (as of next week, I will have no support customers using DSS100s left: the last is about to upgrade to an IMS3000) and if they are on the final software version, of the unauthorized formats, they will read FAT32 and NTFS, but not exFAT (support was added in version 4.8 for 200s and 220s) or HFS+ (MacOS); and neither will they read drives with a GPT partition table.

If the problem is just too many CPLs on the drive, I suspect that if you ingest it into a Doremi, and then transfer it over the media LAN via FTP to the DSS100, that will work.

[Peter Foyster]

I plugged the drive into one of those adaptors and connected via USB to my home PC. The drive is recognised and displays a single CPL. I did ingest a single movie the other day from a drive that had quite a number of CPLs, without any problem at all.

At the cinema last night I tried a number of drives that I still had and the DSS100 would not recognise any of them. They were ones that had previously been ingested and subsequently removed.

The weird thing is that the second DSS100 that I have is also refusing to recognise hard drives.

I'm pretty sure that I can discount the drives themselves. Tonight I will try ingesting via the USB input.

[Peter Foyster]

I came to the conclusion that if both servers were experiencing the same problem it must, in fact, be drive related. I turned off the server, waited for about a minute and rebooted. I was able to then ingest another DCP. I then tried to ingest the problem drive via USB but it was not recognised. Nor did the server subsequently recognise any other drives. I repeated the process on the other server.

So, by rebooting the servers they would ingest normally, until I inserted the problem drive.

The DCP will actually work via a DCP player on my home computer, so is most likely formatted NTFS. I was thinking of copying the files to another drive and then see if it will ingest. Of course, even if it does, there is no guarantee it will play all the way through.

It is probably best to try to get a replacement drive sent to me in the next few days.

Does anyone have any thoughts, from experience, on what the issue could be? Is it more likely to be the drive itself or the files on the drive? it is the first drive in 5 years that I have come across that would not work.

[Carsten Kurz]

If you were able to see the content of that drive on your windows PC, I guess it is very likely it uses NTFS or even exFAT. Because, for a standard ext2/3 (Linux) formatted DCP drive, you would need to have special ext2/ext3 reader software installed on that computer (ext2FSD, Paragon, Linux Reader, etc). While I do believe the DSS100 supports NTFS, it may as well be that this drive is GPT (not MBR) partioned, which is another problem.

Where did that drive come from? One way to solve this issue is to connect it to a PC, create a share for it, then ingest it through Ethernet/FTP from the Dolby.
But, formally, DCP drives still have to be ext2 or ext3, so, the fault is with the company or person who created or supplied that drive.


I remember a few of your threads concerning that DSS100, but can't remember - what software version is it running currently?

[Leo Enticknap]

The formatting of the drive is definitely not ISDCF-compliant (the standard that all DCP distribution drives are supposed to conform to), if a Windows PC can read it with no extra software installed. I think Carsten's guess - a GPT partition table - is very likely. If the drive doesn't have a crap ton of CPLs on it, then the issue I've noticed, described above, obviously isn't the cause. Another possibility is if the drive has an EFI partition on the start, before the main content partition. Many USB plug-in drives sold by Amazon, PC World, etc. come in this configuration. They should then be nuked with a new MBR (I usually use GPartEd in Ubuntu to do this), and a single ext2 or ext3 partition with 128-byte inodes written, before they can be used as fully compliant DCP drives.

Also agreed with Carsten as to the way to go. It's very easy to share a folder as an FTP site over a LAN in Windows 10 (Peter - I have a how to cheat sheet for this somewhere - let me know if you'd like it), and equally easy to get a DSS100 to read it. It's also easy to do it the other way round, using a utility such as Filezilla to initiate a connection to the DSS100 from the PC, and send the DCP files from the PC. There are one or two gotchas (e.g. the connection type has to be active and IIRC, the data transfer mode has to be forced to binary) - I can look up the complete details if anybody needs them.

[Peter Foyster]

The company that produced the DCP is well known in Australia and I have received many DCPs through them in the past.

Anyway, using my home PC, I formatted a 2.5" USB HD as NTFS and simply copied the files across from the problem drive.

I then ran the DCP on my PC in its entirety, making a note of the credit offset (something that none of the companies seem very good at getting consistently right!)

I took the new drive to the cinema and it ingested perfectly.

Obviously I will need to advise them of the issue and hopefully they can explain why their drive caused such a problem with my server.

[Carsten Kurz]

Probably it's an NTFS/GPT issue. While modern operating systems default to using GPT for new drives, smaller/USB drives still come with an MBR partition table, and that probably was the case for your 2.5" drive. If that had been sold with a GPT partition table, you would probably have the same issue with it. GPT is mandatory for drives exceeding 2TB in size. For drives smaller than that, it is optional.

You can easily check that DCP drive in windows disk management. GPT partitioning can easily be detected there.

[Leo Enticknap]

Either that, or there is an EFI partition on the disc in front of the main content partition. DSS servers won't read a drive if there is, because they only look at the first partition on the drive.

[Peter Foyster]

This is the response that I received from the DCP provider. I’m not sure what to say. It seems that it is my fault for not having the latest and greatest.
Surely their drives need to conform to existing standards rather than setting new ones.

Although, having said that, I have had no problems with drives received from them recently. Still, I didn't look to see what was in the case at that time. It may have been a 3.5" drive. Gee, just as well I haven't installed the Series 1 Doremi!!

"All our drives are formatted as NTFS.

We do this because of the improper ejection techniques some sites use to unmount drives which on an ext formatted drives causes journalling corruption.

Over 50% of sites in Australia run the Cinidigm system which is a PC and it cannot repair the journalling issue which caused by this improper ejection, hence circulating drives becomes problematic.

All systems running in AU now support the NTFS driver so its a no brainer.Gone are the days of the Kodaks and Series 1 Doremi…..

More than likely the issue is caused by your .MOV dock.

We have found there were a whole series of these issued by CRU which don’t supply enough power to spin up the 2.5” drives we use. These run at 7200rpm rather than the 5400rpm which the 3 1/2” inch drives supplied by Deluxe use.

We moved to the 2 1/2” drives about 10 years ago and we experience about a 300% life increase across the drives.

If you like we can send you another transformer for your MOV dock and that will more than likely clear up any mounting issues you are experiencing."

[Frank Cox]

They're providing you with a drive that doesn't meet the specifications for dcp distribution. Since it's doesn't meet the standard, you can't rely on every server being able to use it.

[Randy Stankey]

All systems running in AU now support the NTFS driver so its a no brainer.

You want to know a "no-brainer?"

Doing what published spec. says to do.

I work in a factory where the parts that make up a DCP projector were probably made. You would not believe how strict some specs are!
(I'm sure that some of you know better than I do but, rhetorically speaking, people won't believe what goes into making many things!)

I make connectors for industrial, aerospace, medical and military applications. I sit there all day, making parts to spec and if they aren't they are returned to me and I have to fix them.

If you look at a 100-pin Micro-D connector, all of those pins have to be within a certain height range and there can be no more than 0.01 in. spread between the highest and the lowest. There are a dozen other rules and specs I have to obey at all times.

It's a good bet that I or somebody like me made the parts inside your projector or server and we work HARD to make them right.

It really pisses me off when somebody knowingly violates specification, produces substandard product then blames the end user when it doesn't work!

What would they think when a wiring harness on a Boeing 747 fails, mid flight, and somebody from the factory that built it makes a dumb-ass comment like that?