xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Custom Query (2683 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (49 - 51 of 2683)

Ticket Resolution Summary Owner Reporter
#986 fixed 0.15 client sound sporadically breaks Antoine Martin alas
Description

Testing with 0.15.0 and 0.15.6 client and server (osx and win32 clients, fedora 21 server, r-approximately at your releases of 0.15.0 & 0.15.6) I have been seeing (hearing?) sound sporadically breaking.

I haven't been able to find a reliable reproduction in terms of activity that induces it, but with a number of client machines I have seen it happening repeatedly for a while, then apparently stop doing so (haven't successfully narrowed down specific client circumstances inducing it though, it happens on a variety of client machines, while not happening to others on the same network, often repeatedly, despite those others running the same versions on similar or same OS).

In all cases, the client side has shown output similar to this:

2015-09-23 18:08:03,279 ignoring sound data with old sequence number 2 (now on 3)
2015-09-23 18:08:03,528 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x0800AAB0>), ready) on_sink_ready=<function sink_ready at 0x083274B0>
2015-09-23 18:08:03,529 sink_ready(()) codec=mp3
2015-09-23 18:08:03,700 sound_sink_exit() not the current sink, ignoring it
2015-09-23 18:08:03,701 sound_process_stopped(sink_subprocess_wrapper(None), ()) not the current sink, ignoring it

In one case the connection was over a vpn, in other cases the clients were on same local network as servers.

In the case over the vpn, which was recurring regularly, the client output also suggested a latency issue (failed to get xpra info):

2015-08-29 16:27:20,826 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x157f3070>), paused) on_sink_ready=None
2015-08-29 16:27:20,827 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x157f3070>), active) on_sink_ready=None
2015-08-29 16:27:26,583 unknown packet type: airgap-msg
Recv -  load_finished
2015-08-29 16:27:46,287 unknown packet type: airgap-msg
Recv -  load_finished
2015-08-29 16:32:46,916 re-starting speaker because of overrun
2015-08-29 16:32:46,917 stop_receiving_sound(True) sound sink=sink_subprocess_wrapper(<subprocess.Popen object at 0x157f3070>)
2015-08-29 16:32:46,918 stop_receiving_sound(True) calling <bound method sink_subprocess_wrapper.cleanup of sink_subprocess_wrapper(<subprocess.Popen object at 0x157f3070>)>
2015-08-29 16:32:46,919 stop_receiving_sound(True) done
2015-08-29 16:32:46,919 sound_sink_overrun() will restart in 0ms (server supports eos sequence: True)
2015-08-29 16:32:46,943 restarting sound sound_sink=None, codec=mp3, server_sound_sequence=True
2015-08-29 16:32:46,943 send_new_sound_sequence() sequence=1
2015-08-29 16:32:47,023 start_receiving_sound() sound sink=None
2015-08-29 16:32:47,025 start_sound_sink(mp3)
2015-08-29 16:32:47,025 starting mp3 sound sink
2015-08-29 16:32:47,096 mp3 sound sink started
2015-08-29 16:32:47,422 sound-sink internal error: write connection TwoFileConnection() reset: [Errno 32] Broken pipe
2015-08-29 16:32:47,423 sound_sink_exit() not the current sink, ignoring it
2015-08-29 16:32:47,425 sound_process_stopped(sink_subprocess_wrapper(None), ()) not the current sink, ignoring it
2015-08-29 16:32:47,546 sound_sink_exit() not the current sink, ignoring it
2015-08-29 16:32:47,612 server is not responding, drawing spinners over the windows
2015-08-29 16:32:47,694 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:47,695 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:47,695 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:47,740 ignoring sound data with old sequence number 0 (now on 1)


....

2015-08-29 16:32:47,846 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:47,863 server is OK again
2015-08-29 16:32:48,042 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:48,043 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:48,043 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:48,044 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:48,048 ignoring sound data with old sequence number 0 (now on 1)
2015-08-29 16:32:48,049 ignoring sound data with old sequence number 0 (now on 1)
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-08-29 16:32:49,596 the sound-sink process has failed to start, stopping it
2015-08-29 16:32:49,987 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x19f43a10>), ready) on_sink_ready=<function sink_ready at 0x157f8830>
2015-08-29 16:32:49,987 sink_ready(()) codec=mp3
2015-08-29 16:32:50,130 the mp3 sound sink has stopped
2015-08-29 16:32:50,131 stop_receiving_sound(True) sound sink=sink_subprocess_wrapper(None)
2015-08-29 16:32:50,131 stop_receiving_sound(True) calling <bound method sink_subprocess_wrapper.cleanup of sink_subprocess_wrapper(None)>
2015-08-29 16:32:50,132 stop_receiving_sound(True) done
2015-08-29 16:32:50,135 sound_process_stopped(sink_subprocess_wrapper(None), ()) not the current sink, ignoring it
2015-08-29 16:32:50,213 speaker is now disabled - dropping packet
2015-08-29 16:32:50,279 sound_sink_exit() not the current sink, ignoring it

In one case rebooting the client caused the problem to stop (failed to get an xpra info in time for that case too). The logs were essentially the same as above, but without the server is OK again message... probably because there weren't the same latency issues, since it was on the same network as the server.

In another case the same error messages seemed to be appearing, accompanied by a stuttering of the sound... but the sound seemed to restart successfully after a second or two (I'll attach an xpra info from this case). In this case, the client output was:

2015-09-23 18:21:48,025 re-starting speaker because of overrun
2015-09-23 18:21:48,058 stop_receiving_sound(True) sound sink=sink_subprocess_wrapper(<subprocess.Popen object at 0x0800AAB0>)
2015-09-23 18:21:48,059 ignoring sound data with old sequence number 3 (now on 4)
2015-09-23 18:21:48,125 stop_receiving_sound(True) calling <bound method sink_subprocess_wrapper.cleanup of sink_subprocess_wrapper(<subprocess.Popen object at 0x0800AAB0>)>
2015-09-23 18:21:48,233 ignoring sound data with old sequence number 3 (now on 4)
2015-09-23 18:21:48,233 stop_receiving_sound(True) done
2015-09-23 18:21:48,233 sound_sink_overrun() will restart in 0ms (server supports eos sequence: True)
2015-09-23 18:21:48,233 ignoring sound data with old sequence number 3 (now on 4)
2015-09-23 18:21:48,234 ignoring sound data with old sequence number 3 (now on 4)
2015-09-23 18:21:48,242 restarting sound sound_sink=None, codec=mp3, server_sound_sequence=True
2015-09-23 18:21:48,243 send_new_sound_sequence() sequence=4
2015-09-23 18:21:48,243 start_receiving_sound() sound sink=None
2015-09-23 18:21:48,243 start_sound_sink(mp3)
2015-09-23 18:21:48,243 starting mp3 sound sink
2015-09-23 18:21:48,252 mp3 sound sink started
2015-09-23 18:21:48,575 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x0832A0D0>), ready) on_sink_ready=<function sink_ready at 0x08327AB0>
2015-09-23 18:21:48,575 sink_ready(()) codec=mp3
2015-09-23 18:21:48,736 sound_sink_exit() not the current sink, ignoring it
2015-09-23 18:21:48,737 sound_process_stopped(sink_subprocess_wrapper(None), ()) not the current sink, ignoring it
2015-09-23 18:21:49,249 sound-sink using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2015-09-23 18:21:49,263 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x0832A0D0>), paused) on_sink_ready=None
2015-09-23 18:21:49,265 sound_sink_state_changed(sink_subprocess_wrapper(<subprocess.Popen object at 0x0832A0D0>), active) on_sink_ready=None
2015-09-23 18:21:49,369 sound_sink_exit() not the current sink, ignoring it

In a number of other cases, there was no -d sound set and there was no sign of any other errors than the sound-sink internal error: write connection TwoFileConnection() reset: [Errno 32] Broken pipe which I have been seeing periodically but generally with no ill effect.

#860 fixed 0.15.0 client tracebacks on disconnect, if Session Info has been opened Antoine Martin alas
Description

Testing with a win32 0.15.0 r9365 client against a 0.15.0 r9365 fedora 20 server...

When I end a session with a control-c client-side, I am sometimes seeing a traceback - first started appearing with XPRA_OPENGL_PAINT_BOX=1 set while testing #760... but when I set paint box=0 to test if that was the cause, I stopped seeing it... and then when I re-set to =1, it was no longer appearing there either (?).

Ahh... mystery solved - the traceback seems to only show itself if I open the Session Info at some point (even if I close it before ending session) before disconnecting.

If I end session with control-c I get this traceback:

2015-05-14 17:32:14,184 received console event CTRL_C
Traceback (most recent call last):
  File "xpra\client\gtk_base\gtk_client_base.pyc", line 83, in quit
  File "xpra\client\gtk2\client.pyc", line 127, in cleanup
  File "xpra\client\gtk_base\gtk_client_base.pyc", line 95, in cleanup
AttributeError: 'NoneType' object has no attribute 'destroy'

If I grab the session to another device, I get this:

2015-05-14 17:06:04,526 server requested disconnect: new client (this session does not allow sharing)
2015-05-14 17:06:05,213 Connection lost
Traceback (most recent call last):
  File "xpra\client\client_base.pyc", line 405, in _process_disconnect
  File "xpra\client\client_base.pyc", line 386, in warn_and_quit
  File "xpra\client\gtk_base\gtk_client_base.pyc", line 83, in quit
  File "xpra\client\gtk2\client.pyc", line 127, in cleanup
  File "xpra\client\gtk_base\gtk_client_base.pyc", line 95, in cleanup
AttributeError: 'NoneType' object has no attribute 'destroy'

One last bit of testing shows that I'm getting the same traceback with OSX clients (same build/revision).

#873 fixed 0.15.0 server throwing thread parse exception alas alas
Description

Running an osx client 0.15.0 r9533 against a fedora 20 0.15.0 r9533 server, running a video on firefox to test various things, the server threw the following exception:

2015-05-27 17:58:48,509 sound-source codec: MPEG-1 Layer 3 (MP3)
Exception in thread parse (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
  File "/usr/lib64/python2.7/threading.py", line 764, in run
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 610, in _read_parse_thread_loop
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 572, in _internal_error
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'error'
2015-05-27 18:05:42,354 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-05-27 18:05:42,707 sound-source codec: MPEG-1 Layer 3 (MP3)

The client showed a couple of sound-sink errors, meanwhile: sound-sink internal error: write connection TwoFileCOnnection() reset: [Errno 32] Broken pipe ... which I think we've been seeing for a while, but no other interesting information.

Note: See TracQuery for help on using queries.