Does "Ch Data" need backing up?

[alank99101739]

My "Ch Data" directory is now 1.9GB in size. I am trying to use Adobe Cloud to backup my project files, but I don't really want to use 1.9GB of storage if this just contains scratch files. I set media encoding to use a different directory for temporary files (so temp files are not uploaded to the cloud). Does "Ch Data" need to be backed up? If not, is there some other setting to move Ch Data outside the project so I can use Adobe Cloud to backup my project files and nothing else? Thanks!

[Dan Ramirez]

The Ch Data folder contains most of your project(footage and recordings will be in Ch Media). Within Ch Data, temp.noindex contains temporary files that CH can rebuild. repo.noindex is absolutely essential.

1.9gb sounds really really large though. Any chance you're saving footage or exports into that directory?

[alank99101739]

I am not exporting clips or anything to that directory. Its all generated by Adobe.

So its sounds like a product feature request would be to allow the generated temp directory to be kept someone other than the project, so I don't waste my Creative Cloud disk space allocation (and upload bandwidth) on temp files.

The temp.noindex directory seems to mainly come from the "textures" directory, which is lots of images files of all the different parts of the artwork of the puppets.

$ du -h temp.noindex/

633M    temp.noindex/compiler/sources/textures

738M    temp.noindex/compiler/sources

738M    temp.noindex/compiler

114M    temp.noindex/WarpCache

852M    temp.noindex/

Browsing the directory it seems like there are lots of duplicate files in there (different file name, same image).

But there are also lots of tempNNNN.noindex/ directories. Can I safely delete these? Can I recover disk space by deleting the temp.noindex directory as well?

$ du -hs *

39M     repo.noindex

852M    temp.noindex

20M     temp10104.noindex

17M     temp13384.noindex

18M     temp13816.noindex

13M     temp13884.noindex

14M     temp13904.noindex

12M     temp14768.noindex

14M     temp15212.noindex

20M     temp16048.noindex

28M     temp18716.noindex

8.0M    temp21552.noindex

18M     temp21572.noindex

16M     temp21584.noindex

14M     temp21752.noindex

18M     temp21784.noindex

13M     temp21884.noindex

17M     temp22064.noindex

11M     temp22448.noindex

14M     temp22984.noindex

14M     temp23436.noindex

185K    temp25044.noindex

19M     temp25944.noindex

14M     temp26464.noindex

16M     temp26896.noindex

13M     temp30512.noindex

13M     temp3852.noindex

21M     temp46640.noindex

18M     temp48184.noindex

20M     temp5000.noindex

28M     temp57584.noindex

15M     temp57608.noindex

18M     temp60768.noindex

21M     temp60800.noindex

15M     temp61288.noindex

15M     temp61648.noindex

16M     temp61664.noindex

21M     temp61728.noindex

24M     temp63072.noindex

18M     temp63128.noindex

18M     temp63480.noindex

15M     temp63572.noindex

15M     temp63668.noindex

15M     temp64024.noindex

5.2M    temp64312.noindex

16M     temp65844.noindex

16M     temp66284.noindex

19M     temp7104.noindex

13M     temp9100.noindex

18M     temp9876.noindex

Thanks!

[Dan Ramirez]

"Can I recover disk space by deleting the temp.noindex directory as well?"

The entire temp.noindex folder can be safely deleted. Of course, if you open the project, it will be regenerated exactly where it was. Doing a "Save As" will basically do the same thing and that's how we'd recommend users create a copy of their project without extra temp files.

You do raise an interesting point about whether or not we should eventually add an option to put these temp files in a cache directory somewhere. Other Adobe apps do this with other types of media cache files.

Feel free to contact me directly if you'd like to be included in our private beta. It sounds like your use of the app stresses the app more than most, so if you'd like to be in more direct contact with the dev team, that might be a good option.

Thanks,
Dan R.
CH QA

[Dan Ramirez]

By the way, I clearly didn't read your last email clearly enough.

The vast majority of the time, there should be only one temp.noindex folder. Copies can and will be created so Dynamic Link can send a scene to AME/AE/PR without being interrupted. These copies should go away if you're no longer using DL.

So the short answer is you can safely delete any of those temp.noindex folders. The long answer is you might have a situation where these folders are persisting after they should be cleared by our processes. If that's the case, it would be great for me to be able to reproduce.

For me, these "extra" folders get cleaned up when I close AME(or any other DL client).

Dan R.
CH QA

[alank99101739]

I have had lots of Ch crashes, which is where I suspected they came from. I might just delete them all and see if they come back over time. But I will leave that for another day in case you want to poke around. (But I suspect not worth your time – I think just unclean exits of Ch left files behind).

Alan

Sent from Mail for Windows 10

[sabrinab89401184]

Same thing here.

Though a little larger (around 8 gigs)

it was from a series of puppets (7 pupets) where every time I created a new puppet, I copied the puppet folder and just replaced the actual footage in the psd files. The psds are quite large though (upt to 2 gigs).

During the creation I experienced a lot of pseudo crashes (5-8 minutes of loading time on an ok machine).

But I never shut down Ch - so "unclean" exits wasn't a thing with my project.

[alank99101739]

2GB for a PSD file!  Do you think that is because the PSD file is very high resolution? Or just very complex?  (I normally use Illustrator. I was curious to see if there was any performance implication of PSD vs AI files - e.g. are high res PSD files slower in CH, because they are so large? Useful to understand if so.)

[sabrinab89401184]

it's not all that complex but with rather high resolution.

Ch (and Ae or Pr) need very long (around 5-8 minutes, I kid you not) to load a puppet. I think that's the main problem with large files. But afterwards the performance is ok. But I think surely more render-time is needed with higher resolution.