[RESOLVED] X3 data corruption

I just posted a tech support request for this, but I thought I'd mirror it here with a bit more information that I couldn't fit in the description field.
 
I just upgraded from SONAR X2 Producer to X3 Producer. When I try to open a particular existing project, the app hangs with the blue circle cursor. The first couple days, the file would open after five to ten minutes, seeming to take longer every time I opened the file. Now the file no longer opens at all, at least after 30 minutes.
 
Looking at automated backup files, the .cwp files seem much larger than I would expect. The oldest X2 backup is 10MB. The first post-X3 backup is 17MB. The next two are 32MB. The current size is 60MB. I did a small amount of recording in-between, but no more than a dozen clips totalling 5 minutes tops, probably much less.
 
During the hang, the SONARPDR.exe process uses 100% of a single CPU core. Once the file opens (when it used to open), everything seems to work normally.
 
The same phenomenon happens when I attempt to open the file now with X2 (although the file now has some X3-specific plugins in use). But the problem did not appear until I installed X3. Other projects--that I have never saved with X3--still open normally under X2 and X3. I can open the backups of the problem project with both X2 and X3, although they take longer than I would expect.
 
I have tried rebooting, running X3 as administrator, and running Windows Update with no luck.
 
Machine specs:
* Windows 8 Pro x64
* Four CPU cores
* 8GB RAM
 
Digital audio gear:
* Delta 1010
* Line 6 POD XT
* Oxygen 61
 
When I attempt to open the problem file, a series of Windows Event Log messages appear in the Applications log:
 
msiexec (3984) Instance: The database engine (6.02.9200.0000) is starting a new instance (0).
-----------
msiexec (3984) Instance: The database engine started a new instance (0). (Time=0 seconds)
Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000.
-----------
msiexec (3984) Instance: The database engine attached a database (1, C:\ProgramData\Microsoft\Windows\AppRepository\PackageRepository.edb). (Time=0 seconds)
Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.000.
Saved Cache: 1
-----------
msiexec (3984) Instance: The database engine detached a database (1, C:\ProgramData\Microsoft\Windows\AppRepository\PackageRepository.edb). (Time=0 seconds)
Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.016, [11] 0.000, [12] 0.000.
Revived Cache: 0
-----------
msiexec (3984) Instance: The database engine stopped the instance (0).
Dirty Shutdown: 0
Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.000, [13] 0.000, [14] 0.000, [15] 0.000.
Fault bucket , type 0
-----------
Event Name: AppHangTransient
Response: Not available
Cab Id: 0
Problem signature:
P1: SONARPDR.exe
P2: 20.0.1.211
P3: 5243f5ad
P4: unknown
P5: unknown
P6: unknown
P7: unknown
P8:
P9:
P10:
Attached files:
These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: e53c732b-2afe-11e3-bea8-485b39caaf65
Report Status: 2049
Hashed bucket:
 

Yes, the first thing I did after opening the project in X3 is switch some clips from V-Vocal to Melodyne.  (The latter is a clear improvement sonically.)  I'm happy to upload the project and its backups if it would help.  Where/how do I do so?
 
Thanks for the quick response.

Other folks report problems with VST scanning, so I removed all VST scanning paths.  The project still fails to open while consuming 100% of a single CPU core.

Project file is available here:
 
 [Edit:  Because I'm newly registered to the forum, the system won't let me PM or post links, so I'll try to strip off the https:// part.]
 
docs.google.com/file/d/0BxcWsc4IvzckLXhpLUxXbW1vSFU/edit?usp=sharing

Fair enough.  At least from my browser, removing the leading "https://" made the link visible.
 
Some additional info:
* The problem project opens after about an hour of the busy cursor.
* Once open, I can no longer save as a "Normal" or "Template" project.  After about a minute, I get a "General Error" message box.
* When I try to save as as a bundle, I get a message box saying that projects with AudioSnap data cannot be saved as a template.  This confirms there is indeed audiosnap data in the project.
* After deleting one track with a groove clip (but no audio snap), I can successfully save, but now the .cwp files size nearly doubles from 60MB to 117MB.
 
[Edit:  Added a bullet and fixed typo.]

Thanks for looking at the file, and I'll try your suggestions.  I'm happy to upload a bundle file (assuming I can create one in this state) if that's what you need to more thoroughly diagnose the issue.  I thought "the project" meant the .cwp file.
 
I can be a control freak, but I'm confident that I didn't manually adjust 524288 markers.  Other than applying Melodyne, I didn't knowingly follow a different workflow than I've used in X2.  It sounds like you're describing a known issue, or at least an area with historical problems.  Is there a bug tracking number or link I could follow to help me avoid this situation in the future?

Thanks to your help, I was able to recover the project.
 
The problem was in two copies of a single AudioSnapped clip.  Using audio transient view, I scrolled through the tracks looking for shifted transients.  When I got to one of the problem clips, the display become very slow to update.  Opening the AudioSnap palette took nearly a minute.  I could only see a half dozen or so white transients and a bunch of disabled markers.  The threshold was set to 75%, but the duration was over three times that of the project.
 
The clip is a measure of crescendo 32nd notes on a snare drum.  I believe I used AudioSnap's Quantize function to tighten them up, but that was weeks ago and I don't clearly remember.
 
I bounced one of the copies to a clip, deleted the originals, and replaced them with the bounced clip.  That has completely fixed the problem.  The .cwp file went from 60MB to 3MB.  Open and save times are back to normal.
 
Note that the .cwp file size was doubling every time I saved, even though I wasn't modifying the problem clips at all.  I could open the file at 60MB, delete some tracks with no AudioSnap, save, and the file jumped to 117MB.  So even if I did do something stupid with AudioSnap, something in SONAR was multiplying the markers (or at least the file size) all on its own.
 
I originally applied AudioSnap to that clip in X2, but I did not see a problem until the project was saved under X3.  It could be that the markers were multiplying every time I saved in X2, and it was a coincidence that I noticed the slowdown under X3.
 
Should I file a bug report before I delete the bloated .cwp files or clean the audio folder?
 
Thanks again for your help.
 
(FYI, there is no option to clear all snap markers that I could see.)

Problem report is filed as CWBRN-20343.

The demo will be out soon enough.

Bob, I don't think it's the problem is technically data corruption (although it could be a precursor to data corruption - e.g. if you unplug/smash your machine in frustration). I think the problem is actually more prevalent that you think. Some people don't bother to mention the problems they encounter. Some might simply swap it for another product. Others may blame themselves, believing that the the problem is their own fault, caused by their specific set-up or just some freak on-off data corruption event. 
 
Alex, I was kind of hoping to get a reliable recent Sonar and running very soon, rather than wait for a demo to come out.  If you or anyone with X3C can give me an idea what to expect, especially in respect of whether these audiosnap inadequacies have been resolved and also if any of the features useful features listed at the top of my May 2012 post (which became the basis of a Feature request list to the bakery some days later) have been implemented...
 http://forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx

> Alex, I was kind of hoping to get a reliable recent Sonar and running very soon, rather than wait for a demo to come out.
 
No point in testing anything at all now for bugs/features until X3D is out, which is next week, and I place bets the demo will be out within a month, if not this month... (just a hunch!).
 
Cheers...
 
BTW
 
After you review this I suggest creating one thread at a time for any specific missing features or bugs you would like to discuss. One step at a time or we will get overwhelmed. When you made the feature requests/bugs I hope you created one feature request per item, otherwise the chances are it may have been ignored as compilations are difficult to process in the land of software.... you may want to have another go if you did this (analyse one issue at a time, baby steps I suggest, adopting KISS)... To be honest the thread you pointed me towards isn't exactly what I call bite size and a discussion seems to have already taken place, which put me off somewhat (I am a bear of very little brain, trinkets need to be placed in front of me and I need a clear path and direction to follow) .

This is still a BIG issue, unaddressed. Very disappointing. Here's what I've gone through:
 
http://forum.cakewalk.com/Sonar-X3-files-suddenly-get-too-large-m3342543.aspx#3342583
 

robert_e_bone

A V Man
Ah. I see the wheels are turning, albeit very slowly... 19 Months and 2 major releases of Sonar since I reported this problem and now someone has actually proposed doing something about it... instead of slagging me off for mentioning it.
Also, as I've mentioned here on the forum and in messages to Sonar Support, because Audiosnap on long and/or complex audio takes so much time to process there should absolutely be design feature (an "Are you sure?" dialog perhaps) to prevent audiosnap data being applied accidentally or unecessarily.  for the same reason, audiosnap should be available on a "per-clip" basis not "per track".  The amount of data created can be ridiculous and project files become unusable especially when the data is apparently multiplied by subsequent saves. I can't believe that two major releases of Sonar have come and gone without this major issue being fixed.
 
BTW If anyone with X2 or X3 has the time, I'd be interested to know if any of the functionality I listed in the post below is actually possible yet...
http://forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx  
forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx

I think what might have happened is that to the best of my recollection, there just have not been a bunch of occurrences of this kind of issue (I am not taking any sides on this issue - just speculating on the apparently reduced attention given to it).
 
I am glad some improvement to dealing with this kind of corruption is available, and I hope you and the OP don't have this crop up again in any case.
 
Best of all to you guys, 
 
Bob Bone