- Uređeno
Local files hang during network instability (3.8.x)
Hi all,
We're having problems at the office here with our intranet and seemingly all Spine animators are having problems with software hanging despite making absolutely certain that all image folders and files are directing to local drives only. There don't seem to be any CPU spikes in Task Manager and all other computers in the studio have no such problems with local files when using Maya/Photoshop/Unity and more.
Only Spine has problems with working locally despite having no files being used on the network. Is there a chance that perhaps Spine is looking to old paths or networks intermittently?
This slowdown on our end could potentially last weeks due to parts awaiting order as it's already lasted a week longer than expected and it's really effecting our animation pipeline at a critical time.
Is there any chance we could ask for some troubleshooting or a solution with 3.8.99?
Thank you!
Edit: A notable freeze of about 15-20 seconds happens rather reliably when clicking the Spine menu in the top left
Edit2: Just to be clear, this freeze is not limited to clicking the menu. It happens with many regular things like animating and setup changes. We're also aware of the freeze that happens that require you to save the file before things continue to work as expected. These hanging software network issues are neither of those.
Can you please try 4.0? Many, many improvements have been made there. Even if you can't use 4.0 yet, it would be good to know if the problem is resolved.
Have you looked at both the images path AND the audio path? The audio path defaults to blank and people who don't use audio often ignore it, which is fine. However, blank resolves to the folder that the project file is in, so Spine will watch that folder and subfolders in case there are any audio files. If your Spine project file is on a network drive, that could be the reason Spine is reading the network drive.
If your Spine project file, images folder, and audio folder are all on the local drive, Spine should not be using the network drive from old paths for the purposes of working on the project. Spine does write to the user folder and the temp folder, but these should be local. When the main menu is shown, Spine does check that the recent files paths are valid, so this could be the reason you see slowdown. Spine does remember old paths for recent files. To clear your recent files, delete the recent.json file in the Spine user folder:
Spine Troubleshooting: User files
stikkanimate wroteWe're also aware of the freeze that happens that require you to save the file before things continue to work as expected.
We aren't aware of such a freeze! Spine should not freeze like that.
Maybe there is something that can be configured with the way you have setup network drives? I'm not familiar with them, except that they have been a common source of complaints. A network drive that gives a 15+ second pause is unreasonable.
Thanks Nick,
Unfortunately, we can't go to 4.0 - We're too close to release with our current project and can't risk adding bugs - also our freelancers use 3.8.86 (and we can't get them to update even to 3.8.99, they literally just ignore us)
Also, everything I've mentioned here are tested with files and folders that are exclusively on a local machine but were previously copied from the network.
As of today, it's been determined we had a failing drive on the network that was leaving any Explorer searches and softwares hanging. That still didn't explain the Spine-specific freezes though. We've just gotten our network fixed and the freezes have stopped so I can't test it currently but perhaps the recent files list is what does it.
Thanks for the help, Nick!
Dang, Nick got all the credit! 
Good the freezes have stopped, whatever the cause!
We'll see if we can improve the recent files behavior. Maybe we don't need to check files that aren't found as often.
Oh sorry Nate hahah. We have a programmer named Nick at work. I crossed wires and need debugging on my own brain.
Also, it is the recent files list that did it! We were having maintenance on the server one last time and it was effecting us again. Tried deleting recent.json and all was fine.
Haha, no worries!
stikkanimate wroteit is the recent files list that did it!
It makes sense: Spine doesn't want to show recent files that you can't actually open, so it checks if they exist. Spine continues to remember such files, because sometimes you move files and later move them back, so it's nice that you don't lose all your recent files just because Spine happened to find they don't exist once.
A network drive shouldn't take multiple seconds just to determine a file doesn't exist, but there's nothing we can do about that problem.
For a fix, we could detect how long it took to check if a file exists. If it takes longer than some threshold, we could just delete the recent files entry. You'll still get the network drive delay, but at least it will only happen once. We've done this in 4.0.03.