Project succesfully saved unreliable, lost a day of work

The confirmation dialog that says “project succesfully saved” doesn’t seem reliable.

I worked a whole day on a project yesterday, I save very frequently because of the amount of work and time that goes into it.
Normally, I put the computer in sleep mode at night so I can get to work immediately.

Today, I found my computer not asleep when I woke up.
A power outage might have happened, or a bug crashed and rebooted the system.

Not a big deal, cause everything is saved I thought.
Imagine my surprise when I opened up Midi Translator Pro and everything I did yesterday is just gone.
The last save seems to be from the night before yesterday, so a whole day of work is gone.
My notes from yesterday are all still intact, so it’s not a file system glitch.

How could this happen?

Are there backup files somewhere?
edit: Found a slightly newer file from noon yesterday in the temp folder, however, most of the work was done after that.


I’m sorry that this occurred and I have never seen this before on Windows or Mac. I’ve been working with MT Pro since 2016.

Maybe for some reason you saved your project file to a different folder than you had originally thought? Another possibility is if you saved it to a cached ram drive, however people rarely use ram drives these days now that SSD are around.

Another possibility is if you have multiple instances of MT Pro running (not recommend) in which you saved in one instance and then later overwrote your changes of the older loaded and unedited file in a previously opened instance.

If you are Windows, you might want to check

%APPDATA%\Roaming\Bome\TempProjects to see if you can find something there.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:
1 Like

Same here, have been using it since classic.


  • It’s been the same folder for years.
  • No RAM drives, system drive is an SSD, storage is on a RAID5 array with cache disabled(no writeback). SSD is Crucial with power loss capacitors, disks are Seagate Enterprise Storage.
  • Only a single instance running.

Yes, that’s where I found the slightly updated version.

Don’t get me wrong, I’m not blaming the crash on Midi Translator, that’s 100% my system.
I found out from the logs that when I put the system to sleep, the file system from one of the disks crashed and took the windows file manager and windows with it.

I have no doubt that this is due to the Intel Storage drivers, which are horrible and have caused similar behaviour before. I’m sure the file system reported to BMT that the file was written succesfully.
The confirmation dialog that says “Project succesfully saved” seems to be just that confirmation from the file system though, which apparently can’t be trusted.

What bugs me is the fact that every other program had it’s settings and files saved correctly up until the very last edit.
The BMT temp folder only contained one version of the file from yesterday, but plenty from the day before. The BMT settings directory had 3 backup files for yesterday’s settings though, from much later times than the project backup.

Now, while this may all be blamed on my system, I would still want to put in a strong request for an auto save feature:

  • A selectable folder where auto-saves are stored with an interval of a selectable amount of time.
  • Even better would be if BMT also checks if a reportedly written file can actually be read, before giving the confirmation.


If your file system is broken and it reports a successful write, back to MT Pro, there may be little we can do. We could make backup copies but if they are on the same file system, that wouldn’t help.

For this reason, I run a program called “AllwaySync” that periodically (you can set the time) looks for changed files on a file system folder structure and writes it to a different drive. I think there are other similar solutions. There are plenty of other solutions out there that can do similar.

I actually have 2 other drives that I periodically update, one USB external drive and one network attached drive. There are probably also cloud storage solutions that can handle similar.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:
1 Like

As it is set up right now, the BMT files are on the disks, I found the backup on the SSD.
That’s why I was so surprised that the last backup was from noon that day, it’s physically on a different drive. I can imagine one file system being broken, but 2 at the same time?

Up until the crash, all other programs did write succesfully to the same file system.
I can’t explain that difference.

I use FreeFileSync for that, but it’s always nice to have that feature built in.

Maybe an option to insta-save every change when it’s made, like most IDE’s?

I’ll forward your request.

1 Like

Thanks, any feature that makes this less likely to happen again is very welcome.

Luckily most of the code for the rules was still in my notes, so I could easily recreate everything.
But doing the exact same work twice is very unsatisfying.

I’ll assume it was just an unfortunate glitch for now, and set this topic as solved.

@DreamXcape , first of all, I’m very sorry what has happened to you. This is a very serious issue, and we appreciate your way of handling this. I know you don’t attribute the root cause to MT Pro.

A few quick clarifications:
MT Pro continuously saves backups of unchanged work in the location that you have found. It does not save a backup of a file without changes. So, if you frequently save your project files while editing, automatic backups are not created. It’s not a fully automatic recovery system for all kinds of data loss, but this is a start.
You will need to have this option checked for that:

Hard Drive failures come in different flavors. Could be a physical defect, or a corrupt file system, or combinations. It is rare that all files are affected, but it’s likely that the most recently saved files are affected, or that these files are the ones you notice missing at first. And you cannot draw any conclusions from finding that not all most recent files have gone missing.

Thank you for your suggestions.

So far, we only intended to manage unsaved changes. But maybe, managing previous versions of a project file is a good idea, too. But that would be mainly a tool for handling user errors. It does not help (much) in case of file system corruption. I’m slightly hesitant here, because, as Steve said, that is really better handled by backup solutions and/or file versioning systems. We would only add a feature that you should use already anyway…

That might seem like a good idea, but maybe it wouldn’t help as much as hoped. MT Pro only reports success if the OS told it that the file was successfully written. And if the OS has reason to believe that the file write operation was successful, the file is likely present in the file read cache. Re-reading will read it from cache. You may also have write cache enabled, so when Windows reports “success”, the file may not even be written to the disk yet. If you’re concerned about physical drive/SSD failures, a RAID 1 is a safer choice. But also RAID systems rely on error reporting from the drive…

It is also possible, and likely, that a file system corruption caused the missing files on your computer. That could happen some time after writing them (e.g. file system check at boot), so MT Pro could not have detected that problem if it did verify the written file, and managed to bypass the file cache. In the case of file system corruption, the actual files are still on the disk, just not accessible anymore.

When I am working with MT Pro to create a translation project, I save frequently. Every now and then, I increase a suffix number of the file name to keep previous versions. And this is in addition to regular backups of the hard drive. I replace my hard disks after 2-3 years, SSDs after 5 years.

1 Like

I had totally forgotten about this. Thanks for pointing it out, @FlorianBome.

1 Like

Thanks Florian,

That’s probably what happened, it explains why there were so few backups made that day.

I absolutely agree that this is mainly for user errors, but it might also help in case of file system corruption if the folder is selectable. That way it could be assigned to an external drive.
It would still depend on the user for setting a custom folder, but the option for extra safety would be there.

That occured to me too when I was double checking my system’s cache settings yesterday.
Even though write-back was disabled in the Intel Rapid Storage settings and cache was set to read-only, windows still had it’s own write cache enabled.
Without that all storage slows down to a crawl, so I think you’re right about checking if a file is on disk not being that easy. At least not with a default windows configuration.

I don’t think in my case that files can be read from cache before they are actually written, because I have all data security features enabled, but it does explain why the BMT file didn’t make it to disk.

That is a good rule, I’ve built hundreds of computers for customers in the past and that is actually the exact recommendation I would give them. Except that SSD’s didn’t exist back then.

I have 4 enterprise drives set up as software RAID5, it’s slow as snails.
I checked all the drives today for hardware faults, s.m.a.r.t. says all is good.
But I did notice the Power On Hours, which is coming up on 4.5 years(only 37 spin-ups). And even though they’re enterprise drives, it’s probably time to replace them.
SSD’s are different though, the SSD that was installed together with the hard drives only has 51 days worth of Power On Hours, and only 6% of it’s LifeTime used.
I still replace them, but re-use them in less important systems.

For backups I use external drives, I should probably backup more often but I’m lazy.

Today the exact same thing happened again to my system.
Instead of being asleep it apparently just crashed and shut itself off.
Normally this system is stable for at least a month without reboots.
I just hope it’s not gonna die soon :anguished:, I don’t want to buy a new one with these shortages.

Oh no! It can be very difficult to find the root cause. Recently, an older Linux system of mine was kernel-freezing every now and then. Everything I tried to fix this did not help, and I was ready to replace it. But then I found that relaxing the RAM timing in the BIOS fixed it. It ran for more than 10 years with the faster timing, and suddenly it needed to be changed? strange! but stable ever since :slight_smile:

Thanks for the tip, it might actually be spot-on. :slightly_smiling_face:

The memory in my system could never be run on the XMP profile it was meant to run at.
My motherboard just won’t run 4 sticks of ram at full speed, so I already turned it down a bit.
But since it always ran close to that limit, that limit might have lowered a bit over the years like your Linux system.

The system log reads like some kind of power failure when going into or coming out of deep sleep.
Memory power delivery being weak could probably cause that.
Who knows, I’m never there when it happens.

It’s a wonder my system has been running this stable for so long anyway, the motherboard gave me all kinds of trouble in the beginning. The USB ports are extremely picky, it blue screened whenever I switched on a connected RME FF UCX. Had to swap it out with the RME 802 from the other room just to avoid that, and it still hangs up Totalmix sometimes. Any Allen & Heath Xone audio interface is an unstable mess, and any USB cable over 3 meters long causes instable connections at completely random intervals(can be hours, or weeks).
Also any drive in a RAID array can not be spinned down or it’ll end up in an endless spin-up/down cycle.
I could go on…
Needless to say any casual computer owner would have trashed his thing long ago.

BIOS updates over the years have made it a lot more stable but it’s never been completely worry free.
I used to like Asus motherboards…

Sorry for the long nerd-out. :nerd_face:


I found out what happened with my system.

Apparently this now also happens sometimes when putting the system into deep sleep.

That doesn’t sound good! Thanks for the update.