Print at May 28, 2022, 8:07:40 AM

Posted by mazoola at Nov 25, 2015, 6:33:18 AM
Re: Suddenly, huge file size...
I returned home late last night, and one of the first things on my list for the morning was to see if I could simply delete the corrupted directories and the ContentDigests file from the .sh3d archive and have the plan load correctly. First, though, I wanted to check out a few models I'd built while I was away. (In advance of some podiatric surgery, I'd been helping a friend reorganize her home so all critical living functions would now take place on the ground level. In the evenings, I'd occasionally commandeer one of her PCs and refine some Sketchup modeling on which I've been working...)

The new designs appeared to work well, and after a couple of hours spent tweaking colors and textures, I thought I had the items reasonably well integrated into the home design. I decided I'd break for lunch and tackle the question of hand-editing .sh3d files afterwards. Before I stepped away from the keyboard, though, I hit 'save'...

...which suddenly seemed to be taking an awfully long time to handle the request. Sure enough, when the app finally returned control, my 78 Mb (compressed) plan had suddenly grown to 373 Mb (uncompressed). Inside the .sw3d file, I found item 315 now pointed to a folder containing an almost-complete copy of the plan, weighing in at 195 Mb.

Based on what I hope was an accurate reading of your previous post, I removed the offending file from the zipped plan, along with the entire ContentDigests. As expected, when I attempted to load the edited plan, sh3d responded with a warning the data file was invalid; while I could continue to load the plan, one of its furniture items would have to be removed or replaced with a placeholder object.

Unfortunately, as was the case last week as well, regardless of whether I choose to remove or replace the offending object, sh3d hangs. Last week I thought the process suspended and had to be cleared manually. This week, though, I saw it continued to perform at least some calculations, although the process's CPU utilization dropped to below 0.20%. I couldn't determine if the threads being executed were typical or correct for the application at that stage of invocation, or if they indicated the system had entered into an irrecoverable loop. In any case *I* didn't have the patience to wait a few hundred minutes to see if the system would eventually give me a welcome screen.

Once again, I couldn't identify the moment the corruption took place;. nor could I recall any unusual action I'd taken that could have introduced the error. I'm disappointed I still can't get the edited plan to load, as it means I most likely will have to hand-assemble a replacement plan by taking my most recent known-good file -- which is now three weeks' old -- and manually repeating each change since made. (Obviously, such an approach can only continue to work for me for a limited time.)

Again, any pointers or corrections most gratefully accepted!