There are a couple of issues at play here.
1. Trashing media databases only works around 60-70% of the time. And when it DOES work -- you can bet your diagonal tape slicer that it will happen again in the next couple of days.
2. When it doesn't work, you're in for a world of pain -- as the creative team sitting behind you stares at the back of your head wondering what the F you're doing -- and why they're going to miss their deadline again.
3. Then, you are obligated to proceed with what can only be described as an Rainman-eque idiot savant technique for finding a needle in the haystack. I mean really, it's 2011.
4. It simply can't be that hard to write a utility that completely interrogates each media file to determine if it actually robust and coherent. I don't care how many processing cycles it takes -- just do it.
5. While we're on this subject, why are users still dealing with a bevy of cryptic error messages that only serve to send editors to the web to waste untold hours trying to find out what they mean? Do we have the time for that?
6. I mean, really, isn't it time for the application to have a higher layer of intelligence -- that can see the error message code -- and present the user with a plain English list (or whatever language) of potential problems and potential solutions that relate to the error message? Do we all have to be programmers and distill system dumps? As loyal paying customers -- are we not entitled to the minimal amount of programming resources Avid would need to dedicate to implement some kind of intelligent overlay -- r to port solutions that are already available for the enterprise storage products -- and integrate them into the workstation products?
7. And, taking this one step further, what about self-healing? If the application implicitly understands that is is being exposed to corrupt media -- why doesn't it present the user with a dialog box indicating that rebuilding the media databases is strongly advised -- and with confirmation by the user -- it just goes ahead and does it. On a more obvious note, if the Timeline or Bin Window is overlapping the Source/Record monitor causing it to blink and not playback -- why doesn't the software simply move the offending item far enough away -- or notify the user -- so that it doesn't cause a problem? I, and every other Avid editor I know, could go on for hours and hours with examples like this -- but I think you get the point. Those of us that have used this software for many years have had to individually develop a mental encyclopedia of secret handshakes to overcome these kinds of problems -- but that doesn't make it right. And, I can guarantee that FCP users who find themselves considering a migration to MC will not appreciate this requirement.
8. Of course, self-healing systems can sometimes be a double-edged sword -- especially when they heal something that is not actually broken -- or when they heal it in an undesirable fashion that a technically-minded person would never do. However instituting a healing process that includes a dialog box for user-intervention addresses most of those concerns -- and would provide non-technical users a way to solve a host of problems that might otherwise have them down and inoperable for hours or days.
9. They say the auto industry doesn't make money selling cars -- they make money selling parts to replace the ones that fail the day after the warrantee is over. And, I regret to say, that there's something about the complete and utter lack of effort by Avid to address and evolve their software in this realm -- that makes me wonder if this scenario might be intentionally designed to generate Support Contracts. It certainly can't be because Avid creates professional caliber media tools that are frequently used in mission-critical environments.
10. It's almost as though these error messages have been intentionally kept cryptic -- and these systems intentionally DO NOT not self-heal the simplest of problems -- so that your only recourse is to call tech support or send them a FatalErrorReport. I don't particularly like making accusations like this, because they are not fact -- they are merely supposition. Furthermore, I am, and have been, dedicated to Avid and the MC platform for over 15 years -- and have spent literally millions of dollars on their systems. So I don't particularly relish thinking this way about my software/hardware vendor -- but I am beginning to wonder -- and maybe I'm also getting just a little bit agitated.
11. Lastly, it occurs to me that this kind of topic would be better-posted in Feature Request forum -- but, unfortunately, there are suggestions by others that are more far more relevant and important than the ones I have listed -- that have languished for years without any response at all. And, if by chance, this strategy IS designed generate or retain Support Contract revenue streams -- then it is a complete waste of time.
Apologies for being so verbose -- rant over.
--- In Avid-L2@yahoogroups.com, "jeffsengpiehl" <jeffsengpiehl@...> wrote:
>
> Actually interplay does this. It's media indexers will locate corrupt media, and place it aside. As far as it being hard? No, not hard- what it is is processor intensive. Interplay's media indexers are at least a pool of two high-end servers dedicated to only performing this task.
>
> You can do this as well, trash your media databases- the rebuild should flag corrupt media
>
> JDS
>
> --- In Avid-L2@yahoogroups.com, "blafarm" <blafarm@> wrote:
> >
> > This is a bit of a rhetorical question ...
> >
> > But after more than 15 years of dealing with frustrating problems caused by corrupt media -- why can't Avid simply create a application that scans all of the media files to indicate which files are actually corrupt?
> >
> > Is it really that hard -- or is this just plain laziness and lack of attention to detail?
> >
> > At this point in the game -- do we really still have to approach this problem like cavemen and cavewomen -- copying subsets of hundreds or thousands of files at a time to new folder -- until we finally find the block of files that the corrupt media file "lives in". And then having to drill down even further to find the file.
> >
> > It is absurd that we are still forced to use this Flinstonian technique to address this problem.
> >
>
If you want to donate to Red Cross quake relief, you can do so through your cell phone. Text redcross to 90999 to make a $10 donation. It will be on your next cell bill.
No comments:
Post a Comment