250GB issues?

[VorTechS]

Actually, 'diskpart' reports the partition as FAT32.  I guess that MBRWiz tool doesn't have a clue....

After a bit of digging, the MBRWiz is reporting the extended partition instead of the FAT partition.

Code: [Select]


DISKPART> select partition 2

Partition 2 is now the selected partition.

DISKPART> detail partition

Partition 2
Type  : 05
Hidden: No
Active: No

There is no volume associated with this partition.

DISKPART> select partition 3

Partition 3 is now the selected partition.

DISKPART> detail partition

Partition 3
Type  : 0B
Hidden: No
Active: No

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 3     F   PHTDTA       FAT32  Partition     56 GB  Healthy

DISKPART>



[markbowen]

Interesting point Les makes about different behavior of the USB cradles.  I've got a USB 1.1 cradle that is a bit more cooperative under 3.92 -- no "error retrieving DMS ID" on a drive that did give the error in my USB2 cradle.  I would also flag a possible issue the matter of the device IDs.  An original Phatnoise DMS will always have a device ID that identifies it as being a Phatnoise DMS, while a hacked DMS will always show up with the ID determined by the drive manufacturer.  I wonder if the tools could transpose the device ID of an original DMS to the new DMS, if it would make any difference.  But maybe I am wandering off-topic...

[VorTechS]

Is it possible to do that?  I thought it was done at the manufacture point and couldn't be done outside of a specialized hardware environment...?

[sbingner]

No, it's not possible to do that... unless you have some very proprietary tools from the manufacturer of that specific drive...  otherwise we could make new DMS drives without having to have the box flashed.

[markbowen]

Well, after giving a couple of VorTechs' updated tools a go and still feeling no love, then rolling back to earlier versions of the tools without luck, and ultimately repartitioning/reformatting the drive with the PhatHack CD, and trying to use it with PMM 3.51, 3.42, and 3.22, I can only report at this point that using a 250GB DMS with Media Manager is hit and miss at best.

Prior to reformatting with the Windows Tools, I thought I was at peace with 3.51, but now I think it was just luck.  In all versions, most often the partitions will unmount before any write operations can be attempted.  Even if it manages to fully load, the partitions unmount when any kind of write operation is attempted.  Sometimes, it will seem to work, but then I try to transfer some tracks, nothing happens -- they cue up in the software, but they don't get transferred.  I'll keep tinkering, and wait to see if a new iteration of the Windows Tools might take care of some of these issues.

[VorTechS]

Still no word from the Windows Kernel mailing list but someone is taking a look at it.  I think, they may be about to produce their solution to creating the partitions.  I've also bought a 250GB drive to test with, it should arrive in the next few days.

[markbowen]

Great, I'll be glad to read your experiences getting a 250 up and running.

FYI, I'm usually on XP, but if you try under Vista, at first it will seem the 250GB DMS won't work at all.  Vista spends a long time searching for drivers, then reports the hardware as ready to use, but the partitions don't mount and the disk doesn't show up in the device manager.  If you "scan for hardware changes" in device manager, the partitions show up.  I haven't tested yet with any version of Media Manager.

Update:  In Vista, I found I had to do a scan for hardware after every boot in order to mount the partitions, and even then it wasn't always successful.  Even when it is, using Media Manager produces the same problems as in XP (partition unmounts -- or is that "dismounts" -- either on loading or soon after).  A 160GB DMS works under Vista without problem.

[VorTechS]

ATM all I can do is test the partitioning and file copying issues as I don't have a PhatBox available to test with.
(I don't have a car with my stereo equipment in since the MOT failure of my old one)

The drive arrived not long ago, and I'm currently running the tools to create a new DMS with it now.....

[sbingner]

You could always connect your stereo and your phatbox to the line-in on your computer like i did....

[VorTechS]

Powering it at the office might be deemed a 'safety risk' and as I don't have a proper AC/DC converter a bit unlikely to happen.  I've managed to reproduce the problem, and am investigating it now - I don't believe this is a partition problem any more.

[sbingner]

You don't have an ATX power supply??!?

[VorTechS]

Okay the results are in!  On the 3rd time of asking I found out there is a bug in the tools, but I don't think there is anything partition related.  I did find that there was a problem if a disk doesn't have the PHTSYS and PHTDTA partitions on it already (IE a brand new drive).

Once the disk is partitioned, a WMI refresh is called to get the new partition info.  Even though the partitions have just been created, WMI returns two partition entries, but with no volume information.  (Makes sense, we haven't formatted them yet).

The tools were then checking the partitions after formatting (using the out-of-date snapshot) to check which drive is PHTSYS to then copy the firmware files on to it.  Problem is, the out-of-date snapshot is returning a blank drive letter.  How a file copy progress actually allows you specify a blank path is beyond me, but it does and so the log files didn't really show anything up when I'd looked at them before.

I've simply added a second WMI refresh immediately after the partition formatting and then the filesystem appeared as I would expect afterwards.

I then launched PhatHack Media Manager v0.8f (not available to anyone yet) and copied 4 playlists comprising of 70 tracks onto the DMS.  (Note: Copied, not transcoded, I have the option 'Do NOT transcode to this device set).

At no point did I receive any delayed write failures, so any potential issues as a result of a stupid number of hidden sectors may have been addressed by recent code changed to PhatPartition.dll the other day.

Mark/Les, I'll send you the updated tools shortly and we'll see how you get on with testing via PhatNoise Media Manager (as I need to reboot this machine to complete the installation and have a lot of work on right now that I need to avoid doing that).

If PhatNoise Media Manager fails, it'd be good to see if you have the same problems using PhatHack Media Manager - there's an outside chance PhatNoise MM is using low level IOCTL calls (pure speculation).

It'll also be good to clarify the new disk is working in the PhatBox too.

[sbingner]

I might suggest a logical test in there before you start copying to a drive letter to ensure that a drive letter has been assigned?  Sometimes windows just decides NOT to give out a drive letter in my experience

The fact that PMM made those errors occur when it is open (not necessarily even actually doing anything) on my 120GB drive would suggest something like low-level IOCTL calls but why they would do something like that is beyond me...

[sbingner]

Actually, are you sure it didn't say a drive letter has been assigned?   When a partition is created, windows assigns a drive letter.  You can then usually format it with "format d:" etc...  don't you have to pass a drive letter to mkdosfs?  After this mkdosfs will be creating the label, so the original query would be perfectly valid as far as drive letters are concerned... and you could always just assume that the drives you formatted to BE PHTSYS/PHTDTA really are and save yourself an extra refresh?

[VorTechS]

Yes it does, you are right it does assign the drive letter.  However you can't use the IO.Drive namespaces to access the drives because they are not fully formed drives.  Therefore the only other way to get access to the volume data is to use WMI to query the device lists for the partition and volume information.

Essentially I am not making any assumptions that PHTSYS is the smallest drive on the disk, and am using the volume information to check the drive letter of PHTSYS only.  I figured it was prudent given the swapping of the drive letters.

The refresh is hardly a time consuming query...so I think we'll stick with the safer than sorry method...it's pretty much foolproof with the exception of using an out-of-date WMI snapshot.