Unable to ingest to DSS 100 via HD caddy

[Carsten Kurz]

Again, NTFS is not the issue here. Nor is it 3.5" or 2.5" drives.
Quite obviously, the DSS100 CAN read NTFS.

The trouble is, this company will probably not even care if you point them to the ISDCF drive specs demanding ext2/ext3. They will probably say 'We don't know what the ISDCF is, we don't care what they say'.


DCP drives have to be either ext2 or ext3 - ext2 has no journaling (more or less useless for distribution drives anyway), whereas NTFS can become corrupted just the same. 'Proper' systems should mount distribution drives read-only anyway.


Peter - would you mind hooking up that distribution drive again on your PC and take a screenshot of the disk management screen?

[Peter Foyster]

Thanks Carsten,

Sorry, I earlier packed the drive up for postage back to the company. I do recall that it was the same specs as the other NTFS formatted drives. I also noticed on one of the other disc analysis programs that the drive had only done 43 hours.

I will have to see how many other drives I have received from the company in the past 12 months. If, as they say, they have been distributing in the described format, why have I not had the same problem before?

I suppose I should say something to them. Do you agree that the CRU slot in the DSS100 would not be capable of spinning a 2.5" drive?

[Carsten Kurz]

2.5" is not relevant, especially not in a CRU slot. This only applies to USB-connected portable 2.5" drives on older USB2.0 ports (the current is limited on these ports, and the drives often do not spin-up without the help of a Y-supply cable or an additional USB power supply). I am pretty sure this issue was NOT the NTFS formatting, but the GPT partition table. The typical GPT disk has a small protective MBR partition at the beginning of the disc. Older operating systems will only see this dummy partition and can not see the GPT partitions. The drives appear to be empty for them.

Try forwarding this to them: https://isdcf.com/papers/ISDCF-Doc3-Delivery-Recs.pdf

But, I guess, if they don't receive more complaints, they will probably ignore it. Maybe at least they can avoid the GPT partition tables in the future.

- Carsten

[Leo Enticknap]

Sorry to sound like a stuck record, but I have experienced many times, with every model of DSS and DSL, a drive failing to be read because of an EFI partition on the start, even if the partition table is MBR. They typically come from smaller, arthouse distributors, who buy drives intended for the consumer market as USB plugins. They then simply reformat the existing NTFS, exFAT or HFS+ content partition as ext2 or 3, without touching the partition table or the EFI partition in front of the content partition. The problem here could be that, or a GPT partition table, or both. DSS servers can read NTFS, but only if the partition table is MBR, and the content partition is the first partition on the drive. They will ignore all the others.

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.

So they mount these drives in CRU DX115 cartridges, knowing full well that a significant number of 5.25" internal SATA readers cannot provide enough power to spin them up?! That is almost as ignorant as referring to a SMPS as a "transformer." Peter is clearly dealing with an outfit that has decided to ignore established technical standards based on anecdotal evidence, much of it likely provided by end users who did not correctly identify the fault they were dealing with in the first place.

Over the last year to 18 months, we have had problems with Windows-based TMS systems and ISDCF-compliant drives. But this is because the free ext2/3 reader software that most of them used for a very long time (ext2fs) won't work reliably with Windows 10 version 1909 or later. The Paragon plugin, costing around $30, fixes this, and we (MiT) have had zero problems or reliability issues after supplying and installing this software in W10 TMS systems. Typically what has happened is that an end user has upgraded their TMS from 7 to 10, found that it can no longer read Deluxe Technicolor CRU drives, and then called us for help. It wouldn't surprise me if some of these Australian TMS systems are not dismounting ext3 drives correctly, because of this or a related fault.

I suppose I should say something to them. Do you agree that the CRU slot in the DSS100 would not be capable of spinning a 2.5" drive?

It depends on the power supply modules in the DSS100. The internal CRU reader takes its power from a regular SATA power connector, just like any other internal hard drive does. Each drive will need a certain amount of 5v or 12v amperage in order to work properly. It could be that if the 5v or 12v rail in either or both of the PSUs is starting to fade (a possibility, given their likely age), then it's not quite providing enough juice to spin up a drive. However, if it's just this one drive that won't work, and you haven't encountered this problem with any other drive, it's unlikely; and it's especially unlikely, given that you tried the drive in another DSS100, and that wouldn't read it, either. Did the drive activity light on the CRU reader blink momentarily, a couple of seconds after you inserted and latched the drive?

[Carsten Kurz]

Leo, you only sound like a stuck record because you appear to be insisting on something that we have already agreed upon.

The guy giving the answer Peter cited did not mention the partioning method at all, but seems to be stuck himself on USB power or NTFS as such. He probably doesn't even know there is more than just ext2/3 or NTFS when it comes to disk formatting. Maybe the trouble they had with ext2/ext3 drives was not ext2/ext3 as such, but with ext2/ext3 drives AND GPT partitioning. Standard OS procedures do not create EFI partitions when creating an MBR partition scheme. It is possible to do so, yes, but standard tools do not do that. However, when you create a GPT partition or partition table under current or even slightly outdated operating systems, an EFI partition is always created with it.

[Leo Enticknap]

However, when you create a GPT partition or partition table under current or even slightly outdated operating systems, an EFI partition is always created with it.

Only if the BIOS is running in UEFI mode and the OS has booted as such. If the BIOS is in legacy mode and the OS has been installed as such, no EFI partitions will be created automatically - at least not in all the versions of Windows and Ubuntu LTS I've used in recent years, up to and including the current ones (20H2 and 20.04 LTS respectively).

The upshot of that is that as far as I've been able to figure out, it is quite simply impossible to create an ISDCF-compliant DCP drive using a computer that is running under a UEFI-enabled BIOS. This is because, as you say, it will try to create UEFI partitions when you don't want them, and it will not let you delete any existing ones (i.e. it will not let you erase and rewrite the partition table of a drive that had an EFI partition on it when you mounted it). For this and many other reasons I disable UEFI on every computer I build, upgrade, install or refurbish for use in any sort of cinema situation, even if that means having to do a from scratch OS install.

[Carsten Kurz]

Leo - when I create MBR partition tables with GPARTED, Mac OS disc utility, or DiskPart in windows, no EFI partition is ceated. Mac OS and GPARTED make it quite easy to create/overwrite to MBR. In Windows, disk management will stick to a (pre)existing GPT partition table on any disk. One has to use DiskPart through the comandline/console to force an existing GPT table back to MBR (e.g. by fully erasing any partitioning information with 'CLEAN').It is quite cumbersome to create an MBR disk in Windows for the average user, if the disk has been setup as GPT before.

It is no trouble for a blank hard disk. But if you chose GPT unintentionally, only DiskPart and some commandline experience will bring back that dialog: