Having recently bought an XBox 360 to use as a Media Centre Extender with my main MCE living room PC, I was dismayed to find that my network drives were not accessible when using the extender.

A bit of research showed that this is a consequence of how the MCE Extenders connect using the Remote Desktop capability of Windows XP – mapped drive letters are only accessible under the username they are created under, and the extender has its own separate user account (usually MCX1).

Unfortunately, the password for that account is not available. However, there is a simple workaround. The original description came from Chris Lotter’s Blog, but I’ve reproduced the important details here for easy reference.

To make mapped drives visible under Windows Media Centre Extender, you need to follow these steps:

• Map the drive as usual on your main Media Centre account, and configure Media Centre to search for media on that drive
• Create a new folder called C:\Netlogon
• Share that folder publically with the share name “Netlogon”
• Create a file called LOGON.BAT in C:\Netlogon which looks similar to this:

  
  @echo off
  echo Mounting remote network drives...
  net use m: \\192.168.100.20\MP3     /user:world\eddy.carroll mypassword
  net use p: \\192.168.100.20\PHOTOS  /user:world\eddy.carroll mypassword
  net use v: \\192.168.100.20\DVD     /user:world\eddy.carroll mypassword
  

  Replace ‘world’ with your workgroup name, ‘eddy.carroll’ with your server account name, and ‘mypassword’ with your server account password.

• Finally, go to Control Panel -> Administrative Tools -> Computer Management and open the Local Users & Groups -> Users folder. Double-click the MCX1 user, select the Profile tab, and set the Logon Script name to ‘logon.bat’.

You’re now done. Simply disconnect and reconnect your Extender, and it should now be able to see all the media on your mapped drives.

Today from Steve, a very useful tip I wish I’d discovered years ago:

Windows 2000 & XP machines delay as long as 30 seconds when you try to view shared files across a network because Windows is using the extra time to search the remote computer for any Scheduled Tasks.

and delete it.

And just like that, your network shares will once more become instantly accessible. Hard to imagine why this isn’t the default behaviour…

Thanks to Steve for pointing me towards this Microsoft presentation showing Vista’s speech recognition and generation capabilities.

With Vista, there may finally be a good reason to start using speech to interact with your PC. Of course, a good microphone will be essential. Well worth a look anyway.

If you use external firewire disks with your PC, you may have seen at one time or another the dreaded “Delayed Write Failure”. Why does this happen?

Apparently, it’s because various Firewire enclosures have problems supporting more than 128 KB in a single transfer. Depending on the Windows application software, this may or may not cause problems for you.

There is a convenient Filter driver that overcomes this problem, by telling Windows to limit transfers for a particular device to 128 KB; you can find it on the Max 128K Filter Page.

That same page also references another very useful resource, the busTRACE free utilities page. This includes a utility called 1394test which will show you whether your Firewire enclosure suffers from this problem or not, as well as other useful related utilities. The 1394test page also includes extended discussion of the whole Delayed Write issue.

Note: apparently Windows XP Service Pack 2 also includes code to limit the maximum transfer size to 128 KB — so if you are running Service Pack 2, you may not have the problem at all.

(Thanks to Steve for pointing me towards these.)

If you use Photoshop for scanning images, you often need to rotate the scanned image by a degree or two to get it lined up straight (placing it straight on the scanner bed can be almost impossible).

I used to use the trial & error method of guessing a rotation amount, trying it out, then adjusting it up or down until I got something that looked right. Eventually, I figured there must be an easier way.

And of course there is: use Photoshop’s Measure tool, which is a sub-menu option on the Eyedropper tool. Measure a horizontal or vertical line using this (the longer the better), then open the Rotate Canvas / Arbitary dialog and you’ll find Photoshop has automatically filled in exactly the right angle for you.

This handy tip courtesy of Pixel-Techs where you can also find a detailed example, with screenshots.

In an earlier entry, I mentioned the problems I had when upgrading an old ATA66 drive to a shiny new ATA133 drive. The old drive had been in an ATA66 removable disk caddy, and it didn’t behave too well at ATA133.

I resolved that problem by simply uninstalling the drive caddy and connecting the new drive directly to the motherboard via a decent ATA133 cable. (HDTach still shows the performance as a little choppy, but it’s not bad, averaging around 50 MBps transfer rate and peaking at 78 MBps.)

Well, I had a 120 GB drive die a few days ago, also in a caddy. Maxtor sent me a replacement, and once again, it was ATA133. Exactly the same problem as before – really bad performance, making the PC close to unusable.

I didn’t want to give up another caddy, so I buckled down and did a bit of research. It’s been well documented that Windows XP will drop down to PIO mode for hard disk transfers after six DMA timeouts have occurred. However, my problem was different – I suspected transfer errors (which result in a retry) rather than timeouts.

You can check which mode Windows is currently using for a drive by going into System / Hardware / Device Manager, then opening IDE / ATAPI controllers and double-clicking the Primary or Secondary IDE controller. Under Advanced Settings, you’ll see the current transfer mode used for each drive.

I knew from the PIO/DMA discussions that the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Control \ Class \ {4D36E96A-E325-11CE-BFC1-08002BE10318} was responsible for configuring the ATA IDE driver. However, documentation of the various fields was hard to come by. I eventually figured it out by trial and error.

This key has a Default value of “IDE ATA/ATAPI controllers”, which is a handy way to check you’re in the right place. If you’re searching for it manually, it’s usually about the 10th class down in the (gigantic) list of classes from the top, so it’s easy enough to locate.

Inside the key are several numbered sub-keys: 0000, 0001, 0002, etc. 0000 is for the IDE controller, 0001 and 0002 are the primary and secondary interfaces. If you have multiple IDE controllers (e.g. SATA and PATA), then there will be more than three keys here – be careful to modify the correct one! The SATA controller is usually listed before the PATA controller, but you may just need to use trial and error.

Anyway, once you have identified the correct subkey, corresponding to the interface the problematic drive is attached to, you’ll see a few sub-keys:

• MasterDeviceTimingMode – set to the fastest supported transfer mode when the drive initialises.
• MasterDeviceTimingModeAllowed – defines what modes are supported by Windows; usually set to 0xFFFFFFFF, but we can tweak it to stop certain modes being used.
• MasterIdDataCheckSum – I believe Windows uses this to detect when a new drive has been attached to the cable. If you delete this key, it forces Windows to treat the drive as new next time it boots up, and restore full DMA access. This is one way to force a drive that Windows has reduced to PIO mode back to UDMA mode again.

(The same settings also exist with a Slave prefix; which set you modify depends on whether your drive is the master or slave.)

Let’s look at the MasterDeviceTimingModeAllowed value in more detail. This defines a 32-bit mask, allowing up to 32 options to be individually permitted or prohibited. The default value of 0xFFFFFFFF means all supported operations are permitted. By selectively turning off certain bits, we can make Windows avoid using those features. These same bits are reflected in MasterDeviceTimingMode, so that’s a good place to start.

On my UDMA6 drives, MasterDeviceTimingMode was set to 0x20010, which is 0x00020010 in 8-digit hex. I also knew that 0x00002010 was UDMA2. It seemed logical that the in-between positions corresponded to UDMA3 (0x4010), UDMA4 (0x8010) and UDMA5 (0x10010). The 0x10 at the end is probably multi-word transfer, though I haven’t confirmed this.

Right so. To disable, for example, UDMA5 and UDMA6 (ATA100 and ATA133 support respectively), we just need to turn off the appropriate bits in the Allowed mask. Instead of 0xFFFFFFFF, we can use 0xFFFCFFFF. All the other modes up to and including UDMA4 (ATA66) will still be allowed.

My problematic drive was attached to the secondary master IDE interface, so I went ahead and set MasterDeviceTimingModeAllowed for that interface to 0xFFFCFFFF, then rebooted. Sure enough, Device Manager now shows that the drive is running UltraDMA 4 instead of UltraDMA 6. Better, the performance is now usable again, averaging around 20 MB/s transfer rate. I suspect the caddy is still introducing errors (HDTach is a bit choppy still) but it’s hugely better than it was before.

This is crying out for a little applet to let you tweak the individual bits in this mask from a nice GUI. Perhaps I’ll write one if I get some spare time…

Over time, the Windows Registry accumulates dead and unused class keys, installtion keys, and other cruft which can gradually slow down the operation of your PC. If you notice the Start Menu taking longer to appear, and Explorer appears sluggish when opening files, it may be time to give the Registry a clean.

I’ve been looking for a good Registry cleaner for a while, and I finally found one: EasyCleaner.

Not only is it free, it also does a nice job of finding dead shortcuts, temporary files that are no longer used, abnormally large files, and plenty more. Particularly useful is the ability to find all large files and directories on a particular partition, to give you a heads up on where all your disk space has gone.

Recommended.