If a Serial Storage Device drops during recording, Reaper doesn't know it = data loss

[karbomusic]

[REPRO STEPS]

1. Create a project.
2. Set the record path so that the media is written to an external serial device aka USB drive.
3. Begin recording a track.
4. Once the track is recording, unplug the USB cable (to replicate what occurs if the connection drops on it's own for various reasons).

Expected behavior: Reaper throws an error or otherwise informs the user that the media has failed etc.

Actual behavior: Reaper continues "recording" as if nothing is wrong though the file is no longer accessible. Reaper could record for hours with the user assuming everything is OK.


[DETAILS]

See this post/thread...

https://forum.cockos.com/showpost.ph...1&postcount=33

It appears that while recording is in progress, if the serial drive/device inadvertently blips or disappears after record is pressed, Reaper either doesn't see or ignores the fact that the storage media no longer exists and continues to report to the user that everything is just fine and that the recording is still occurring - but it isn't...



It appears there are a couple of possibilities...

1. Being External the OS (Win) uses IRP_MJ_WRITE, when the drive is no longer present, the return value switches to FILE INVALID and Reaper isn't actually informed that the write failed, possibly due to caching/lazy writes.

2. The same as above but Reaper is informed and it is a missed case.

In all cases, IF Reaper can detect this, it probably should because someone theoretically can (and actually has per other thread), record for hours thinking everything is fine when in reality no data is being written to disk. It's also possible it went somewhere else (memory/page et al), but too much work to investigate further when the devs likely already know the answer.

Can the devs look into this and comment? We are a little concerned with risk of users losing hours of recording since Reaper doesn't give any clues that something went wrong. Even if recording external USB media is a bad idea, would be nice to know if Reaper can detect this.

Confirmed on Windows and Mac (and linux based on clepsydrae's reply below).

[clepsydrae]

Just confirmed on linux, too. Same behavior: recording appears to continue without issue.

[karbomusic]

Bumping since I added repro steps to the first post.

[karbomusic]

Bump!

[akademie]

Bumping also this serious topic.

Devs, please?

[karbomusic]

bump.

[Thonex]

Thanks for posting this. One more thing for my OCD to worry about during recording sessions. A solution to this would definitely add peace of mind and potentially avert disaster.

[karbomusic]

Bumping hoping for a dev comment - I'm pretty resilient myself, but since someone could run in record for hours and lose every minute of that audio without warning, seems important for chiming in.

[Fabian]

Similar thing happens when rendering to a disk that becomes full. Reaper just keeps on rendering, when the graceful thing would be to stop rendering and inform the user that something went astray.

https://forum.cockos.com/showthread.php?t=221562
https://forum.cockos.com/showthread.php?t=120185

[akademie]

Originally Posted by Fabian

Similar thing happens when rendering to a disk that becomes full. Reaper just keeps on rendering, when the graceful thing would be to stop rendering and inform the user that something went astray.

https://forum.cockos.com/showthread.php?t=221562
https://forum.cockos.com/showthread.php?t=120185

YES :-(

So another bump. Please...

[karbomusic]

Bump - cuz data loss - thanks!

[akademie]

Another bump

[karbomusic]

Bump, due to potential data loss - thank you!

[Meo-Ada Mespotine]

Bumperony

[Meo-Ada Mespotine]

I would add, that Reaper seems to have issues as well, with recording to a volume that's full.
So if you run out of space, Reaper keeps on recording without writing it, as there's no space available anymore.
This could cause broken recording-files.
Maybe that is linked to the problem above, that Reaper does not check if writing itself is possible at all.

[karbomusic]

Originally Posted by Meo-Ada Mespotine

I would add, that Reaper seems to have issues as well, with recording to a volume that's full.

Just an FYI there is a setting to warn you if the disk has less than the amount of space you configure but I'm not sure it is enabled by default?

Edit: it is enabled by default @ 1GB.

[akademie]

Originally Posted by karbomusic

Just an FYI there is a setting to warn you if the disk has less than the amount of space you configure but I'm not sure it is enabled by default?

Edit: it is enabled by default @ 1GB.

But question is if it checks for the space only at the moment of starting recording..?

I mean, if Reaper finds you have e.g. 1.2GB free space at the time of pressing REC button, so everything is OK, but few minutes later something is triggered in OS or other app and making a big file download, backup, tempfile or whatsoever, then Reaper does not check periodically if there is still some free space (while still performing recording task, or rendering task, or any file saving task in general!!!). Too bad then. It happens with rendering, too

[karbomusic]

Originally Posted by akademie

But question is if it checks for the space only at the moment of starting recording..?

Correct, but once recording has started, I assumed trapping the failed return value would still fall under this bug?

[akademie]

Originally Posted by karbomusic

Correct, but once recording has started, I assumed trapping the failed return value would still fall under this bug?

Yes, I would say.

[clepsydrae]

Some discussion on disk space cases here...

IMO we could really use options:

[x] alert when disk fills up while recording
[x] alert on recording stop if disk filled while recording
[x] do not create zero-length items if recording to full disk

[Fabian]

Originally Posted by clepsydrae

Some discussion on disk space cases here...

IMO we could really use options:

[x] alert when disk fills up while recording
[x] alert on recording stop if disk filled while recording
[x] do not create zero-length items if recording to full disk

I don't see any reason for these to be options. This is just part of graceful exit/degradation. When would anyone not have those turned on?

It is amazing to me that the devs, as great programmens as they apparently are, let this slip by. Could there be some technical reason for not checking the return code of a write operation and gracefully terminate the writing if the write fails?

[karbomusic]

Originally Posted by Fabian

It is amazing to me that the devs, as great programmens as they apparently are, let this slip by. Could there be some technical reason for not checking the return code of a write operation and gracefully terminate the writing if the write fails?

Not unless the API call that Reaper calls doesn't return the failure, but based on the procmon in my first post it does at that lower level and I'd expect that to bubble up - but I don't know the Reaper code and there could be another call, that reaper makes that I can't see, which is likely... so there could be other reasons but if so...

A dev comment would be nice so we could inform others, workaround whathaveyou.

There is another investigatory action I could take to help answer, maybe later if I have time.

[clepsydrae]

Originally Posted by Fabian

When would anyone not have those turned on?

Yeah that probably makes more sense. I think I was just being conservative in case devs or users didn't want the pop-ups.

Could there be some technical reason for not checking the return code of a write operation and gracefully terminate the writing if the write fails?

If it's not just an oversight or something not-yet-implemented, then my only guess is that the philosophy is in the vein of "professional tools let the user hang themselves if they want; let the user handle their own business without nagging them about stuff". But seems more likely that it's just that "warn if disk space < X" is enough to cover most cases so the others haven't been dealt with.

Given the stakes (e.g. lost data) I do hope these features (and the bugs mentioned in this thread) can get implemented/fixed some day soon.

[karbomusic]

Originally Posted by clepsydrae

If it's not just an oversight or something not-yet-implemented, then my only guess is that the philosophy is in the vein of "professional tools let the user hang themselves if they want; let the user handle their own business without nagging them about stuff". But seems more likely that it's just that "warn if disk space < X" is enough to cover most cases so the others haven't been dealt with.

I agree likely a missed case, especially since it falls out of the testing most would think of doing while testing in a dev environment. Actually, most of the debugging I do in the real world, is catching things people don't think to test when running test cases on code - then customers hit it.

[Justin]

We should definitely notify, I agree, this is overdue. We'll be adding this in the next cycle (with an option to stop audio processing if this occurs in order to draw attention to the issue).

[clepsydrae]

Awesome, thanks!

[karbomusic]

Yip, Yip, Yippieeeee.

Thanks Justin!


Edit: Once a pre-release build lands, someone let me know if I miss so I can add (fixed) to the title.

[akademie]

Nice, thanx.

[Fabian]

Originally Posted by Justin

We should definitely notify, I agree, this is overdue. We'll be adding this in the next cycle (with an option to stop audio processing if this occurs in order to draw attention to the issue).

Great!
Thanks.

[Meo-Ada Mespotine]

Awesome!

[Meo-Ada Mespotine]

Originally Posted by karbomusic

Yip, Yip, Yippieeeee.

Thanks Justin!


Edit: Once a pre-release build lands, someone let me know if I miss so I can add (fixed) to the title.

It is now added.