LG H55N goes crazy

My LG-H55N went crazy today. It was using the 1.03 firmware update with MCSE patch to remove ripguard since December 10, and had worked generally OK. But today it appeared to lose the ripguard and was slow to rip discs and very slow/unreliable burning. When trying to burn a disc at 4x it could only manage 1.5x speed and the device buffer was fluctuating wildly. Naturally I restarted my computer and cleaned up the op system, including a reinstall of my burning software ImgBurn. But that didn’t help. I verified that my computer was OK by burning a disc with my other drive on that channel (a Lite-On), so something appeared to be wrong with the LG. I feared that it had gone south for the winter.

I never liked the 1.03 update because it turned the drive into a noisy creature, where formerly it was fairly quiet. Even when playing a DVD movie, it revved up like it was trying to read at 16x, which is of course unnecessary! So I had a good excuse to revert to the 1.02 update, MCSE patched to remove ripguard of course, which had worked fine for four months prior to trying 1.03. To make a long story short, things are back to normal and the drive works OK again with the 1.02 firmware. I see no reason to change it again.

Sounds like the OS/drive switched to PIO mode.

[QUOTE=ala42;1968990]Sounds like the OS/drive switched to PIO mode.[/QUOTE]Thanks for your attention ala42. I thought of that possibility, but don’t think so, because… My Lite-On was on the same IDE secondary channel and it was not slowed down. Only the LG was slow to rip and burn.

I’ve always been suspicious of the 1.03 firmware because it turned the H55N into a noisy drive with a lot of unnecessary revving up. It behaves normally again with the 1.02 firmware. Now I see there’s a new release of 1.05 firmware but I see no good reason to try it. It’s working fine with 1.02 for the kinds of blank discs I use (TYG03 MKM001), so I’m going to leave well-enough alone, I think.

The computer can make the Master on a cable PIO, and not the Slave. That means that one drive can be affected and not the other. [Rarely is the whole channel–primary or secondary–affected].

I agree with [B]ala42[/B]. Sounds like the drive was switched to PIO mode. It might help to read this link. :flower:

Thanks for the link Albert. I read it for awhile til my eyes got tired. :slight_smile: I suppose you’re right but have no way to prove it, one way or another. It seems there’s no log which records when drives switch into PIO mode, or DMA mode. Looking at my system event logs only turned up what I knew already…

I had been trying to rip a badly scratched DVD. Both of my optical drives (Lite-On and LG) had trouble with it. The Lite-On refused absolutely with a CRC error. The LG managed to read it eventually, taking a long time to get past one particularly bad point on the disc. The result was OK. It burnt & played OK, after I “recovered” normal operation of my drives and op system, reflashed the LG drive, etc.

FWIW, the Lite-On is slave and the LG is master on my secondary IDE channel. Another of my mistaken assumptions was that a drive would automatically recover into DMA mode after having been put in PIO mode. But it would seem that the LG may have been put into PIO mode more or less permanently by these attempts to rip a marginal DVD with CRC errors. I seem to recall in my reading that this can happen after 6 CRC errors. In future I’ll remember to doublecheck it after CRC errors happen. I suppose one way to recover a drive from PIO mode into DMA mode would be to remove the device in Device Manager, then restart the computer which should reinstall it. So maybe reflashing the firmware won’t be necessary again in such cases(?).

Thanks for setting me on the right path. It’s pretty clear now that my drive reverted to PIO mode and did not automatically return to DMA mode. I found the following explanation easy to understand:
http://winhlp.com/node/10

FYI, that website also provides a later version of the vbs script (to reset drives from PIO to DMA mode) dated 2007-04-04, available at:
http://winhlp.com/tools/resetdma.vbs

The version posted at the cdfreaks link (from Albert, above) is dated 2007-01-29, same author, Hans-Georg Michna. I’m not familiar with vbs but hope it’s safe to use. It passed a couple of malware scans that I have available. Then I ran it, and it appeared to work correctly.