these are very rare but we should still do the right thing.
In this case, there was a bug in the codec's C code and it bombed out, IIRC it took the whole server with it but left the vfb running...
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server_source.py", line 1049, in data_to_packet encode_and_queue() File "/usr/lib64/python2.7/site-packages/xpra/window_source.py", line 624, in make_data_packet packet = self.make_data_packet(*data) File "/usr/lib64/python2.7/site-packages/xpra/window_source.py", line 755, in make_data_packet data, client_options = self.video_encode(wid, x, y, w, h, coding, data, rowstride, options) File "/usr/lib64/python2.7/site-packages/xpra/window_source.py", line 868, in video_encode self._video_encoder.init_context(w, h, self.encoding_options) File "codec.pyx", line 207, in xpra.x264.codec.Encoder.init_context (xpra/x264/codec.c:3146) File "codec.pyx", line 187, in xpra.x264.codec.Encoder._get_profile (xpra/x264/codec.c:2611) ValueError: unsupported format character 'S' (0x53) at index 11
actually, we can't do anything about this: we can't just encode a dummy frame to test the encoder, and if something crashes after the initial setup we should leave the vfb running so that it can be salvaged.
Note: we handle this in 0.16 a lot better: most of the codecs have selftests which will catch those errors and disable the codec. (see also #948)
fix milestone: selftests were added during the 0.15.x milestone, ie: r8264 for enc_x264.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/240