I've been happy with the two WH16NS40 drives I had in my 5,1 for the past seven years but recently both stopped reading discs of each format in rather quick succession - some formats still worked initially but within a span of two months both drives were useless. I'd love to figure out how to repair them, but many around the internet seem to regard these drives as somewhat failure prone.
Without knowing about incompatibility in firmware sleep states between the 5,1's Intel ICH10 host controller and modern drives, I ordered a pair of Pioneer BDR-212DBK as replacements since sentiments suggest they're of higher quality than the LG drives.
I can't really recommend the Pioneer BDR-212DBK as it has a couple of problems on macOS, but, it is the most reliable blu-ray writer of the three.
I found this thread because of this specific post when I started to encounter issues.
The first issue I encountered is trivial- the drives' eject buttons are physically thick enough that they are pressed by the cMP's case frame. Installing the drives in the typical fashion for classic Mac Pros (drive tray face removed) is not quite enough; removing the entire faceplate was necessary in my case to avoid the eject button being pressed down when installed.
The second issue is more fundamental [and I haven't researched this extensively so I may misunderstand]: the Pioneer drives' firmware allows them to enter a more modern sleep state wherein they become somewhat inaccessible to the ICH10 host's older set of commands. If left unused for too long (maybe half an hour or an hour?) the drives 'disappear' from the list of 'Disc Burning' options in System Profiler [System Info] and appear as 'Unknown' devices in the SATA section, refusing to open their trays even when the hardware eject button is pressed on the drive itself. The only way I've found to reestablish connection is to restart the Mac Pro.
I've attempted a couple of software bodges which can help mitigate this state:
Running the commands
Code:
drutil status
drutil info
regularly (ten minute interval in cron [>/dev/null]) will regularly poll the drives' information, which basically prevents them from becoming 'Unknown' SATA devices. This is unfortunately not enough on its own...
Without a disc inserted the drive still enters a low power state, and despite still appearing as 'PIONEER BD-RW BDR-212D' on the ICH10 SATA controller it will no longer respond to requests to open the tray, etc.
Additionally keeping a disc inserted seems to largely mitigate this sleep state, but this is not foolproof. In an initial test the drive with disc inserted remained active for over 12 hours but then eventually reverted to an 'Unknown' state.
I've had considerably more success with a rougher approach; adding the following line to the crontab blindly instructs all drives to close their trays every five minutes:
Code:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * drutil tray close
This can be refined with drive names somewhat easily to only apply to 'Upper' and 'Lower' bay drives, rather than all (which may include external) but will still awkwardly close a drive the user just opened depending on the system clock.
Overall, however, this seems to work. Over 36 hours after adding this in cron, both of my drives (one with a disc inserted and one without) have remained accessible and responding to requests to open/close trays, read discs, etc.
Time will tell if this is ultimately stable...
Bonus points:
If this approach does prove to be sound, ideally a script which pauses the closing commands when a recent open event has happened can mitigate this solution's main caveat. Unfortunately it doesn't seem the drive's tray state is determinable by any command...
@joevt, do you have insight on this?
Running:
Code:
stdbuf -oL drutil poll | sed -n '/DRDeviceStatusChangedNotification/ {
N
/DRDeviceIsTrayOpenKey/ {
s/\n/ /
p
}
}'
cleanly produces a live output of events describing the explicit opening and closing of drive trays in the console.
I'd expect to be able to pipe that into
Code:
while IFS= read -r line
do
echo $line
done
So that I could implement logic to skip closing when an open command has just taken place for a given drive, however when I run this (as a prelimary test) nothing is written to console at all. Not sure why that is.
In the meantime, being able to use these drives is nice, even if I need to be aware they can quickly close if I open them several seconds before a five minute interval.