Ok, let me try to separate the many things you have asked!
First of all, I assume you have not modified the .ac files I've tuned. They were: hst.ac, SPARTAN-201.ac, TDRS_demo.ac and rmsArm.ac. If yes, be very careful, any change of scale, or origin, will destroy the tuning. If in doubt, try back the original files to see if this is the cause of the problem. Also, I've added texture files for SPARTAN and TDRS, the one giving the target on the grapple fixture!
If you want, I can put the blender files somewhere to update your repository of 3D objects. Notice that you can already add the grapple fixture:
https://curl.irmp.ucl.ac.be/~chris/upload/fg/ss/grapple_fixture/1) Catching Hubble.
The active grapple is the one closest to to the RMS arm when HST is in the payload bay. With the RMS view, ensure that you have the grapple fixture target and stick just in the middle of the view! In other words, the end effector X,Y,Z should be around
X=7.8
Y=0.75
Z=0.10
and it should have an attitude close to:
P close to 90 deg (this is Euler), so realistically should be 82-84 degrees.
Y = 0
R = 180 (mind the roll!!!)
2)
"The arm eventually also disappeared"
I suspect you mean, from the SRMS view, in some attitude the arm becomes translucent whereas it is still visible in other views. I've seen that too and interpreted it as some openGL clipping conditions being triggered. I don't know what can trigger this as the view is always out of the arm. Maybe some rough approximations made by the graphic drivers induce this effect (I've seen this before with the "red cut" in Earthview). This one is tricky to solve as being really at the graphic level.
3)
Also after all the extreme angle rotations and translations the CCTV model or the view or the arm or any of the 3 are not at the original alignment.
This can happen only if you pass over the Euler singularity, I mean you push the pitch larger than P=90 degrees and move the arm back in the bay by yawing at more than 180 degrees. If you have done so, yes, I expect the alignment to be broken. But if you go back to P < 90 degrees and Y < 180, you should recover the original state.
4)
After straightening out all the angles of the RMS arm I got both the arm model and the CCTV overlay model to be visible again but froze one of the joints.
Here, I suspect this is not Euler at all [Euler is point 3) above] but you have reached the STOP of the RMS. The joint angles have software stop limitations (as coded in our Shuttle and also in reality).
If you reach one of them, you cannot move the arm anymore. You should take SINGLE mode and move the offending joint angle back to an allowable value. For instance, if you have pushed the elbow too deeply in its "unnatural position" , you have to reduce its angle value for a while to make it functional again. To be more specific, internally, that angle assumes a value, let's say 200 degrees. You have to reduce it to 180 degrees to start seeing the elbow moving again. But while you're reducing its value, nothing is happening (unless you monitor the property tree), which can be very confusing and disturbing. Also, if you make a mistake and increase its value to values larger than 200 degrees, the elbow will remain locked and it is very likely that you'll never be able to unlock it again. Within the payload specialist view, a talkback indicates "STOP" when this is happening.
In conclusion, 1) and 4) should be no problem, but 3) being Euler is likely to be unfixable! Concerning 2), that should be fixable, but we need to understand more what triggers this graphic clipping of the close object.
Let me know how it goes!