First Serious Glitches With DL32R and MF

[Topsøe]

Maybe it is the increased bandwidth demanded by the new 32. ch  files ?

[WK154]

Sorry BenO my money is on Seagate definitely not Mackie. They are far more thoroughly tested than any Mackie gear. I was trying not to bring up the obvious software issues such as having to wait after the software declares an operation completed and it's not, REALLY. What kind of programming is that? Skip the manual update and fix the software instead. If the OS hasn't been modified by Mackie buffered writes would complete and not cause any problems since plenty of time was allotted to writes especially in this case. As Gio stated FAT32 is FAT32 and I haven't read one reason why Mackie requires it's own formatting, maybe you should stick to the standard. Playing around with FAT allocation tables when you're not up to it will cause you problems. JMc I wouldn't try a SSD since it requires special handling I'm certain Mackie can't handle. Since we are talking about a USB interface to the drive there's lot's that can go wrong. A disk diagnostic on a PC will settle that issue.

[JMc]

Bill, why do you say an SSD requires "special handling"?  Can you be more specific?  I don't know why it would be different than using any other drive, so long as it was formatted properly...

[gerenm63]

In my experience, cut your losses and replace the Seagate trash with something else. Even their so-called "enterprise" drives don't seem to last more than a few months anymore. In fact, I've had nothing but trouble with Seagate drives since I got stuck with my first one in 1986. Until we moved away from them where I work, I was replacing them at a rate of 2-3 a month, every month. They had started failing within 3 months of purchase. We switched to Hitachi/HGST about 18 months ago, and I've had 76 of the little buggers spinning in three arrays 24/7 since then with zero failures (probably just jinxed that!).

[WK154]

Bill, why do you say an SSD requires "special handling"?  Can you be more specific?  I don't know why it would be different than using any other drive, so long as it was formatted properly...

Without going into all the techie details of every variation of SSD technology suffice it to say that whatever USB interface you have attached to the drive or incorporated on the drive it needs to be aware of the underlying SSD chip technology. That's why XP drivers although work on SSD's are inefficient and lead to early failure. Windows 6 on up had the changes incorporated in the driver. Not sure if it requires any  special handling in USB to deal with that. For that reason I would check with the Mfg. before use or avoid it altogether. Since I don't have the model # of your drive I can't go further. HD's are cheaper and handle more storage so I don't think you would gain anything with SSD's. HD's are in the 6Gbs range not going to be  challenged by 480mps.
Gerem63 I've had no such experience in the past with Seagate although the bulk of drives I installed were IBM/Hitachi with excellent results but also some failures.

[JMc]

Interesting.  I've been running XP on my 1 T Samsung 840 EVO for over a year now.  Troubling to hear of this early failure business..  I too have had no regular trouble with Seagate drives.  I switched to Seagate Barracuda drives after repeated failures by Maxtor and never looked back.  Of all the Seagate drives I've owned, I've only had ONE go bad, which was a 3T backup drive I purchased a few years ago.  It died after a year and was replaced, free of charge, under warranty.  I can tell you this...  I don't like how fussy the DL32R is sounding like when it comes to HDD.  It's worth noting that my recording problems seemed to coincide roughly with the last firmware update.  Prior to that, I successfully recorded about a dozen shows, never ejecting the disc and leaving the earlier recordings on it when I went to make more.  I'm glad that others aren't experiencing the same problems, apparently.  Guess I'm just the "lucky" one.  And what's the reason you can't just record to a USB thumb drive with this mixer?  I've never really heard that one explained.

[gerenm63]

Gerem63 I've had no such experience in the past with Seagate although the bulk of drives I installed were IBM/Hitachi with excellent results but also some failures.

Lucky you. 

I spent 15 years of my life in IT, and 8 years in professional audio/sound design before going back to television production for my day-gig about 12 years ago. I admit, I'm hard on disk drives, but I've seen a wide range of drives out there. Seagates have consistently been the worst -- and as I said, that's going back to about 1986. The best drives I every used were Quantums, but that seems like a couple of lifetimes ago...

[JMc]

Okay, latest wrinkle...  Using data recovery software on my HDD I found 264 .WAV files which probably represent the recorded shows that went missing due to the phantom FAT errors.  I can't say with certainty yet if they are intact and usable, but if they are, sorting them is going to be a bitch, but worth it in the end if all the performances are salvaged.  I'll know soon enough...  The recovered files are currently transferring onto a different drive and I am cautiously optimistic

I am also going to use the Samsung 850 EVO 1T SSD despite Bill's admonitions against it.  I see no valid reason not to try it.  It's a drive.  It SHOULD work just fine and in fact, might even be more suitable given there are no moving parts and it is less susceptible to vibration/shock and heat issues.  I have formatted it in the DL32R and successfully recorded some test files on the SSD.

I DO have a question for Beno, though.  WHY is the filename from a previous show (eur082115) displaying in the recording window of this newly formatted, completely different drive?  Why this particular show from August 21st when I've recorded others since then and why did the DL32R retain that information?  For what purpose?  How do I get rid of it?  Could this be a clue to at least part of the problem? 

https://www.dropbox.com/s/0r3jql2g5sl1zga/File%20Sep%2011%2C%2012%2049%2005%20PM.png?dl=0

[beno]

I DO have a question for Beno, though.  WHY is the filename from a previous show displaying in the window of a newly formatted, different drive?  Why this particular show from August 21st when I've recorded others since then and why did the DL32R retain that information?  For what purpose?  How do I get rid of it?  Could this be a clue to at least part of the problem? 

That's a bug. Don't think it has anything to with the issues. Master Fader keeps track of the last string shown there and isn't getting reset properly.

[JMc]

Thanks for your quick reply.  Just for reference, it was not the last show that recorded and saved successfully.  That was named something else and was saved the following day on 082215.  So, I'm not sure what, if anything, that means.   I've got a few more minutes to go before I can see if the recovered files are usable...  I'll report back here.  But, hey, glad I helped you uncover one bug, at least...

[WK154]

JMc I did state that you will get a shorter life out of the SSD drive as advertised due to the Fat file system and the driver.  Whether you will reach that point in this application before the drive is obsolete remains to be seen. If all you use it for is occasional recording of gigs most likely not. So Mackie is admitting to BUGS in their software but no-one is being affected but you, interesting. What vibration/shock and heat issues are you encountering now? I can't see that as a problem if mounted on the DL32 unless it's in an enclosed box which certainly wouldn't be a good idea since the DL has 2 fans and needs ventilation.

[JMc]

What vibration/shock and heat issues are you encountering now?

  I didn't say I was encountering any heat or vibration issues now.  I'm not as far as I can tell.  But the hard drive is strapped to the mixer and the mixer is in a road case and it gets picked up, set down, moved around, put in the van, etc.  I was just making the case that if anything, a SSD would seem even better for live recording use than a HDD with moving parts, that's all.   

Much later...  So when I fixed the errors on my Seatgate HDD with chkdsk /f, the missing files from our last show were found and renamed in sequential order of how they were recorded and placed in a hidden folder.  I was able to extract and replace the .chk extensions with .wav extensions and salvage the last show. 

Another gig tonight.  Going to be using the Samsung EVO 1T SSD and see how it performs, but despite Benos assurances, I'm still nervous about the bug.

[RoadRanger]

A couple of my products use FAT file systems that I wrote from scratch and that sure sounds like a bug in the firmware that isn't flushing the cached directory sector(s) out to disk when a file is closed. Thankfully it sounds like the cached FAT(s) are being updated and flushed so that chkdsk can find the data . When streaming data like that it's easy to get too "cute" with delaying the cache flushes - and forget to ever do them under certain circumstances . Could also be a write cache fault in the drive itself...

[JMc]

Recorded last night's show with the Samsung SSD.  No issues to report.     Just hoping the same applies when I plug it back in and use it for the next gig.  That one is going to be worth some money from post show sales, potentially.  BTW, for anyone interested, our three hour show (two 45 minute sets plus one 55 minute set of actual recording time, used about 1.625 gigs of storage per track, or a total of 26 gigs for the 16 tracks that were recorded.  That represents a lot of shows that can be saved on a 1T drive.  Think I'm going to throw this one in my PC and use a smaller SSD instead.