PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: markbowen on February 12, 2008, 08:39:44 am
-
I decided to go all the way and bought a 250GB WD 25000BEVE to use in my Kenwood Keg, but I'm having all kinds of problems. I'm pretty sure I've got a dud, but I'm wondering if anyone else using a 250 (I've seen at least a few other people on this board using them) has had any issues getting it up and running. VorTechs Windows tools couldn't create a DMS with it, so I had to use the Phathack CD. Then PMM comes up with a number of errors and ultimately fails to load, I get write delay failures and the phtdta partition disappears. When I run a repair in the Phathack CD it always says the partition table is corrupt and does the repair, but it never works. That's in XP, Vista takes forever to load a driver and then won't even populate the volumes.
Thorough disk scans complete without hanging, but I am nonetheless fairly sure I have a dud. But is it possible there is some issue with the cradle (USB2) and 250GB drives?
-
Does it work properly if Phatnoise Media Manager is closed? I had one where I had to use it with Phatnoise Music Manager instead... see http://forum.phathack.com/index.php/topic,620.0.html
-
I'm wondering if anyone else using a 250 (I've seen at least a few other people on this board using them) has had any issues getting it up and running. VorTechs Windows tools couldn't create a DMS with it, so I had to use the Phathack CD. Then PMM comes up with a number of errors and ultimately fails to load, I get write delay failures and the phtdta partition disappears. When I run a repair in the Phathack CD it always says the partition table is corrupt and does the repair, but it never works. That's in XP, Vista takes forever to load a driver and then won't even populate the volumes.
I've built 3 DMS's with that drive and haven't had any problem (XP Pro, USB2 cradle, PMM 2.30). I had some initial issues where the Windows hack tool wouldn't create the partitions, but that was fixed a couple versions ago.
A delayed write failure almost always indicates a hardware problem.
-
PMM 2.30 doesn't have the issue I was mentioning. Have you tried it with the new Phatnoise Media Manager?
-
Sam, I remember you had issues with the 160GB drives at least initially, but at least some 160s (Samsung, for instance) will work with Media Manager up to 3.76 (not 3.92). So, theoretically a 250 should not have problems either, but it won't even work with 3.76. I'm inclined to believe it's a bad HDD because VorTechs' Windows tool just would not work with the drive, the PhatHack CD kept reporting a corrupt partition table, and the Phathack bad block check kept restarting. A surface test in Windows ran okay, but another test using the surface scan in Paragon Partition Manager just hung up. And Windows Vista just would not recognize the partitions at all (and yes, I know, Vista sucks). The write delay failures also point to a bad disk.
I'll be exchanging the drive and hopefully will not run into the same issues. However, it would still be useful to know if anyone has a 250GB DMS working with any version of Media Manager.
-
I say this because you describe what my problems were exactly... but it could go either way. Best bet is to load up the 250GB with nothing running on the computer (PMM etc) and try a bad sector check or just try copying files to it. You didn't have PMM running when you tried these tests, did you?
-
Oh and if you have a laptop... you could try it in there directly...
-
Yeah, in somewhat limited testing using a USB caddy it seemed to work fine on its own, but as I wrote it couldn't complete a bad block test under Linux with the Phathack CD, neither could it complete a sector scan in Partition Manager. It passed a Windows surface scan, but the MS disk tools are not 100% reliable -- they'll catch a badly hosed drive, but not always a subtly hosed one.
I'm still exchanging this 250 and hoping for better luck next time. If it won't work with Media Manager, then I'm just screwed I guess. (Unfortunately, I'm not in a position to return the drive, only exchange.)
-
Have you tried MUSIC manager?
-
No, I haven't tried it with Music Manager. If the second drive won't work with Media Manager, I guess I may have to go to Music Manager, which sucks in comparison.
-
Update for anyone else who might be interested in using a 250GB DMS:
I exchanged the WD 250GB drive I had and assumed was bad for a new one. This one at least works in the Windows Phathack DMS Tools, where the other one did not. However, it would seem that there certainly are issues with Media Manager and the 250GB drives. 3.92 gives the "error retrieving DMS ID" that also happens with some other drives, and just won't work. That's a shame, because as a program 3.92 is the most stable (no crashes when updating the database, as I get in every earlier version), and it has the added benefit of being able to edit the voice prompts.
3.76 seems to work at first, but then I get write delay errors and the phtsys partition disappears.
I've gone down to 3.51, which seems like it might do. I did manage to create a playlist, transfer files and do a full save/eject without incident. However, it is sluggish at first loading the DMS (even with nothing on it), and I do get infrequent write delay errors and disappearing partitions. I'll see how it works and if it becomes too unstable, I'll go down to 3.42 and 3.22 to see if either of those works any better.
Music Manager does seem to work with 250GB DMS, but if it comes down to using a 250GB and Music Manager or a 160GB and Media Manager, I'll use the smaller drive -- if only because I much prefer to be able to have bands properly named with "the" or "a" and still be able to sort alphabetically (e.g. "The Who" instead of just "Who").
-
You may be able to load the music all on with Music Manager, then go through and sort etc with media manager... most of the issues seemed to be when actually copying data to the drive
-
Erm, *cough*
Les and I have been doing a bit of research - there's an outside probability that the partitions aren't being created correctly by the tools. I'm currently investigating this one as thoroughly as I can and have managed to get myself on a Windows Kernel Driver mailing list where at least one person is examining the code.
One thing I noticed, is that if I modify the parameters being passed to mkdosfs then the disk doesn't look right (PHTSYS and PHTDTA show the same partition size, spanning the entire size of the disk).
I think this is pointing to a partition problem... but won't know for a little while yet.
If it does turn out to be a problem with the code - I apologise sincerely to all those that were advised to get new disks!
I'll keep you updated of progress.
-
Okay, sbingner and I have done a little digging. There doesn't appear to be an issue with the partition offsets - but there may be an issue with hidden sectors. I've removed the hidden sectors with the exception of the one required for PHTSYS and interestingly the problem with the PHTDTA partition taking forever to mount looks like it has gone away.
Mark, is the block size on your drive 512? It looks to me like the partition side of things is taking care of the block size, cylinders etc... but the formatting is hardcoded to use a block size of 512.
I can send you a copy of the new tools with the changes I just made if you'd like to give them a go?
-
Actually...I forgot to mention that the Windows Tools were not 100% successful at setting up this drive. It put the phtsys and phtdta in the wrong order. I didn't think changing the drive letters was a good idea, so I ended up reformatting and partitioning using the ol' Phathack CD. I used the Windows Tools to load the firmware etc. I'm away from my home computer at the moment, so I don't know what the block size is, but I assume it is 512 since that should be the default.
Since I haven't gone too far in loading up the drive yet, go ahead and send me the new tools and I'll give it a whirl. You can either send directly to my e-mail, or PM me a link, and I'll report back later today.
-
I suspect the order was some fluke of the OS... the physical order is hard-coded into the way it sets up the drive and it shuld be impossible for that to swap. Did you notice the size of PHTSYS and PHTDTA?
-
As an aside, but since it could be of interest - I also found that USB caddies can have - ummm - interesting effects. I have one which causes Media Manager 3.92 to complain that it cannot identify the drive signature (so we now know for sure that at least 3.92 checks for that in some way, which could explain a few things). USB - ATA bridge chip type = GL811E. That was with a smaller 80G drive.
As VorTechS mentioned - we are also digging into the partitioning generated by his current tools. Watch this space...
Les.
-
sbingner: S80_UK just pointed me to the fact that the MBRWiz program is showing the PHTDTA partition as FAT16x, and not FAT32
I wonder if it's that older version of mkdosfs that doesn't recognise larger disks (after all it was written in 2001 IIRC)
I check the code and the partition types are definately being explicitly set to PARTITION_FAT32.
S80_UK/MarkBowen: Try using the newer mkdosfs I sent you to re-format the PHTDTA partition and see if that modifies the result of the MBRWiz.
-
Did you forget to get -F 32 on the mkdosfs command line?
Anyway, the setting in the partition table isn't really used... it's just for reference, when it's mounted it detects if it's fat16 or fat32
mkdosfs doesn't recognize disks - it formats them... and it supports the fat32 format which supports up to 2TB -- the problem with it not detecting the size of the partition is just because it's a port from linux to windows
-
Dim PhtSysArguments As String = "-v -n PHTSYS -F 32 " & DMSPartitions(PhtSysPartition).DriveLetter & " " & (DMSPartitions(PhtSysPartition).PartitionSize / 512)
Dim PhtDtaArguments As String = "-v -n PHTDTA -F 32 " & DMSPartitions(PhtDtaPartition).DriveLetter & " " & (DMSPartitions(PhtDtaPartition).PartitionSize / 512)
Nope, I didn't forget the -F 32 option...
-
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.
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>
-
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...
-
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...?
-
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.
-
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.
-
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.
-
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.
-
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.....
-
You could always connect your stereo and your phatbox to the line-in on your computer like i did....
-
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.
-
You don't have an ATX power supply??!? ;)
-
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.
-
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...
-
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?
-
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. ;)