And just for some background:
I started seeing some bad compression (horribly pixelated results) when I tried to replace the texture in question, which was already compressed. I attempted to re-compress it, but I may have run into this issue. (My work-around was to delete the texture, re-upload it, and then rebuild the material.)
Some of our users hit the compression machines with absolutely huge textures and this brought them down. We’ve implemented texture size restriction for now (limit is 4096x4096) and restarted things though, so please try again.
Ok, so this problem is a bit different than it was previously.
I can start new compression jobs, and they finish OK. However, the batch that was running, and incomplete, is now “in limbo”. I have to uncheck all the boxes, click ‘compress’. Then re-check the boxes, and click ‘compress’ again. This seems to restart the job, but the compression job doesn’t get any further than it had. So, for the file in the image above, I can only get the DXT compression to run.
Sorry you had to work around it in a painful way. The reason I asked about the dimensions of the textures was due to a limit we recently placed on the backend to prevent excessive load on the compression pipelines.