Critical Bug: Media Items change position randomly in project file

[x7i7l]

Here is a gif that shows the bug in action:

https://ibb.co/dKqDdV

Steps to reproduce:
1) Work on media item, cut, edit and position media items according to the needs of the project.

Expected Result
Media items will stay in the position they were in, will retain their length, their playback rate, gain, and envelopes.

Actual Result
Without warning, and without any discernable pattern, hundreds of media items change their length, playback rate, gain and envelopes. Some clips obtain a length of 0, and a playback rate of 0.00000001 (or even peculiar words like "nan"). This is documented in the above gif where the Project Bay shows many media with a length of 0, that also misreport their location within the project file as all being at the same location place as the video file I imported, and when I delete this media item video, all these malfunctioning media items misreport their location to another part of the project.

--

Above is a summary, but to provide more context:

1) The project is the audio post production for a feature length film. It is from a Final Cut Pro XML file that was converted into a Reaper project by the program Vordio.

2) I imported a rough cut of the film to edit to.

3) I worked on the project for a week, mainly normalising dialogue. I did not notice anything strange, except what I thought was some drift between the media items and the video file. This seemed to go away when I asked for a copy of the video file with time code hard encoded into the image.

4) Close to the project deadline, one day, a large number of clips in the project were scattered in the way described above. (Some clips obtain a length of 0, and a playback rate of 0.00000001 (or even peculiar words like "nan").

5) I tried to go back to an earlier save, and backups of the project file, but found that upon loading, these older files also suffered from the same corruption.

6) I attempted to restore the media items to their locations. Some time after completing this task it happened again. This was repeaeted multiple times.

7) One time I observed that it happened when I hit "ctrl+z" - instead of the last action being undone, I watched multiple clips move their locations, change their envelopes etc. I have not been able to reproduce this when using screen capture.

8) I disabled all scripts, but the bug occurred.

9)I tried using a much earlier version of Reaper - v 5.51 but the bug still occured.

10) I thought that somehow the bug related to my nextcloud sync, so I disabled nextcloud but the bug still occurred.

11) It seemed through my experiments that copying media items from one of these corrupted projects would introduce the bug also into a fresh project.
--

This is absolutely a show stopping bug. I cannot work on any of my projects right now because I have no confidence that the bug will not destroy everything. My appreciation will be endless if anyone has an idea what is causing this and what the solution is. It cost me of sanity this last week and resulted in a missed deadline for a film festival.

[mrlimbic]

Originally Posted by x7i7l

10) I thought that somehow the bug related to my nextcloud sync, so I disabled nextcloud but the bug still occurred.

If a corruption has occurred in an RPP and it is your backup system doing this, then disabling your backup system after corruption would be too late anyway.

Attach a corrupt RPP here and I'll see how it behaves on a different computer/platform and also take a look inside for suspicious entries. RPPs are humanly readable so easy to spot weird stuff.

PS NaN means not-a-number, so a sensible value has gone missing.

[Eliseat]

Did you change the tempo while having your tracks on time base "time?"

[x7i7l]

@mrlimbic I see what you mean. The strange thing was, I was going back to project files that I was pretty sure were "pre-corruption" but would find that they were also totally warped (as if somehow upon loading the project file things were going awry). I guess it is possible that the corruption had occurred it hadn't noticed.

I uploaded the project file from the gif (without the media) here: https://ufile.io/u7oag

@Eliseat The project BPM has remained 120 the whole way through. And the bug is not only affecting play rate, but also changing the gain of media items to -inf dB, deleting media item envelopes and so on.

Thanks for your help!

[mrlimbic]

The corrupt project behaves really strangely & slowly on my machine. Beachballs for ages when doing anything.

It has hundreds of items with 0 length, 0 playrate, 0 volume in the RPP itself.

The original converted RPP contains nothing suspicious looking.

When reaper reads a project file it fills in missing values or nonsensical values with a default - usually 0. It is very tolerant of crap in the file.

I took the uncorrupted original RPP and changed an item's length for a stupid value. REAPER opened it fine with no complaints but the length was now 0.

<ITEM
POSITION 2797.3089267826203
SNAPOFFS 0
LENGTH rubbish

I've never had reaper save a bad file but it's possible. However, I think it's unlikely that lots of people wouldn't also notice.

It could be file system problems, backup system problems.

Although it's also possible you did something accidentally in reaper that applied to lots of items when you thought it was only one item, changing length or playrate to 0 is unlikely to do even as a mistake.

It's hard to know what is the cause or what to do without being able to replicate the problem.

My guess is something is very wrong with your system. When reaper saved a file something happened to the file. I doubt reaper would miss out or change those values when saving.

It is also possible that a drive is slowly dying. I recently had a few corrupt files on an internal drive and turned out that disk was dying and gradually gaining errors. I think the drive had overheated and damaged it somehow. I had to do a block level clone of the drive with Gnu DDRescue because even the OS diskutility clone tool would not copy it when it hit a bad sector. This was an extra headache because TimeMachine (the backup utility) had copied the bad files as empty files, so even my backups were corrupt. I didn't expect that. I thought TimeMachine would warn if it found a bad file, not assume it was empty!

[x7i7l]

@mrlimbic thanks so much for your assessment.

Its clear that something is wrong with my system but it is rather strange that nothing else seems affected. I'm working with Bitwig projects without any trouble.

Having spent time with the problem I feel like something is confusing Reaper and as a consequence it's encoding strange values. As I mentioned, one time I pressed ctrl + z and watched the project warp before my eyes. I thought that perhaps my cloud was substituting one referenced file for another and this was throwing off what Reaper expected. Also, I am using FLAC in my workflow, for all the audio. Could that somehow be causing this problem?

[mrlimbic]

Originally Posted by x7i7l

Also, I am using FLAC in my workflow, for all the audio. Could that somehow be causing this problem?

I doubt that is related to file format.

I'd do a some disk diagnostics asap. Do hardware integrity check first and then something that tries to read from every block on the disk, even if not used. At least eliminate that as a possible cause.

When mine started dying I only found 3 corrupt files initially. It had started putting zeros randomly into some audio files. Which then polluted the backups because the backup system thought they had changed intentionally and backed up the broken files.

It was only when I did checks that I discovered it was not working properly.

You need to use a block based tool like ddrescue that will find bad sectors. A file based backup system may not notice bad sectors (Mac TimeMachine didn't notice mine were bad - it just backed them up as zeros!).

[x7i7l]

I ran an extended SMART test on my hard drive, and got the result "OK". All of the important factors for a SMART test (reallocated sector count for instance) are fine. So it's not hard disk failure.

It also seems unusual that hard disk failure would target only certain parameters within an xml file and not other parts, like the header for instance.

It's devastating that I can't figure this out. I'll try Ardour in the short term.

Thanks everyone for trying to help.

[x7i7l]

Hi all,

I observed something new about this bug.

Since I last posted, I changed my HDD, reinstalled KDE Neon, completed a project in Ardour with no errors - it's safe to say that my hardware nor my OS is somehow responsible.

Then, with this problematic project file, I "scrubbed it clean" by rendering all the items in thep roject, and selecting "add rendered items to new tracks in project".

Then I deleted all the old tracks and all the old media items which were corrupted somehow.

Everything was going well for about six hours when i observed the following.

I dragged in a flac file that was quite long and sat layered behind two existing media items in a track. That was an accident so I hit ctrl+z - then a mutation happened, I watched a few media items move randomly, and I watched item envelopes set themselves to -inf.

Unfortunately I have not been able to reproduce this... so frustrating.

What was really strange is that when I opened earlier backups and saves, the same weirdnesses with volume envelopes and moved clips were also present. Then when I closed Reaper without saving and reopened these older project files, they were back to normal.

Maybe this is all due to some odd corruption just with this project file, or maybe there is some unholy alliance of circumstances in my situation that produces this bug. Who knows. My new work flow involves making an archive of the entire project basically every time i stand up, just to be sure.

[effitall]

Soooo....

What operating system/version of Reaper are you using? Your last post mentioned KDE and Ardour which is implying Linux. Are you running Reaper under WINE or are you running native Reaper? Does this problem happen on Mac or Windows versions?

[x7i7l]

Hi effitall

I'm using KDE Neon, which is an Ubuntu 18.04 distribution produced by the KDE foundation. I'm using the Linux native build of Reaper. Wine is not an option for this project because I don't think video is supported.

I don't have access to a mac or windows machine. The difficult thing is that the bug or whatever is hard to reproduce and only happens every approx. 6 hours of active work. So even if I played around on a mac machine with the project file for a while and nothing happened, it wouldn't necessarily prove anything.

I've turned on "trim content behind media items" as I'm curious as to whether this is somehow involved.

[ivansc]

Might be worth addressing this to the "official" Linux area of the forum. The Linux version is still very much a work in progress, of course.

Good luck!