Old 10-21-2019, 04:42 PM   #1
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default Zero size .wav files

I've used Reaper happily for a few years now, but now I need help, or need to report a bug.

Last week, I used Reaper to record a multi track concert performance. I recorded the rehearsal (as I usually do for backup), then the live performance. When I came to edit the show, I found some of the .wav files have a zero size. The rehearsal was perfect, but the start of the live show was lost.

In detail, I was recording two stereo tracks at 96k to an external USB drive from a Windows 10 laptop using Reaper v5.79/x64 and Dante Virtual Sound Card, a configuration that has worked flawlessly for over 2 years.

There were no error messages, or any other indication that there was a problem. As indicated above, the rehearsal recording was fine. The concert recording ran for about 75 minutes, so a new file was created approximately every 31 minutes.

However, the first 3 files of the recording ended up with a size of zero, two from one track and one from the other. The later files are fine.

Has anyone come across this situation before? Maybe there is a problem with the drive...

I have another, critical recording to make tomorrow. I have replaced the USB drive, and will record to two drives from two laptops, but I would really like to know what happened last week.

Can anyone shed light on this?
Jeeves is offline   Reply With Quote
Old 10-21-2019, 05:14 PM   #2
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

I remember someone posting a similar thread a while ago around here and the conclusion was that Windows was caching files locally when using external drive volumes. The scenario was Windows either crashed or was interrupted by an unexpected shutdown and the temp cache never got written. It was either a poor choice for default made by the Windows team or it was easy to end up setting and not realize. So... a bug in your OS.
serr is online now   Reply With Quote
Old 10-21-2019, 05:46 PM   #3
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default Thanks, but

Thanks Serr, for your very prompt response, but I see 3 problems with your conclusion:
1. Windows did not crash or exhibit any unusual behaviour (not that that is conclusive in itself).
2. Reaper continued to record the remainder of the concert successfully and continued to run throughout the concert without indicating any problem.
3. Continuous flashing of the drive activity light suggests that there is continuous write activity to the external drive (as opposed to cashing the data elsewhere).

At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.

I'm more inclined to believe some sort of failure in the drive's structure.
Jeeves is offline   Reply With Quote
Old 10-21-2019, 05:49 PM   #4
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default whoops

Sorry, not 9 files, 6 files.
Jeeves is offline   Reply With Quote
Old 10-21-2019, 06:33 PM   #5
lunker
Human being with feelings
 
lunker's Avatar
 
Join Date: Nov 2007
Location: Lucas, TX, USA (via Luleň, Sweden)
Posts: 988
Default

May or may not be relevant:

For the first time in more than 10 years, I had a corrupt RPP file this weekend. (Luckily, I could recover it from the automatic backup copy)

When I compared the corrupt file to the backup, the last several lines (maybe 1/4 of the file) were missing. Even though I saved the RPP before exiting Reaper, it appears that the file wasn’t completely written right away, and I accidentally shut off the power strip before the PC had completely finished shutting down (total brain cramp -- I started the shutdown but got hurried/distracted and hit the power button without thinking).

So perhaps the files weren’t written yet when you shut down?
__________________
Best Regards, Ernie "lunker" Lundqvist
BDSM (Bad Dog Studio Musicians)
Windows 10 running on Z390 + i7-8700

Last edited by lunker; 10-22-2019 at 01:17 PM.
lunker is offline   Reply With Quote
Old 10-21-2019, 07:27 PM   #6
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default Conceivably

Well, I did exit Reaper just after saving the project, and shut down the laptop shortly after Reaper closed, (but not in a great hurry), so your theory could apply here (though the rpp file was OK).
Perhaps we could ask the software authors if there is any way that Reaper could exit before it knows that any file close action is completed.
Jeeves is offline   Reply With Quote
Old 10-22-2019, 10:51 AM   #7
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

I'm curious what the file system on the external drive is?

And did you check the S.M.A.R.T. data on the drive?
clepsydrae is offline   Reply With Quote
Old 10-22-2019, 11:19 AM   #8
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

Quote:
Originally Posted by Jeeves View Post
Thanks Serr, for your very prompt response, but I see 3 problems with your conclusion:
1. Windows did not crash or exhibit any unusual behaviour (not that that is conclusive in itself).
2. Reaper continued to record the remainder of the concert successfully and continued to run throughout the concert without indicating any problem.
3. Continuous flashing of the drive activity light suggests that there is continuous write activity to the external drive (as opposed to cashing the data elsewhere).

At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.

I'm more inclined to believe some sort of failure in the drive's structure.
I didn't make any conclusions initially...
But I'll make a couple now.

#2. That would still follow if the OS were caching the files. Reaper wouldn't and shouldn't know about this. It would be a transparent cache by the OS.

#3. Were you watching it during while it would have been writing the files in question?

If the drive were genuinely failing, you would get a write error or device not responding error. The "pinwheel of death" as people like to call it. (It just means an unexpected wait for one of the hardware devices in the system.)

So... Reaper saw the handshake for a successful write.
The cache for any external volume feature being turned on by default as other Windows users discovered would explain everything.

My conclusion is that if your filesystem shows a file of 0 size, that file is really 0 size now. It still could have a root cause of drive failure. (The scenario being that the file was complete and intact at the end of that night but suddenly not there when you next fired up that drive.)

But this WAS mentioned as a recent Windows faux pas that bit someone else on this forum in the ass and lost them a live recording. So I'm passing that along.

Reaper writes an end of file mark with every block of data written to the drive. That means the recording and file would be intact up to the point of power failure, should that happen. It's either it was being cached somewhere else and never got copied at the end by the OS or the drive really did fail between powering it off that night and powering it on later.

If you think the drive is corrupt... Recovery techniques like reading the whole drive as data and sifting through for what looks like files would be the thing to try.

Good luck and my condolences for the loss.
serr is online now   Reply With Quote
Old 10-22-2019, 12:06 PM   #9
lowellben
Human being with feelings
 
lowellben's Avatar
 
Join Date: Aug 2010
Location: They put me in a home.
Posts: 3,068
Default

I'm about to make your life better OP
Here is what I suggest ASAP.

Go to device manager and find the USB drive.
Go to policies.
Change write-caching policy.
Enjoy no more zero files.
__________________
47.8% of statistics are made up.
lowellben is offline   Reply With Quote
Old 10-22-2019, 01:26 PM   #10
lunker
Human being with feelings
 
lunker's Avatar
 
Join Date: Nov 2007
Location: Lucas, TX, USA (via Luleň, Sweden)
Posts: 988
Default

Thanks!

I just did.
__________________
Best Regards, Ernie "lunker" Lundqvist
BDSM (Bad Dog Studio Musicians)
Windows 10 running on Z390 + i7-8700
lunker is offline   Reply With Quote
Old 10-22-2019, 04:50 PM   #11
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default Thanks

OK everyone,

Thanks for your responses while we sleep here in Australia.

I have checked SMART and all drives report as OK.

File system is NTFS

I've now turned off write caching. Seems like a good idea.

I was watching as I told Reaper to save the files recorded in that session.
I also watched as Reaper saved the project.
These actions were very quick, as they usually are.

I then told Reaper to close - also admirably quick.

Then I used Rednet Control to switch off phantom power to the microphones.

Then I closed Dante Controller and Rednet Control

Then I closed Windows, and when the laptop switched off I packed everything away.

At no time was there any indication of a failure of any sort, or a power failure (laptop with battery charged and power supply connected).

Note that the 3 empty files were from the start of the recording. Would Windows have been holding 3 gigabytes in a cache for 45 minutes? There was ample time for all applications (including Windows) to close in a controlled way.

So, I have a new drive for today's critical recording, plus a second laptop and drive to run in parallel. The old adage is true - digital data doesn't really exist until it is on at least two different drives.

Thanks everyone.
Jeeves is offline   Reply With Quote
Old 10-22-2019, 07:16 PM   #12
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by Jeeves View Post
Would Windows have been holding 3 gigabytes in a cache for 45 minutes?
No, it shouldn't that I know of. If it were actually recording and writing the files to begin with they should be accruing size as the recording happens. To test this I started recording one track, and used task manager to end task and forcefully kill reaper while in the middle of the recording - the WAV file was not 0 bytes but rather 5MB or so which is what I would expect for the amount of time I let it record; and it was playable believe it or not. That's an internal not USB drive though.

If I didn't miss it above... What is the Date Modified time of these files? Does that gel with the actions you remember taking?
__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 10-22-2019 at 07:21 PM.
karbomusic is online now   Reply With Quote
Old 10-24-2019, 04:43 AM   #13
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default File date and time

The time of day in date created and in date modified are the same as on one of the files that was OK, that is, the full gigabyte in length. The times are 32 minutes apart as you would expect (stereo, 96k 24 bit). Although I didn't make a note of the exact time of day of the recording, those times are perfectly consistent with approximate start and finish times.

(and I'm pleased to say that both sets of yesterday's critical recording, on two machines, are fine).
Jeeves is offline   Reply With Quote
Old 10-24-2019, 07:49 AM   #14
drumphil
Human being with feelings
 
drumphil's Avatar
 
Join Date: Jun 2006
Location: Australia
Posts: 3,546
Default

If there is a pattern I've noticed in my experience, it's this:

Using external USB storage for mission critical recording applications is a bad idea.

If I had a dollar for every time I've seen things go bad because a USB cable moved a bit, I'd be a rich man.

As someone somewhere once said, If in the 1960's USB plugs had been suggested as a system for any mission critical application in a room full of engineers, you'd have been laughed out of the room.

Conceivably, brief dropouts in a USB connection to storage could be handled gracefully, but I doubt this happens in real life with the systems that are in place currently.

Now, this may have nothing to do with exactly what happened in this particular instance, but compared to critical connectors designed years ago, like XLR connectors, or even serial ports, modern convenient and universal connectors like USB are terribly badly designed for any situation where a break in connection can have serious consequences.

Last edited by drumphil; 10-24-2019 at 08:02 AM.
drumphil is online now   Reply With Quote
Old 10-24-2019, 07:54 AM   #15
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

Oh, you mean like the 1/4" plug with its tiny pinpoint contact that we got from WWII surplus?

Using a USB external for anything critical even if your OS doesn't have glaring bugs like this isn't a good idea. These are backup devices.
serr is online now   Reply With Quote
Old 10-24-2019, 08:04 AM   #16
drumphil
Human being with feelings
 
drumphil's Avatar
 
Join Date: Jun 2006
Location: Australia
Posts: 3,546
Default

Even PC serial plugs had threaded screws to hold them in place. DVI plugs still have that. Even display port plugs lock into place.

HDMI, USB, Thunderbolt and other such "modern" consumer plugs are bloody hopeless. Even firewire fails that test.

There are USB and firewire designs that have a locking mechanism, but basically no hardware out there has those features, and even then they don't even come close to the reliability of an old serial or parallel port plug.

At least these new brilliant electrical interface systems are easy to plug and unplug. Which is great given how many times you may have to do that to get a functioning connection. No problem, unless you need something to keep working without being interrupted because someone looked at the USB port a bit too hard in the middle of a recording.

Imagine running a gig with a 48 channel mixing desk, with every microphone connected to a USB port on the mixer...

That would never fly. But we're expected to connect the mixer to a laptop via USB to make the mission critical recording of the gig. Sigh.

Last edited by drumphil; 10-24-2019 at 08:14 AM.
drumphil is online now   Reply With Quote
Old 10-24-2019, 08:17 AM   #17
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

Yeah, everything just keeps getting smaller and wiggly-er! I'm not impressed by any of this crap either! TB is the smallest and wiggly-est yet.

I've been using firewire now since the 20th century. The modern FW800 port is much more shallow and wiggly than the FW400 port was. I've never had anything happen... (knock on wood and all that).

I honestly think I'll be looking at network audio moving forward. The ethernet plug has a nice solid ker-click with a locking tab and everything!

TB locks you into certain logic boards too. Maybe kind of a moot point nowadays.

Haha. Imagine the forum posts with someone trying to make a 48 device aggregate device! (Your USB example.)
serr is online now   Reply With Quote
Old 10-24-2019, 08:21 AM   #18
drumphil
Human being with feelings
 
drumphil's Avatar
 
Join Date: Jun 2006
Location: Australia
Posts: 3,546
Default

Quote:
I honestly think I'll be looking at network audio moving forward. The ethernet plug has a nice solid ker-click with a locking tab and everything!
Before I forgot because of how many beers I've had, I was going to say something about how funny it is that good old ethernet has become the future of digital audio interconnection.

Be it dante or AVB. I'm using AVB more and more these days in studios. Which is great so long as you can do what you want with MOTU or Presonus gear.

At least ethernet plugs have to be pulled hard enough to break something before they fall out.

My favorite example is the trash can mac's. A bunch of them were installed in my local TAFE (Technical And Further Education) facility. To connect to the MBox 3 audio interfaces, they needed a thunderbolt to firewire adapter, and then a firewire cable to the audio interface. Someone asked me if I could show them how that works. I said that I couldn't because if they looked at it too hard it would fail. In fact, don't even think about it too hard or it will break. Heaven forbid if someone needed to plug a USB memory stick into the computer..... Also, make sure you turn the fans and air conditioning off, lest a gentle gust of air wafts in the general direction of the computer and moves something a thousandth of a millimeter.

FFS...... Argh.

My standard advice nowdays is to just get a new computer with a big SSD, or replace the HDD with and SSD in an older computer, and be done with it. Which still doesn't eliminate all potential issues if you're using a USB audio interface. I never want to see a portable USB drive on stage ever again.

At my local radio staion, I purchased a new mac mini with 2tb of SSD storage for our playout system, which handles all live and automated audio broadcast. Someone said, couldn't we have got the basic model and attached a USB drive. I said, over my dead body.

Last edited by drumphil; 10-24-2019 at 08:46 AM.
drumphil is online now   Reply With Quote
Old 10-24-2019, 06:51 PM   #19
insub
Human being with feelings
 
insub's Avatar
 
Join Date: Mar 2014
Location: Louisville, KY, USA
Posts: 1,057
Default

Quote:
Originally Posted by Jeeves View Post
At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.
If the ReaPeaks files are intact, I think REAPER should be able to rebuild the audio files from them. I'm pretty sure I've recovered audio this way before.

I'm not familiar with Dante equipment. Do you have to use a router with it? Perhaps there was a Dante network failure?
__________________
Everything you need to know about samplerates and oversampling... maybe!
My Essential FREE 64bit VST Effects, ReaEQ Presets for Instruments
Windows 10 64 bit; MOTU 828 MKII, Audio Express, & 8PRE; Behringer ADA8000
insub is offline   Reply With Quote
Old 10-24-2019, 07:01 PM   #20
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

The peak files are image files to let you view waveforms without reading live from the actual audio all the time. They're a bit low res - notice how the view switches to live when you zoom in to the sample level.

There are some creative audio apps that will generate audio from waveform images but it's going to be telephone-like crude.
serr is online now   Reply With Quote
Old 10-29-2019, 09:22 PM   #21
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default More evidence

Here's some more evidence that might point to a disk drive problem, though I'm still not totally convinced.
I've now had time to look at earlier recordings on that drive. There were three concerts that I'd not yet processed. Each was multiple sessions, (stop and save at intervals in the performance).
The oldest event was fine, all files present and correct.
The next had one file of zero length, as before, at the start of the session, and should have been a gigabyte size.
The next had every .wav file of zero length, and over two sessions. Note that only .wav files were impacted, peaks files were OK, and whereas for the other recordings it was always gigabyte files, this was all the files.
So, the problem ran over three totally different events at different venues on different days. I would suspect physical damage to the disk drive during transit, impacting the file management tables on the drive, but why only .wav files?
Jeeves is offline   Reply With Quote
Old 10-29-2019, 10:32 PM   #22
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Yeah, it's a weird pattern.

Perhaps an intermittent problem crops up now and then that causes a file to not be written, so that statistically it just happens to be the biggest files (i.e. the ones that are open the longest) that most often exhibit this issue?

Peak files get regenerated if they are missing, but I guess if one was zero-length I wouldn't expect it to be rebuilt...

Have you scanned for viruses and the like? (Long shot, but just confirming.)
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 04:52 AM   #23
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default Viruses?

The laptop is used exclusively for recording, and has no virus checker installed. It is only ever connected to an isolated Dante network. Any software installs are downloaded onto a different PC, thoroughly scanned, and taken to the laptop on a memory stick.
So, a virus is an extreme long shot, and I really don't want to install a virus checker on that machine.
Jeeves is offline   Reply With Quote
Old 10-30-2019, 05:27 AM   #24
insub
Human being with feelings
 
insub's Avatar
 
Join Date: Mar 2014
Location: Louisville, KY, USA
Posts: 1,057
Default

Have you tested your RAM? Perhaps part of your RAM is bad, so that small files are transferring to the HD fine, but larger files are getting corrupted.
__________________
Everything you need to know about samplerates and oversampling... maybe!
My Essential FREE 64bit VST Effects, ReaEQ Presets for Instruments
Windows 10 64 bit; MOTU 828 MKII, Audio Express, & 8PRE; Behringer ADA8000
insub is offline   Reply With Quote
Old 10-30-2019, 09:49 AM   #25
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Quote:
Originally Posted by Jeeves View Post
The laptop is used exclusively for recording, and has no virus checker installed. It is only ever connected to an isolated Dante network. Any software installs are downloaded onto a different PC, thoroughly scanned, and taken to the laptop on a memory stick.
So, a virus is an extreme long shot, and I really don't want to install a virus checker on that machine.
Yeah it would also be weird behavior for a virus anyway, but it might be worth ruling out. You can do virus scans without installing anything, too -- various online services offer that.

(Also, if you ever connect a USB drive or thumb drive to the machine without a thorough scan... those are a very common vector... e.g. never ever trust a USB stick you plugged in to a computer at the library/copy shop/etc. Sounds like you're on top of this; just making sure.)

Given the cost of storage, the most time-/cost-effective way to debug this might be to get a different drive and install it.

Anyway: you said that the peak files for these zero-length files are fine -- how can you tell? When I test this manually, the zero-length files show as "offline" in reaper but don't show the peaks (in linux, anyway) -- is this what you are seeing? I.e. that the items in reaper are the proper length, but say "offline" when they are zero-length? And the .reapeak files are not zero-length, as I understand you to have said?

Are peaks being generated as the recording happens? And they are generating fine while the concert is happening and appear fine at the end of the recording when you are saving?

When you begin a session, are you creating a new project and saving it to a new directory before beginning recording? Or are you only setting the final directory on the final save of the project? Meaning, where is the audio actually being recorded during the show: the final project directory, or reaper's default record directory?

Have you tried deeper disk diagnostic/repair utilities? E.g. chkdsk and the like. Also here.
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 09:59 AM   #26
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Hey serr --

Quote:
Originally Posted by serr View Post
If the drive were genuinely failing, you would get a write error or device not responding error. The "pinwheel of death" as people like to call it. (It just means an unexpected wait for one of the hardware devices in the system.)
...do we know that this is true for reaper? E.g. reaper has that unfortunate behavior where if the disk fills up when recording or rendering it doesn't complain and instead appears to have worked fine (here, here, and here, and my sig :-) ) which makes me wonder what it actually does if there is some other kind of failure while recording?
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 10:01 AM   #27
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Jeeves -- how close to full is the disk you are recording to? E.g. when you finish a session, how much free space is there, and what is the total project size you just recorded?

I'm wondering about contrived scenarios where e.g. you record to reaper's default location, and at the end you say "save these files" or "save project here", which triggers a second copy to be made (at the final project destination) and that causes the disk to fill which causes zero-length files, and reaper maybe doesn't mention it...
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 10:22 AM   #28
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by clepsydrae View Post
Hey serr --


...do we know that this is true for reaper?
Running out of space for a non-system/OS disk write isn't a storage failure in the truest sense of the word so I think it's a good ask and may not be logged by the system.

CreateFile() which is likely what gets used here, will create a zero-byte file IIRC if you call it and not subsequently call WriteFile() to write data but it's just a side point. That's why I was curious about the create time and modified times of the files in question which I think the OP answered. I do think there is something obvious we don't yet know.

It would be smart to double check the Windows application and system event logs if not mentioned already. Because if such a failure did get logs, that's where it will be.
__________________
If it requires a null test to find it, it is by definition minuscule.
karbomusic is online now   Reply With Quote
Old 10-30-2019, 10:34 AM   #29
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,395
Default

Quote:
Originally Posted by clepsydrae View Post
Hey serr --



...do we know that this is true for reaper? E.g. reaper has that unfortunate behavior where if the disk fills up when recording or rendering it doesn't complain and instead appears to have worked fine (here, here, and here, and my sig :-) ) which makes me wonder what it actually does if there is some other kind of failure while recording?
I'll modify that to: You would get an error if you tried to record to a directory that wasn't there or a device that wasn't responding at the time you pressed record.

I guess I haven't ever tried running out of drive space during a recording or render. Evidence sounds damning... Maybe I'll have to try it.
serr is online now   Reply With Quote
Old 10-30-2019, 10:42 AM   #30
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Quote:
Originally Posted by karbomusic View Post
Running out of space for a non-system/OS disk write isn't a storage failure in the truest sense of the word
Yeah totally; I just got to thinking that I've never actually seen or heard about what reaper does if there's some kind of true disk problem while recording... I would presume a dialog would pop up saying so, but... dunno? And would it pop up when it happened or after you stop? Etc.

I guess for one test we could record to an external USB and just rip the plug out in the middle of recording and see what happens. :-)

Quote:
It would be smart to double check the Windows application and system event logs if not mentioned already. Because if such a failure did get logs, that's where it will be.
Yeah, OP: that sounds wise.
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 12:23 PM   #31
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by clepsydrae View Post

I guess for one test we could record to an external USB and just rip the plug out in the middle of recording and see what happens. :-)
I just tested that using a USB Stick:

1. Reaper just keeps on recording as if nothing happened! At least for the 30 seconds or so I let it record *after* yanking out the USB stick.

2. However, the file that was being written to was intact and playable (aka contained the audio recorded up until I yanked the USB stick) after plugging the stick back in and copying it over - pretty sure I remember WAV/RIFF has everything you need in the header so if that's there it's just data after that and wouldn't be corrupt.

#2 above is what I find odd as none of the tests I've done thus far = 0-byte files, they always include any data made it to the file before the failure.

The OP could just as a longshot and being thorough... from a command line running as administrator: fltmc instances which will list any filter drivers who have the ability to inspect and/or muck with IO packets right before/after they hit the physical disk. I may run procmon later when I have time and repro this test, just to see what the OS knows about the filestream when it gets interrupted. If procmon doesn't see it, it's low level and reaper possibly can't know.
__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 10-30-2019 at 12:30 PM.
karbomusic is online now   Reply With Quote
Old 10-30-2019, 12:37 PM   #32
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Whoa. Interesting. Thanks for trying it.

Quote:
Originally Posted by karbomusic View Post
If procmon doesn't see it, it's low level and reaper possibly can't know.
If true, that's some weird OS design, in my non-expert opinion... seems like any app should be told if the data it's writing is going in to a black hole...

At any rate, kinda makes the "disk or OS-level problem" theory seem a bit more plausible... if reaper can't or otherwise doesn't report an issue to the user (or even react at all) in some cases, then if OP's disk had some unusual issue that borked a file they might indeed see what they have been seeing...
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 12:58 PM   #33
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

There is one less likely but plausible idea for #1... If for some reason the disk dropped right when they hit record, then theoretically reaper could be "recording" for hours, click stop then a zero byte file would be the result.

Looks like ProcMon sees it and Reaper may or may not see it, and the result of the function call (IRP_MJ_WRITE) starts returning FILE INVALID when it drops (but this may be at the OS level and reaper calls a function that causes the OS to call this one, not sure) - you can also see the drive letter designation change to \device\... when it drops. But it still keeps writing to possibly nowhere or some cache I didn't have time to chase down - this is really a Justin question/investigation - I could learn a lot more with various tracing but what he knows already from writing the code is a couple minutes vs my hours of reverse engineering and reading Windows driver documents.

All that said, IRP_MJ_WRITE looks specific to serial devices so this could literally be only a problem with using a USB drive and indirect proof a serial device issue - minus all that reading I haven't had time to do:

https://docs.microsoft.com/en-us/pre...6904(v%3Dvs.85)

IRP_MJ_WRITE (Serial) - An IRP_MJ_WRITE request transfers data from a client to a serial device.

And the procomon output...

__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 10-30-2019 at 01:07 PM.
karbomusic is online now   Reply With Quote
Old 10-30-2019, 01:00 PM   #34
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Right on, thanks for checking it out. Will be interesting to see if OP gets any interesting results from chkdsk and the like. (If you have any tips on deeper investigation of troubled disks than my naive chkdsk, I'm sure OP could use them.)
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 01:05 PM   #35
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by clepsydrae View Post
Right on, thanks for checking it out. Will be interesting to see if OP gets any interesting results from chkdsk and the like. (If you have any tips on deeper investigation of troubled disks than my naive chkdsk, I'm sure OP could use them.)
I don't think it's the storage itself, I think it's the serial transport and any issues there not being handled well. I added some last minute edits to the above as well.
__________________
If it requires a null test to find it, it is by definition minuscule.
karbomusic is online now   Reply With Quote
Old 10-30-2019, 01:06 PM   #36
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Quote:
Originally Posted by karbomusic View Post
I don't think it's the storage itself, I think it's the serial transport and any issues there not being handled well.
== the USB subsystem/connection/etc?

edit: read your edits... so is this something that may be affected and/or fixed if OP were to update mobo drivers?

edit2: I guess regardless there's still the "ghost recording" effect you saw that feels like either a bug or just an unfortunate consequence of architecture...
clepsydrae is offline   Reply With Quote
Old 10-30-2019, 01:22 PM   #37
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by clepsydrae View Post
== the USB subsystem/connection/etc?

edit: read your edits... so is this something that may be affected and/or fixed if OP were to update mobo drivers?

edit2: I guess regardless there's still the "ghost recording" effect you saw that feels like either a bug or just an unfortunate consequence of architecture...
I have no idea other than thinking this probably would not occur with a non-serial SSD/HDD. I think it could be caching when it keeps writing - it's a USB drive after all and you can see before it is yanked it is taking the extra step to physically flush the IO packet to disk (FASTIO_ACQUIRE_FOR_CC_FLUSH) - I assume that's what it is anyway, then when yanked the virtual write continues but the physical flush to disk stops.

I did try plugging the drive back in before stopping the recording to see if things would magically link back up but they did not. Maybe the success is reported back to reaper when it successfully writes to the cache, but not from that cache to disk. That would at least align with stuff we already know about cached backed serial drives and data loss.
__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 10-30-2019 at 01:29 PM.
karbomusic is online now   Reply With Quote
Old 11-01-2019, 10:34 PM   #38
Jeeves
Human being with feelings
 
Join Date: Oct 2019
Posts: 9
Default More testing done

Hey, you guys have been busy while I've been off recording!

First, the current situation:

I've been using two laptops and two external USB drives, Win 10 and Win 7. Several sessions at several venues over the past few days. All totally rock solid. This is NOT using the USB drive on which I had the problems.
So, it is pointing clearly in my mind to an issue with the disk drive.
However, chkdsk reports no problems:
4287 files
166 indexes
0 bad sectors
But I'm not using that drive any more.

Thanks to everyone who posted. To answer,

insub - no. I haven't tested RAM. Will do if the problem recurs.

clepsydrae - I haven't seen the content of the peaks files, Reaper reports the file as being off line, but the size of the files is about OK, except for one zero length peak file from the very bad session.
Peak files were generated (or at least displayed) during the session. As I said up front, there was no indication at all, from Reaper or Windows that there was any problem what so ever.
And I always create a new project in its own, new directory, and save the project before I start recording (and at the end, before closing Reaper).
The drive still has 630Gig free, so I don't think disk space is an issue.

karbomusic - checked every sort of log I could think of, and found nothing.

*******
But, I've just run another test. With the (problem?) disk drive no longer in use, I thought there's nothing to lose, so I tried pulling the plug while recording. Reaper didn't miss a beat, and continued to build (at least on screen) the peaks file. So I re-plugged the USB drive, and still Reaper continued as if nothing had happened. Only when I stopped the recording, and said to save the file, did I get an error message. The peaks, which had been displayed including the section with no drive connected, changed to a file off line message.
Subsequent investigation showed a zero length peaks file, but a realistic length .wav file. The .wav file lacked the header information for sample rate, bit depth and stereo, and when opened (in Wavelab) contained no waveform.
*******

So another possible cause has to the the USB plug / cable (which I've also changed).

It would be really helpful if Reaper could detect / flag this sort of error.
Jeeves is offline   Reply With Quote
Old 11-02-2019, 02:15 AM   #39
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,901
Default

Quote:
Originally Posted by Jeeves View Post
*******
But, I've just run another test. With the (problem?) disk drive no longer in use, I thought there's nothing to lose, so I tried pulling the plug while recording. Reaper didn't miss a beat, and continued to build (at least on screen) the peaks file. So I re-plugged the USB drive, and still Reaper continued as if nothing had happened. Only when I stopped the recording, and said to save the file, did I get an error message. The peaks, which had been displayed including the section with no drive connected, changed to a file off line message.
Subsequent investigation showed a zero length peaks file, but a realistic length .wav file. The .wav file lacked the header information for sample rate, bit depth and stereo, and when opened (in Wavelab) contained no waveform.
*******
Looks like the same tests I performed, if for some reason a blip occurred when recording started, you'd get zero byte files but reaper would go on it's happy way and not tell you that the recording wasn't really occurring. I do think it is being cached by the OS, you can see in the tracing I showed above. When the drive blips, it is only writing to cache, when working it's cache/disk/cache/disk, when it blips its' cache/cache/cache/cache. In all of my tests however, the realistic length wav files worked and played back fine since the header got written.

Those write operations are USB/Serial specific so I think this is potentially impossible with an internal drive because the serial device writes aren't used. I may write up a bug/rfc demo later to see if the devs can chime in.
__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 11-02-2019 at 03:29 AM.
karbomusic is online now   Reply With Quote
Old 11-02-2019, 09:56 AM   #40
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,453
Default

Quote:
Originally Posted by karbomusic View Post
I may write up a bug/rfc demo later to see if the devs can chime in.
Had the same thought. We may never get to the bottom of OP's troubles, but at least this issue can be addressed by the devs; might be out of their hands, but if there's something they could do, seems like it'd be nice. Having files end up zero-length as everything seems to chug along merrily is a major bummer (even if it's unwise to record via USB).

I guess another experiment could also be to unplug a SATA HD while recording, but I'm not going to do it. :-)
clepsydrae is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:56 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.