A better and more efficient approach would be to make this update available for all of us to try now, at our own risk of course, which will broaden the testing field to a variety of scenarios that one or two post-production facilities will likely not cover, leaving the next release as vulnerable as the current one. We already know from experience that the idea of a longer wait period in order to ensure a more reliable release has yet to work in practice, opening it up could be the best decision you could make. Bottom line, what harm could it do?
I agree with Bowie. If you and your team can find a way to make sure everyone understands that it’s a beta, and that it’s at our own risk, I think there would be many takers.
I for one would do a quick install over a clone drive and test it without affecting my workflow (just an hour to test).
It would certainly bring up SOMETHING that will be missed by your current plan - admirable though that is!
As a side note - this level of communication from SB is a great step in the right direction, and very very re-assuring. I think we all appreciate it. Nearly there!
B
The videoengine is a separate component, os it is easy to test.
P
Hello,
let me have a conversation with other team members. Maybe we can extend the beta tester circle.
Thanks very much for your suggestions and the willingsness to support this release!
Thanks,
Timo
You’re missing the original point maybe… (?)
Well I understand that the “communication to all users” is the main point. From our point of view,
this release should not be just a hotfix but a completely tested update. Many users are not
visiting the forums and don’t know our conversations. Our goal is to make sure that these people
also get a stable, tested version.
Thanks,
Timo
That’s not what I meant. Read Bowie’s last post preceding this one. And it relates directly to the issue of being able to actually release a “stable, tested version”.
I’m sure you could make it clear that a release is BETA. Here’s an example of it: “Nuendo5.x.x_BETA” The word “BETA” should tip users off that it is a BETA, and not final release.
I’m sorry, but I’m with Bowie on this one in that a public beta “will broaden the testing field to a variety of scenarios that one or two post-production facilities will likely not cover, leaving the next release as vulnerable as the current one. We already know from experience that the idea of a longer wait period in order to ensure a more reliable release has yet to work in practice”
And by the way: I’m not the only one who has requested a larger and better beta team and has volunteered myself and others to do so. Fredo’s explanation that we don’t know whether or not beta found the problem really just points the finger in the direction of product development/management. Not an attractive alternate explanation. Just picking between two unflattering ones.
We’re talking about the video engine of a post app. Not trivial stuff. And the notion that one bug “covered” another bug and that the latter was undetected or ignored in favour of release is a deeply unsatisfactory explanation.
In the case of the .aaf from FCP issue for example, the explanation was that one bug covered up another. Well compare the methodology of identifying, treating and testing the problem using one .aaf from a user, versus letting the last phase, testing the solution, be done by a larger community in a real world scenario: If you test it yourself using only the .aaf file that exhibited the problem you get what you now have - another bug “uncovered” after release - whereas giving a beta to the community and letting them do real world testing for a couple of weeks would have uncovered the other bug just like it did, before the release.
See the merits of what Bowie proposed?
Either do that or get the beta/management people to do their job better.
I am definitely a fan of public beta testing.
Native Instrument does it and it has been a win win for them.
PR wise and more stable products.
rsp
I also think that maintenance updates could be tested by public.
Hello Timo,
Looking forward to any further news including a successful fix.
Hugh
Timo
We were doing so well, with communication and honesty…
Can we PLEASE have a little update about the update? Is SB on track or are they hitting problems solving the video issues? Either way, it would be great to know.
Thanks
Ben Bartlett
Hello,
the problem with the video drift has been solved meanwhile.
We’re currently still working on the “jerky” video issue, but we
made a huge step forward in finding a solution for that problem.
Thanks,
Timo
Thanks Timo. It’s good to know that progress is being made.
B
Thanks Timo!
Will autoscaling be back as an option? I really miss it!
Is there any update to this? I literally just updated and every now and then I get a “video engine” crash on windows 7 64 bit using N5 32 bit. Currently using Mjpeg as my video type and never had this problem in N4.
I’m also getting the video engine to crash using MP4. Should be noted I never ONCE got this crash in N4. My video is native using either one of these. Is anyone else getting anything remotely like this with the video engine crashing and having to reboot Nuendo/sometimes your whole machine?
Dear forum members,
a new Nuendo 5 video engine hotfix update will be released within the next 14 days. It will fix
the video drift problem and will - partly - also solve the stutter video issue. In fact, we’ll continue
to work on the stutter video problem even after that hotfix, as problems could still occur depending
on e.g. the processor type used. So there will be another, regular maintenance update, which
can be expected for early June.
More information regarding the video engine hotfix update will be availabe in near time.
Thanks,
Timo
Thanks for sharing this Timo!
Ola
Any news on the update?
