I would have thought that the problem is more likely to be associated with the IDE drives. At low voltage, the spin-up current required by the drive motor is likely to pull down the voltage lines for the processor on the disk's controller. This is a frequent complaint on the BSD hardware discussion groups - that the drive controllers themselves get into a screwed up state that effectively puts them out of reach of the system. They latch up and do not respond to commands (mainly due to inadequate voltage regulation and no processor voltage monitoring on the controllers - IDE is Low Cost, don't forget), and the only way to recover is a power cycle for the drive. In this case, SCSI is superior.

I don't think that the player is to blame; the Linux kernel should be doing drive retries to try and get them to respond, but it won't succeed. The player software is probably pending on kernel drive start operations. There is no mechanism for the ARM to power-cycle the drives (physically) and I am not so sure that there is a strategy actually built into the kernel to deal with a situation where the drive controllers don't come up as expected.

If you want to check this, you could run the SYSLOG daemon in the background (permanently) and set up kernel logging to look at what the kernel thinks is happening when this situation occurs.