Vienna Symphonic Library Forum
Forum Statistics

194,053 users have contributed to 42,907 threads and 257,904 posts.

In the past 24 hours, we have 3 new thread(s), 19 new post(s) and 98 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. Critical Data Loss Bug in VEP7

  • Critical Data Loss Bug in VEP7

    S
    S

    UPDATE: FIXED in 7.1.1329

     

    This is real bad. Worse than any crash. More like a hard drive wipe severity.

    Latest VEP7, Latest Mac OS intel.

    Repro:

    1. Create a new VEP server project with 10 instances. Imagine this is your main template you've worked on for months.

    2. File/Save Server Project, name it "Main Template"

    3. Quit VEP7 (which does not allow closing a server project any other way than quit...which is a notable smell...)

    4. Launch VEP7 again and we'll use the new blank server project that appears for a specific project that doesn't need the whole main template, just one of its instances.

    5. File/Save Server Project and name it "Specific Template"

    6. File/Import Instances From Server Project... and import Instance "Untitled 8" from the "Main Template" server project you saved in step 2. You uncheck all the instances and then check Untitled 8 only before importing.

    => Untitled 8 now appears in the server project you're working on.

    7. Now File/Save Server Project (cmd-shift-S) to save your work.

    => At this point, everything seems fine. BUT THERE IS A VERY, VERY BIG PROBLEM.

    8. Quit VEP7, now that your Specific Template setup is done.

    9. Launch VEP7 this time by double-clicking Main Template.

    => Main Template opens, but NINE OF THE INSTANCES HAVE BEEN DELETED.

    Your months of work have been destroyed irretrievably unless you have a constant backup system. You now only have Untitled 8 instance in your Main Template.

    10. Quit VEP7 and launch it this time with Specific Template.

    => Specific Template remains blank. Untitled 8 never got saved to it. It got saved to Main Template, clobbering the rest of the data in Main Template.

    So what happened? There is a catastrophic data loss bug in File/Import Instances From Server Project. For some incomprehensible reason, the programmer decided to clobber the file system handle of the currently open file with the file they are importing from, and never cached and restored it to the current working file. The only hint this has happened is the title of the window you're working on changes to the file you imported from. But that is incredibly easy to miss, especially given you would never expect anything like this to happen. Fortunately in my case I noticed before losing a lot of work (although I have backups).

    The (hopefully very temporary) workaround is, after any use of the exceedingly hazardous File/Import Instances..., immediately do a File/Save Server Project As... and navigate back to the file you meant to save over, renaming accordingly. But this is so easy to forget to do you ought to make backups of both files every time before using that feature at all.

    Oh and if you have the terribly implemented Autosave feature enabled, you may not even get a chance to do the workaround before it clobbers your main template for you autotragically. PLEASE

    Whoever is maintaining this...don't make it this easy for some jerk on the internet to embarrass you like this. If it were my code I would be level set on finding these before anyone else did. I mean seriously. Given this product is for artists, who often won't have good backup practices, you can't have a bug this hour-destroying this easily exposed. You absolutely have to bring good, comprehensive QA on board and work with them.
  • E
    E

    I'm pretty sure you've encountered a bug I was about to report however, I don't think it's a data loss bug, but rather a subtle but really problematic SAVING bug?  Or maybe I've encountered a slightly different thing....

    Let's say you're working with a VEP file called "Template A" and you choose to import instances from "Template Z"

    The very next time you go to Save As, it DEFAULTS to calling your file "Template Z" and saving it in the SAME location as Template Z.  Which means, if you aren't careful to NOTICE and CORRECT this, it will SAVE OVER "Template Z" with the NEW (potentially totally different except for whatever instances you just imported) from Z.

    This is HIGHLY problematic, counter-intuitive, and should be fixed in my opinion RIGHT away.  Just because I want to import an instance from Template Z (saved on drive/folder Z), doesn't mean I've now totally abandoned working on Template A (saved in drive/folder A).

    Evan
  • S
    S
    last edited
    last edited

    @evang42 said:

    I'm pretty sure you've encountered a bug I was about to report however, I don't think it's a data loss bug, but rather a subtle but really problematic SAVING bug?  Or maybe I've encountered a slightly different thing....

    Let's say you're working with a VEP file called "Template A" and you choose to import instances from "Template Z"

    The very next time you go to Save As, it DEFAULTS to calling your file "Template Z" and saving it in the SAME location as Template Z.  Which means, if you aren't careful to NOTICE and CORRECT this, it will SAVE OVER "Template Z" with the NEW (potentially totally different except for whatever instances you just imported) from Z.

    This is HIGHLY problematic, counter-intuitive, and should be fixed in my opinion RIGHT away.  Just because I want to import an instance from Template Z (saved on drive/folder Z), doesn't mean I've now totally abandoned working on Template A (saved in drive/folder A).

    Evan

    Yes precisely. My suspicion is that they are using some ancient cross-platform database thing, and they kludged the import approach in a very, very inadvised way, and then promptly forgot to de-kludge the kludge and have no QA to find the oversight. Leaving it to us, with potentially disastrous results to our work.

    The insides of VEP are clearly the work of an A-level coder. The frontend on top of that was either asked of that same low-level coder, which is a completely inappropriate use of their skills, or was assigned to a junior C-grade Windows engineer who can't even get the file menu implemented properly on the Mac.

    This is version 7 of the flagship software product of the leading virtual orchestration company. I'm actually wondering, given how truly awful Steinberg's frontend work is, whether VEP is actually built by Steinberg under contract, and Steinberg gave them one of their best on the backend and worst on the frontend, and VSL don't have much control over it. Steinberg's userbase mostly on Windows and used to suffering, but artists mostly use Mac and needn't accept this abuse. We paid good money for this.

    Though I don't know the backstory and shouldn't start rumors. They have been fixing my bugs, so at least there's that. But this one, and seeing it's not just me smacking into it, doesn't merit patient sympathy. This absolutely had to be detected before signoff on GA.
  • S
    S

    Confirmed fixed in 7.1.1329. Congratulations.

    Happy to see a major bugfix release today, although I myself would have hotfixed this particular bug and got it out in 24hrs. Perhaps though it's better for a team that would make such a bug to do a full QA cycle even on a critical fix like this. You can skimp on coders, you can skimp on QA, but you sure can't skimp on both at once, and beta sites are not professional QA engineers. Hopefully things are looking up there and I'm happy to see the progress.