Xpra: Ticket #240: early startup errors should not leave a vfb behind

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


Thu, 18 Apr 2013 13:43:50 GMT - Antoine Martin: status changed; resolution set

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.


Sat, 24 Oct 2015 05:00:01 GMT - Antoine Martin:

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)


Mon, 25 Apr 2016 10:32:34 GMT - Antoine Martin: milestone changed

fix milestone: selftests were added during the 0.15.x milestone, ie: r8264 for enc_x264.


Sat, 23 Jan 2021 04:49:20 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/240