Problem with Proxy invalidation

NormanPCNNormanPCN Website User Posts: 3,950 Enthusiast

Hitfilm 3 Pro, Windows 7, 16GB, i7 4770k 4Ghz, AMD 7950, 3GB, driver version 15.7.

I have a fractal noise texture being generated in another application and I import that file into HitFilm. An 800x800 Cineform AVI to be specific. I have a composite shot in  HitFilm which has this media as one of the layers and that comp is proxied.

When I update the AVI file with changes (fresh render from other app) and then open the project in Hitfilm, it does not invalidate the proxy for the comp containing the media file and keeps using the previous proxy.

I am manually removing and re-creating the proxy to workaround this issue.


  • Triem23Triem23 Moderator Moderator, Website User, Ambassador, Imerge Beta Tester, HitFilm Beta Tester Posts: 18,303 Ambassador
    edited August 2015

    The thing is, Hitfilm's project file is only using pointers to indicate media files (exception: 3D model geometry is stored in the hfp file. Textures remain pointers). By changing the media file, but giving it the same name and file location then opening Hitfilm, well, as far as it's concerned, nothing changed, so the proxy is valid. In general, it's uncommon to be making changes to a source media file mid-edit (the vast majority of imported media assets would be raw camera footage), and what you're describing is fairly rare (Although I have done it myself). 

    Hence, having to manually recreate the proxy. Eh, it's four mouse clicks. Not too big a deal. 

  • NormanPCNNormanPCN Website User Posts: 3,950 Enthusiast

    Three words... File date time.

    It's pretty simple to store and compare file date/times. I've been doing that for 30 years.

    Just because something is rare, does not mean it should be ignored. All I can do is inform them of a hole I fall into.

    The persistent proxy feature creates potential file dependency relationship(s). Something FxHome probably never thought would happen and Hitfilm is for the guy sitting in front of a computer and not a group environment.

  • Triem23Triem23 Moderator Moderator, Website User, Ambassador, Imerge Beta Tester, HitFilm Beta Tester Posts: 18,303 Ambassador

    I almost suggested file/date/time earlier, but was on a phone and in a hurry. I'm thinking, however, one would have to compare the file creation date, since moving a file changed it's "modified" date, in which case moving assets would invalidate proxies (Something I often do. I may start with a stock element in a library folder, then copy it to the project folder and relink once I know I'm keeping it.). In your specific example, if you overwrite the original file, do you get a new creation date, or just a modified date?

    You're on to a good idea, so forgive my questions. I just want to help you nail down the most logical way to approach this. Then we'll take it to the wishlist thread.

  • __simon____simon__ Website User Posts: 113 Just Starting Out


    @Triem23, are you sure moving changes the modified date? Seems like you might be doing more than just moving.

    If the file is changed while HitFilm has the project open then it should be a simple as registering for a change notification.

  • __simon____simon__ Website User Posts: 113 Just Starting Out

    On second thoughts, its not really a good idea to add implementation details to a feature request. Simply state what the requirements are and let the developers figure out the best way to do it.

    Is this really an item for the wishlist or a bug?

  • Triem23Triem23 Moderator Moderator, Website User, Ambassador, Imerge Beta Tester, HitFilm Beta Tester Posts: 18,303 Ambassador

    A Wishlist item, I think. As I argue above, the proxy system holds a proxy until a change ia made to the composite shot. Changing the file but having the same filename and location doesn't change the comp shot as far as Hitfilm is concerned. Because Hitfilm just uses a pointer to determine the file and in/out points to determine which parts of the file are used. Hitfilm doesn't know the file is changed. If Hitfilm is OPEN when the file is changed, Hitfilm unlinks the file from the media pool and invalidates the proxy, which requires the file to relink. 

    I suspect the system is working correctly as designed. 

  • RobinRobin Website User, HitFilm Beta Tester Posts: 1,671 Enthusiast

    The file date/time can be unreliable, as they can basically be changed by everyone, and as Triem said, doing some things to the file that don't alter its content still change those values. Or, depending on the program you're using, it might even make changes to a file but the dates are not updated. I think what @__simon__ suggests is probably the most reasonable way to go. Hashing the file content (with what every hash you want to use, doesn't really matter) is a way also used by many  version control systems to identify changes to files, and would make sense for this special case.

  • NormanPCNNormanPCN Website User Posts: 3,950 Enthusiast

    File date/time modification date is not modified by simply copying. Something needs to be written to a file. Of course a newly created file has the creation and modified date identical. 

    Yes, date/time is not 100%, but if a user (aka me) is going out of their way to alter file date times beyond what normally happens by opening, writing, creating and copying files then we must accept responsibility for any consequences of those actions. A hash or crc of file contents is going way over the top. This is not dire consequences such as bad/corrupt/altered data files used by the fault tree software used at a DOE regulated reactor. There one needs many levels of integrity and security. This is kinda the polar opposite.

    Hitfilm keeps files open while it is open, but its permissions are not preventing  copying over the top. They do prevent deleting. Hitfilm does detect a copy overwrite as I see the thumbnail in media change. I've not yet tested if that change detection propagates to a proxy.

    "the proxy system holds a proxy until a change is made to the composite shot"

    When a media file is a part of a comp, then a change in the media is by definition a change to the comp. Hitfilm may not be able to detect a media file change unless it is open. I strongly doubt that FxHome decided to knowingly not detect media file changes made while HitFilm is not open. IMO, they just implemented proxies and did not think about file dependency relationships that creates.

    Hey people re-create files and I have had friends give me an updated intermediate file on occasion. It happens.

  • AxelWilkinsonAxelWilkinson Staff Administrator, Imerge Beta Tester, HitFilm Beta Tester Posts: 5,242 Staff

    Do you have the option to "Close all media files when application is not active" turned on or off? When it is on, it will cause HitFilm to reload all media whenever to switch back to the interface, so any changes to the source files will be detected. If it is off, does it make any difference when you right-click on the media assed and Reload?

  • Aladdin4dAladdin4d Moderator Website User, Imerge Beta Tester, HitFilm Beta Tester Posts: 2,509 Enthusiast

    I have to go with @Robin on this one for a couple of reasons. The first is I do deal with collaborative projects and so I have no control over what others may or may not do. Different methods can generate different modification dates as can working across different platforms. This alone makes relying on file timestamps problematic at best and disastrous at worst. This kind of thing is why version control systems and their hashing methods exists in the first place. I'm not saying HitFilm needs version control but hash checking would be much more reliable. 

    The second reason is HitFilm is multi-platform and I could see (not saying it is as I don't really know) how implementing a hash check might actually be easier and provide a more unified experience across platforms than having to maintain separate file/date/time methods across both platforms.

This discussion has been closed.