Processing hangs at Compressing all.zip

#1

I have had pretty good luck with ODM for a few months on my server but recently I have had a number of failed tasks because ODM appears to hang at the ‘Compressing all.zip’ stage. I have also used the Lightning network and had similar results. This is happening whenever I add GCPs to the dataset to be processed.

I am using WebODM through Docker on a Dell R710 and only recently started having issues after an update about a week ago. I can see a Celery job running when it gets stuck but even after waiting several hours it fails out.

The test images I am using have been only about 120 images or less. My server has approximately 1TB of storage remaining and 80 GB of RAM available for ODM to abuse as necessary.

I am also not sure if it’s related but the elapsed processing timer also gets stuck when it reaches this stage. If I refresh the page when it reaches the compressing stage, the timer resets to the elapsed time at which it began the compressing stage.

Terminal output:

conversion finished 
55,569,731 points were processed and 55,569,731 points ( 100% ) were written to the output. 
duration: 383.984s 

Postprocessing: done (•̀ᴗ•́)و! 

Compressing all.zip

I have tried updating everything a couple times and still have had no luck. My next step will probably be to remove everything and reinstall from scratch but I don’t know how effective that will be. I will upload the dataset to a drive when I get a chance.

Here are some related threads which I have looked at but not found an effective solution from:


0 Likes

#2

Hey @RyanF :hand: could you share your dataset images and GCP file with us?

1 Like

#3

Yep! I’ll get it uploaded sometime over the next couple days. Google drive runs slowly when uploading large amounts of data.

0 Likes

#4

Actually scrap that. I already have it on my drive and just had to move it to the shared folder. You can find the dataset here:
https://drive.google.com/drive/folders/1ghpCsdAoc02VtgxjXmJDyvCWVGhEIJph?usp=sharing

1 Like

#5

Will test in the next few days and report my findings here.

0 Likes

#6

First thing I noticed: EPSG codes are not supported.

EPSG:6345

Have you tried using proj4 instead?

+proj=utm +zone=16 +ellps=GRS80 +units=m +no_defs 

https://docs.opendronemap.org/using.html#ground-control-points

0 Likes

#7

I was screwing around with it a lot earlier and it accepted the EPSG code in ODM. I couldn’t get it to process with proj4 so I instead converted to EPSG when going from the GCP interface to the ODM processing interface

0 Likes