Salient Soft

I hit  number of issues getting the scanner to work, even after an extended period where it had worked ok.

There were 3 main issues:-

• During (re)installation of the software, a test scan is done and this typically failed. This was frustrating because when running the SVT diagnostics utility which came with the software, it would readily perform a scan and save a valid JPeg, indicating that there was nothing wrong with the base drivers. The solution to this was to do an advanced install, and just untick the scan test to allow the install to complete.
• I often had issues where the Kodak ScanMate software (which allows scanning to PDF directly using the front panel of the scanner) refused to connect to the scanner. The main issue here was that the correct USB cable (with an inbuilt suppressor component) must be used – any other USB cable seems to be prone to error. In addition, I found that it helped to exit the ScanMate software from the tray, and restart it. This then gives a choice of either starting the scanner first or the software – it was not clear which was best, but at least this allowed a complete reset (especially after changing settings). I also disabled running ScanMate on windows startup. It is straightforward to run from the start menu when needed, which is not very often. I have also tried installing a later version of the drivers etc. (v2.2.6 rather than the v2.1 on the original delivered CD) but this does not appear to have done anything to improve the reliability (at least on Windows 7)
• Having sorted the above and got to the point of performing a scan, I would often get an error whilst the PDF was being created “Failed to format images” after which the scan attempt just died. This link here details how to delete a sys folder to resolve the problem and this certainly helped – the folder however was in fact in C:\Users\SteveW\AppData\Local\Smart Touch\i11xx  in my case under windows 7. I had to exit ScanMate and disconnect the scanner to be able to delete the folder, and it was recreated automatically when I reconnected and restarted ScanMate. An additional issue was that using a high resolution in the settings definitely triggered the issue – to the point that my gut feel is that this may be a prime cause of the problem. It certainly failed  at 1200dpi, and the improvement in quality was hardly noticeable compared to 300dpi. Also a double sided A4 colour scan to PDF increased in size from around 5Mb to 25Mb so it was definitely not worth using. It also took a lot longer doing the conversion/saving at resolutions above 300dpi (and typically e.g. for 1200dpi, took a long time and then failed). In the end I stuck with 300dpi, and just wound the Jpeg quality up to best to help improve things. After this I was able to get reliable operation.

A backup plan if all else fails is to used the SVT diagnostics utility to scan to a JPeg (tweaking the settings allows colour or monochrome selection etc. but paper size appeared to be just automatic). I then used an upgraded version of PDFSam which allowed creation of a PDF directly from the JPeg. To to this I had to register PDFSam but it appears to allow PDF creation as a free option if you register. This worked fine as an emergency backup. The downer with this approach is that each page side gets saved to a separate file, so they all need pulling into the PDF separately with PDFSam – not an issue but a bit time consuming.

No Comments »

This was done in order to resolve ongoing reliability issues with the OCZ Vertex and SATA port errors from the P6T as detailed here.

This post also follows on from my earlier post here concerning hot swap issues, where I went into some detail of the P6T flashing process. Reference should be made to that post for more details of P6T flashing.

The following steps were performed:-

1. I identified the current firmware version of my OCZ Vertex. To do this start device manager, find the disk under Disk drives, and open its properties. Then select the Harware Ids property and the version number of the firmware will be shown. There were hints in the forums of a more detailed revision number, but I could not find it. My initial version was 1.5.
2. I also tried to run the OCZ Toolbox which allows identification and upgrade of the firmware, and also auto downloads the correct new version. I nice idea if it had worked! In my case it failed to find the OCZ Vertex either before or after the upgrade process.
3. I did note that a number of posts suggested switching the SATA mode to AHCI in both the bios and windows. This OCZ post details the process, which (for the windows part) simply involves changing the value of HKLM\System\CurrentControlSet\Services\msahci\Start in the registry from 3 (=IDE mode) to 0 (= AHCI mode). However, when I tried this at this stage, the system froze at boot time. Fortunately, I was able to switch the setting back in the BIOS, boot into safe mode, and set the registry setting back to 3, to restore the system to a working state.
4. The latest version for my Vertex was 1.7, but it is not possible to upgrade directly from 1.5 to 1.7. It is necessary to upgrade to 1.6 first. Finding all the historical versions of the firmware is not easy on the OCZ site – the main download area only has the most recent version. Older version may be found from a forum post here which has all the historical downloads.
5. For my Vertex, here is  the 1.6 upgrade and here is the 1.7 upgrade.
6. Note that as per the 1.6 upgrade, I had the ‘filename error’ which meant that I had an older version which needed a destructive upgrade to 1.6 due to a change in the NAND/wear levelling algorithm. This would mean loss of all data on the drive and a restore afterwards, and the use of a different kit for upgrading. The upgrade also could not be done with the drive in use as the system disk. The links in the previous paragraph give all the instructions and the alternative versions of the upgrade.
7. I then made 2 full backups with Acronis, plus another daily file backup, to be sure I would be able to restore the drive.
8. As per the instructions, I jumpered the drive to set it into standalone/upgrade mode, and booted from the previous version of Windows 7 which I still had available on a standard Hard drive. I kept this available just in case, and on this occasion I was very glad I did.
9. The destructive upgrade is available as 16_win_vertex.zip. Unfortunately the zip contains 2 versions of the update, 641102VTX.exe and 661102VTXR.exe. There are no release notes to say which version to use or what they are (!) I wondered if they related to the internal firmware/drive version from which you were upgrading, but I didn’t know that either as I have said earlier. Another forum post hinted that as may be expected, the 661102VTXR.exe was a later version and the ’R’ indicated revised. I decided to try this one.
10. Having jumpered and rebooted, the drive correctly identified itself as YATAPDONG BAREFOOT, and I proceeded with the upgrade, which went successfully.
11. I then immediately upgraded from 1.6 to 1.7 using 17_updaters_1.zip.  This time, a standard non-destructive upgrade could be done (not that it mattered in my case), which mean burning an ISO on a CD, and booting that to do the upgrade. The zip contained ISOs for a number of OCZ products plus some release notes this time, so I burnt the ISO for the Vertex. I booted it and did the upgrade, which went with no problems. One point is that I cannot recall whether I removed the jumper on the drive before or after this final upgrade. I am fairly sure that it was after, in which case the upgrade does not mind whether the jumper is present, but if there are any issues it should be tried without the jumper present as would be normal for a non destructive upgrade.
12. Following this, I booted the system. Initially it could not see the Vertex, so I rebooted into the bios, found it was then visible, and did a bios save and another reboot. This time the drive was visible but not formatted.
13. I then booted Acronis from its rescue CD and restored the backup, plus the Master Boot Record. This proceeded normally.
14. After rebooting, the system came up and ran fine, however it did present the boot manager from the other disk, and the system had to be selected from there. To prevent the need for this, I copied the boot files back to the new SSD using bcdboot as per this post here. It was also necessary to reset the boot order in the bios so that the SSD was chosen first, otherwise the boot manager is still presented even after you have run bcdboot.

Now I had a working system with the updated SSD, I decided to reflash the P6T as well. Previously I had had hot swap and SATA issues with later bios versions, as detail here. However, since then I had disabled the onboard JMicron controller which was giving problems, and replaced it with a Startech controller, as detailed in the update to this post here. Therefore, the original issues which were preventing the use of a later bios were no longer present, so I opted to flash to the latest version which at the time of upgrade was version 1408 :-

1. I used the in-bios EZ-Flash, and the process and precautions are detailed in the original section of this post here.
2. I re-applied the required motherboard settings as per the process, and rebooted successfully.
3. I then retried switching into AHCI mode, as detail above when I tried it prior to the upgrade. This time it worked correctly with no problems. In the bios, I just set the onboard SATA to AHCI. The JMicron controller was disabled, and the Startech controller was not touched as this was an add-in card just used for SATA backups. It is possible that now either the onboard ICH10 SATA or JMicron SATA might work and hot swap reliably in eSATA mode with AHCI enabled, but as I was happy enough with the Startech I decided to leave this issue well alone for now.
4. As a final test, I re-ran the Windows Experience tests to see if AHCI had improved performance, and indeed the primary hard disk figure had increased from 7.1 to 7.3, which is good considering the fact that my original OCZ Vertex is now an old  technology which has been set to End-Of-Life by OCZ. The system certainly felt snappier, but this is highly subjective as I had not run before and after benchmarks – the goal of the whole excercise was reliability rather than speed.

No Comments »

My old TyTn II has had sync issues over the last few weeks, sometimes needing several attempts to sync.

A few days ago it failed completely with sync errors part way through.

I have tried a number of things to resolve the issue, with only partial success.

1/ WMDC 6.1 did not sync at all. I tried turning ‘advanced network functionality’ both on and off on the TyTn II (under settings/connections/USB to PC), and neither worked. The advanced setting is apparently what allows the device to share the PCs internet connection, and is not available with this turned off, although I have not investigated this.

2/ I tried removing WMDC 6.1 and installing WMDC6.0 for Windows 7/Vista 64 bit, but it always installed 6.1 as part of the install, and so was very tricky to roll back.

3/ This procedure worked in the end and allowed 6.0 to install (as per this forum post here):-

Note that as part of this procedure, when deleting the WindowsMobile folder, renaming it first then allows all the contents to be deleted (possibly rebooting after the rename but this was not always required). Note also that I turned windows update automatic mode off so that it would always ask about any update first, in case it was responsible for the ‘invisible’ update to 6.1

Here are the steps that I performed during this cycle of events that has got
my Dopod phone with WM6 sync’ing again with WMDC 6.0:
— Uninstalled the two Windows Mobile Device Center 6.1 items from the
Control Panel > Programs and Features list
— Manually deleted the contents of the C:\Windows\WindowsMobile folder.
Initially I could not delete some DLLs but once the two “Windows Mobile
device connectivity” services were stopped from the Task Manager, I was able
to delete the rest of the files in the WindowsMobile folder, except for the
en-US folder containing the *.MUI files. I could not delete them and so
decided to leave them.
— Using Regedit, I deleted all entries from the following two keys that
related to my two devices:
* HKCU\Software\Microsoft\Windows CE Services\Partners
* HKLM\Software\Microsoft\Windows Portable Devices\Devices (I left
in the entry for my memory card)
— Using Windows Explorer, I deleted all files in the following folder:
* C:\Users\<username>\AppData\Roaming\Microsoft\Acti veSync\Profiles
— With my two Pocket PCs disconnected, I tapped on Start > Programs >
ActiveSync > Menu > Options, highlighted the Windows PC and tapped on and
the Delete button. Both of my PPCs had two entries in here so there could
have been some confusion on the desktop at some point, so I deleted both of
them. They do not sync with any other computer.
— Rebooted (Restarted) my Windows Vista computer
— Reinstalled WMDC 6.0 from the Microsoft Download website.
— Recreated the two relationships from my two devices, and they each did
the initial long sync
— I then tested each device that it could perform a sync not long after it
was reconnected, and they both now sync perfectly. I also tested that making
any changes to some contact details in Outlook 2007 would update the devices
after a sync. and it did.

4/ When using WMDC 6.0, I had to disable the Advanced Networking Functionality on the device, as WMDC was unable to install the correct driver for it when I tried.

4/ This now allowed the TyTn II to sync contacts, calendar and tasks. However, annoyingly, it does not sync the textual content of calendar appointments or tasks – only the headers are synced. This is the ‘partial’ solution that I am having to live with. The good point is that at least contacts are synced properly, and at least with the appointments I will get reminders on the phone plus the title details, which is enough for most of them.

5/ I retried the different versions a number of times but this behaviour was consistent. In the end I had to use system restore to remove 6.1 as the driver update would not remove. It may have done so in safe mode but I did not try this. The behaviour was consistent with both USB and bluetooth syncing.

6/ I also tried syncing with a laptop running Windows XP, but interestingly this also failed to sync, which perhaps points the finger at the TyTn II as this used to work.

7/ I tried running SCANPST.EXE (in the C:\Program Files (x86)\Microsoft Office\Office12 folder) to check for PST corruption as a possible issue. Interestingly it did find a number of issues. It fixed most, if not all of them ( I reran the check again after it had done the fix and some errors remained). However, these errors have not caused any issues when using Outlook and did not allow the TyTn II to sync with WMDC 6.1

It is not clear what the actual issue is, but it is interesting that WMDC 6.0 at least completes a full sync consistently (albeit without calendar/task text). There are any number of posts on the internet complaining about this issue, and I must say I agree with them. It is hugely ironic that an iPhone can sync with Outlook but in many cases a Windows Mobile cannot.

No Comments »

Update 4/4/2010

Whilst hot detection has been working, I was unable to run a backup as Acronis gave errors. A disk check with windows failed to complete intermittently on one of my drives. When I disk checked the same drive afterwards via USB, it checked out with no problem.

I’ve finally taken the decision to dump the internal eSATA on the P6T. Whilst my PC is an Arbico one under return to base warranty, I will not be returning it. I may have a hardware fault, but so many other people are reporting problems with the P6T and eSATA that it is impossible to be sure. I do not wish to be without my PC for a week or 2 only to have it returned with the problem still present.

I have disabled the JMicron controller in the Bios, and installed a StarTech 2 Port PCI Express eSATA card (Silicon Image 3132 chip).  I bough mine from CCL Computers for £20-78 including VAT and postage, so not much more than it would have cost me to courier my PC back to have it looked at under warranty, and it took me 10 minutes to install. So far this is performing flawlessly. When installing on Windows 7, Windows Update found the driver and auto installed it – the bios on the card was 7.4.05, and Windows installed version 1.0.15.3 of the driver. This version did not appear to be available when I searched the Silicon Image Site – the CD with the card, and Startech’s site, both had version 1.0.15.0 of the driver, so I stuck with what Windows did and had no issues with it.

Having already used a card with a Silicon Image Chip, I immediately installed HotSwap! as this allows safe removal of the drive. As installed, the driver does not enable safe removal in windows, but does enable write caching on the drive, so HotSwap! is recommended. After installing HotSwap!, remember to ctrl/click the systray icon – this will allow you to specify those devices which are to be excluded from hotswapping, such as your fixed hard drives. HotSwap! is designed for Silicon Image chipsets and is able to optionally spin down an eSATA drive on removal. It can also scan for hardware changes if you have hot detection problems (I did not). The only slight issue with it is that it will not autostart in the tray under Windows 7 as it gets a UAC prompt to continue when it starts. You can get around this by making it start as a scheduled task with high privilege, but I just leave it on the quick launch bar or superbar and start it manually when I need it, and put up with the extra click.

Update 10/3/2010

After reverting the Bios back to 1004 as at the end of this post, a couple of reboots later the pc failed to detect a hot insertion again. I reverted the JMicron driver back to 1.17.53.0, the version used by the poster referred to below, as this was cited as stable, but still no joy. I tweaked the Bios to disable the floppy drive (on by default) as I don’t have one, resaved and booted, and then it all worked again. After 5-10 more warm and cold boots, it is still hot detecting fine. I don’t think the floppy controller was the issue, but the fact that I went in and changed and resaved the Bios settings, as this has kicked it into life in the past.

My final conclusion – it does run stable now, but I wouldn’t call it rock solid – it still won’t detect an eSATA drive present at boot time, and I’ll need to keep an eye on things to see if the detection problem resurfaces. If it does, I suspect just entering Bios setup and resaving the Bios settings after a small change (or even no change) will sort it!

Original Post 9/3/2010

My P6T was delivered with bios revision 0904, and as delivered would not hot-recognise or safely remove an eSATA drive (safe removal was off, and write caching was off which obviously impacted performance).  I installed the latest JMicron jmb36x Controller driver (1.17.55.0, 27/01/2010) , and this enabled write caching and safe removal via the system tray. Note that whilst the P6T has both jmb363 and jmb322 controllers listed in the spec, the controller under windows lists as a jmb363, and this driver appears to handle both the above chips, therefore the jmb36x driver is the correct one. Upgrading the driver in my case affected eSATA hotswapping/safe removal etc. using both the rear eSATA port on the P6T (jmb363), and my front port connected to SATA_E1 (jmb322).  However, hot recognition was very intermittent (even with a device rescan) and the only way to consistently recognise the drive was to have it plugged in at boot time, enter the bios, exit the bios and boot. It would then recognise the drive at boot time once only, and could be safely removed (but would need booting to recognise it again).

This post states that bios version 1004, plus the JMicron driver I was using, sorted the problem. As there was now also a later bios version, 1201, I reflashed the P6T to this version. I used the flash utility in the Bios itself as this was convenient, and it would recognise USB flash drives to read the new bios. There is also a recovery process if it crashes during flashing, which involves booting with the target Bios in the root of  a usb flash drive in which case it auto flashes (see manual).  However, this recovery process only  works with small FAT32/FAT16 flash drives of less than 8GB, so I prepared a 2GB flash drive especially in case this was needed. Note also that the Bios flash utility does not do long filenames and so converts them to DOS 8.3 format – if you have multiple Bios file versions on the drive this may mean you won’t be able to tell which is which, so rename the files to sensible short names before you start, and save yourself another reboot! Also be sure to unzip them.

It turned out that version 1201 did not work at all with eSATA, so it appears that Asus fixed this in version 1004 and then broke it again in 1201 – doh! I even tried a CMOS reset with 1201 just to be sure, but it still did not work. With the drive present at boot time, it just froze during the JMicron controller drive recognition phase, just prior to starting windows.

I reflashed back to 1004 and hotswapping all worked fined, both recognition and safe removal, including multiple times. However, the drive would not be recognised at boot time if present, and would still freeze as before. As my real goal was true hotswapping, I was happy to live with this issue as hotwapping was fine – I just plugged the drive in later after booting.

Prior to clearing the CMOS, I took shots of all the Bios screens with the old settings in, to be sure I did not miss any custom settings, as the PC had been built by a custom builder, Arbico. Whilst there is a Bios feature to allow saving and restoring of CMOS settings to a flash drive, there was the concern that reloading old settings could introduce old data which did not match the new Bios, so I wanted to be sure to load default settings and tweak from there.

The screen shots of my old settings may be downloaded in this zip file. Afterwards, I manually made the following changes after clearing the CMOS and loading new defaults :-

Menu: AI Tweaker, Setting: Ai Overclock Tuner, Value: X.M.P.

Menu: Power options, Setting: boot via keyboard, Value: set to Ctrl/esc

Menu: Power options, Setting: Power On via PCIE devices, Value: enabled
(This setting was needed to allow Wake On Lan to work correctly)

Menu: Boot/Boot Device Priority :-
1 SATA: PM-SAMSUNG HD
2 CDROM:SM-Optiarc D]
3 DISABLED

Menu: Boot/Boot Configuration settings, Setting: Full Screen Logo, Value: disabled

Menu: Advanced/On Board Devices Configuration, Setting: High Definition Audio: Value: disabled
(Onboard audio was disabled as I was using a separate sound card)

Menu: Advanced/USB Configuration, Setting: Legacy USB Support, Value: Enabled

Menu: Tools, Setting: Asus Express Gate, Value: Disabled

No Comments »

According to Microsoft here you can do this if you install them in increasing order, i.e. you must install the earliest first.

In my case, Office 2000 would not play ball at all, as Word 2000 froze on startup.

Office XP ran ok, and does seem to coexist with Office 2007, but there are some issues.
I had to mess around with compatibility mode for XP, but ended up taking it off as it appeared to try to run Word XP in administrator mode even though this was not enabled – strange. I ended up not needing it and Word XP started OK but was initially a bit flakey as said.

Two issues remain outstanding, but they are possible to live with:-

1/ Double clicking a .doc document always opens Word 2007, even if you try to change the file association. I had it working correctly for a little while (loading up Word XP for .docs and Word 2007 for .docx, but Word 2007 ended up taking over. This may have had something to do with the next point – ‘re-registering’

2/ Both versions wanted to reconfigure themselves each time you switched from running one version to the other one. Even on a fast PC this takes 10-20 seconds of thrashing with a conifiguration dialog displayed – not nice, although Microsoft say that this is normal behaviour if you have multiple versions (Word XP did its configuration a lot quicker). This post  describes the way around this by telling both versions of Word not to ‘rereg’ themselves, by setting the following registry keys :-

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Options\NoReReg = 1 (DWord) – for Word 2007
HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Word\Options\NoReReg = 1 (DWord) – for Word XP

This fixed the problem, although it is not entirely recommended as it may cause issues during fixes/updates that may need the ReReg to be run. I would imagine that removing the keys temporarily and re-adding them would solve this.

If I was in this situation again, I would certainly try to avoid installing multiple versions on the same OS – it is clearly not supported well. It would be best to use another machine or a VM.

No Comments »

I hit this problem trying to connect to a local Oracle XE 10.2.0.1 database.
The problem is due to a bug in Oracle’s networking layer. It cannot parse program locations containing parentheses, and by default Toad installs to “Program Files (x86)” which causes the bug.

More details on OTN here.

The fault is designated Bug 3807408, and whilst there is an Oracle patch for it, the patch is not available for Oracle XE.

The easy way around the problem is just to install TOAD in “Program Files” rather than “Program Files (x86)”. The different directories are purely to aid in distinguishing 32 bit applications from 64 bit ones – it does not matter where applications are installed.

I removed and reinstalled TOAD in “Program Files” and this completely eliminated the problem. The problem would also apply to other applications which access Oracle, so worth bearing in mind.

No Comments »