Cannot Save if Video is added to the Stage on Networked Server

1

Up until recently I have been using a NAS drive to save all of our HYPE work to with no problems at all. Our IT department has just upgraded our servers from this to a more robust windows server. All seemed to be going well until a video file was added to a HYPE project and the file refused to save. Below is a scenario whereby the error occurs:

Step 1:
Open a new Hype project and save the file into a folder on the Server. Make a change by adding text, images, code etc. and Save, The file Saves OK.

Step 2:
Close the file then reopen it, make changes and save, no problems.

Step 4:
Add a video file to the stage, a visual timeline is created for the video, Save file, no problems.

Step 5:
Make a change and save, no problem.

Step 6:
Close the file and reopen it again, Save, and I get the following error:
The document “xxx.hype” could not be saved. The file is locked.
Do you want to save your changes to it anyway?

By clicking ‘save anyway’ give me another error which doesn’t let me save:

Also by leaving the file open for a few minutes I get a third error which a presume is from the autosave feature:

By Removing the offending video file the Hype file stays permanently ‘Locked’ not allowing me to save ever again.

Now it would be good to note that if I had added my video file to the ‘Resources’ folder and not add it to the stage than I can still save the file as much as I like, close it reopen it save, no problems. As soon as I add it to the stage I can no longer save the file.

Everything this works as expected on my local HD and NAS drive.

I am presuming this problem has something to do with the persistent storage but why only when a visa is added to the timeline? My IT department has tried everything changing file permissions etc but could find no solution.

Any help solving this problem would be much appreciated, IT are willing to speak directly to someone to get this sorted if possible.

Thanks
Darren

1 Like
2

Can you select ⌘ + i when you have your video selected and see what the permissions are listed as? If ‘Everyone’ is not set as ‘Read & Write’ can you adjust that?

3

Hi Daniel, Thanks for your response.

Do to the nature of the server the permissions for all files are set for ‘read only’ on ‘everyone’, 777 is not allowed.

All users of the server have their own permissions that are set to ‘Read & Write’. However, we have run a few tests where we reset ‘everyone’ to ‘Read & Write’ and the error still persisted. Even changing permissions on the the file and all resources included in the package after it had been saved still produced the error.

Just to reiterate, the problem with saving the hype file only happens if the video has been added to the stage / timeline.

5

Is there any way of disabling versioning of file saves on the software in order to work around this problem?

6

You can manually disable version control for Hype by following these instructions: http://apple.stackexchange.com/a/52390

The command for Hype would likely be:

defaults write com.tumult.Hype2 ApplePersistence -bool no

You may also want to turn on ‘Ask to keep changes when closing documents’ in System Preferences > General as well.

7

Thanks for this, unfortunately after implementing both of these fixes I still can’t save the file once a video has been put onto the stage and a timeline has been drawn. I only get this error with video.

8

I have the same issue and have had no luck with the solutions provided. Is there a way round this? Currently we have to duplicate the document and re-save it under a new name. This is no way to work and we are in the same situation where we require our files on a network server for ease of access.

Thanks in advance.

9

Can you perhaps send a link to the video, your .zip document, and also let me know what protocol you are using to connect to the NAS?

It’d also be useful if you can report this via the ‘Help > Report an Issue…’ dialog, as this will also capture some logs that might be useful. Thanks!

12

Hi all,
I recently got this error today as well. Has there been a working solution provided for this?
My file kept trying to autosave and as it couldn’t it kept creating folders in the .hype files directory and eventually corrupted my hype project (it disappeared).

On the plus side I got to use the “Restore Document From Export” feature which worked a treat! Still have to duplicate and rename the file to get ahead though, every time. Which is quite annoying.

I could not tell you what our server set up is unfortunately.

Cheers,

13

Sorry, the current best workaround if you encounter this issue is to save locally to your system volume. We’re working on a fix.

14

Hi Jonathan,
Thanks for your reply.

As long as you aware! I look forward to a fix

Kind regards

15

Hi all,

Anything new about this issue with video? I am having the same problem here, and I can see this thread is kinda old.
Thank you

16

Hi, We are still having this problem with this even though we have switched from a windows server to a Linux one, However there is one thing you can try that half works for us.

This problem seems to be worse when connecting via SMB, so try AFP instead. There are other issues with AFP but at least this is a start.

17

Hi Darren,
Thank you for the follow up. This is good to know and may help others, unfortunately, we are always connecting using AFP here with the help of Acronis/ExtremeZ. Keep us posted on updates.
Regards.

18

Hi Alexandre

This problem does seem to be inconsistent over different NAS set ups. Recently we where running a windows server and both AFP and SMB resulted in failure if a video file was inserted in to a HYPE file.

We have recently switch to a Linux NAS setup and here are the differences when connecting to it.
SMB - Saving a HYPE file is very fast unless it contains a video then it will not save at all.
AFP - Saving a HYPE file even with video works however it it very slow. i.e. a new blank file that would save instantly on the local drive is taking take approx 15 seconds on the NAS. The more that is then added to the HYPE file, the slower the save becomes. I recently opened a small project with a couple of video files and a small amount of graphics and the save took around 1 minute 20 secs.

I have also recently tested a small WD NAS BOX with the same results as the very large Linux Server.

As we need our HYPE projects on a shared space due to several people accessing them, we now fileshare to a spare mac which so far has no issues.

Cheers
Darren

19

What is the MacOs you are using and Is in smb protocal the server and Mac are using.

In Terminal.app you can see in part from your end

smbutil statshares -m /Volumes/sharemountPoint

Also check with your IT want waht the servers are supporting.

On Sierra I have had problems with SMB 2 & 3 and had to revert to 1.
But that came with issues that where a problem. Like files being locked for now apparent reason.
On High Sierra I was able to go to SMB 3. Some small issues but none of the locked file annoyances

20

Hi Mark, I have a bit of time today so I am going to run a few more tests on the NAS drives.

First off, I am using Sierra, we’ve been told by our IT company to hold of upgrading to High Sierra for the moment but if I can get hold of spare mac in the next few days I will upgrade it.

Here is the smbutil console log for our main Linux NAS (I don’t control this Server):
SERVER_NAME xxx
USER_ID xxx
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
CLIENT_REQUIRES_SIGNING TRUE
FILE_IDS_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE

And for my small WD NAS box (I have full control of this Box):

SERVER_NAME xxx
USER_ID xxx
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_2.1
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
CLIENT_REQUIRES_SIGNING TRUE
FILE_IDS_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE

21

On the Linux v3 and the WD v3

But both on Sierra which was flaky for me with smb 2-3

Be interesting to see what smbv3 is like for you on High Sierra which in the end has worked best for me.

22

I’ve managed to upgrade my mac to High Sierra and can report that there is no change to the situation at all.

SMB - Hype files with Video is still reporting as locked, this occurs on SMB1, SMB2 and SMB3
AFP - All Hype files save but take a very long time, unusably so. And in addition each save leaves behind a duplicate empty package folder:

23

Darn, It was worth a shot… shame it was not that simple for you…

Thats interesting that afp is leaving these empty folder… I wonder if they are for temp writing of the files in place of overwrite.