Some mp4 proxys can't be played in CatDV PRO 9.0.5 // Confusing behavior
I have a very strange Bug. Some MP4-Files can't be used as proxy clips. I tried different settings and codecs. It's all the same. The only similar thing about this clips: they all were made by Telestream Episode. I can import them and play them as a normal Mediafiles in a Catalog. But when I want to use them, as a proxy medias, the catdv pro failures to play them. The proxys are online and can be seen by catdv pro. The Paths are o.k..
As you will see from the Log File, the error "quicktime.std.StdQTException[QTJava:7.6.6g],-2015=invalidTime,QT.vers:7668000" appears, if I try to play proxy clip. The same clip can be played, when it used as a normal mediafile (when I import it in my Catalog). When I use a mp4 file created by Quicktime, no errors appears. It can be played by catdv pro.
Is it a known issue?
Do you know any workaround?
Thanx for any suggestions and regards
Hier is the Testfile:
And hier is the Log File:
so do they have the exact same name as the source and have you created a Path Based directory structure within the Proxy folder ? , and as usual is the path to the proxies correct. Do a quick test by building the proxies from within the Catdv client interface , Menu > Media > Build Proxy Media
the Problem seems to be the compatibility between the mp4 files and the CatDV. The Proxys were build in a proper way. The Paths and the naming are correct. I checked this by exchanging the not working mp4 testfile by another mp4 (that was created with MPEGStream Clip) with the same name. In that case everything worked fine.
I am confused because my mp4 files causes a strange behavior. If they wouldn't work at all, it would be clear. But they work in the slider "Movie" (if I use them as main assets, by importing in the catalog) and don't work in the slider "Proxy" (if I try to use them as a proxy files) in CatDV Pro. I don't know how CatDV build, but it seems that two different engines trying to play the same moviefile, and the proxy one fails.
Thanks for the file. We do see some "invalid time values" warnings with that file which might explain why it doesn't work as a proxy but we'll investigate and let you know.
The file plays as a Proxy on my system. I'm on version 9.0.6. Try downloading the latest version of CatDv.
The invalid time values is an Episode bug. They are aware of it.
Ah. o.k.. I see. It's a pity i didn't mentioned your post before, even though I searched the forum for some similar issues. But you have just the same problem as I have. It is often so difficult to spot the cause of the problem, when so many elements are involved in a workflow.
The Telestream distresses me more and more. I use different Telestream products and have always some confusing problems with them.
So it seams I can't use the expensive episode encoder I just bought for building proxys. Hm...
I will try the CatDV 9.0.6 asap.
Thank you very much!
You can use the command line interface of Episode engine to create the equivalent directory and use it to make proxies.
I'm still wondering how you got the clip running on your system. I tried all possible settings in Episode.
Mac OS 10.6.8
Quick Time Player (Version 10.0 (131))
Quick Time Player (Version 7.6.6 (1709))
CatDV Pro 9.0.6
Java SE 6 1.6.0_29-b11-402
Telestream Episode 188.8.131.52 (3412)
Can you give me a Tip?
When I import the Clip in a Catalog, CatDV says:
Import Notes: Movie contains invalid time values
I added a new testfile in attachment. 3862_testversion184.108.40.206412h264mp41mbit16x9.mp4.zip
I now use the ffmpeg to convert Clips into mp4. But it makes my Workflow complicated and slow.
But maybe Squarebox can somehow find the way to use that files.
Sorry, I've been slammed and just saw this. I revisited my test. It turns out I was using Xuggle to play the proxy. In your media playback settings make sure Xuggle is checked. QT doesn't work for me either.
That might not be a solution for you. Can you get away with .mov? I believe Episode 6 is not causing the same problems with .mov's.
I've also informed Telestream about my problem. And after several mails I became post, that makes me hope :)
We have made some progress with your issue. We beleive it will be resolved in an upcoming release. Our estimate is June/July timeframe. We believe the upcoming 6.3 release should resolve this issue.
Thank you for your understanding and your efforts."