xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#1003 closed defect (fixed)

server control channel isn't re-starting sound-output after stopping

Reported by: alas Owned by: alas
Priority: minor Milestone: 0.16
Component: server Version: 0.15.x
Keywords: Cc:


Testing with osx client 0.16.0 r10828 against a 0.16.0 r10786 server, I happened to use the server control channel to stop sound-output, but when I immediately tried to start it again, there was a message that "None" had been started.

[tlaloc@jimador ~]$ xpra control :13 sound-output stop
X11ServerSource(Protocol(tcp socket: <- : stopped
[tlaloc@jimador ~]$ xpra control :13 sound-output start
X11ServerSource(Protocol(tcp socket: <- : started None
[tlaloc@jimador ~]$ xpra control :13 sound-output resume
X11ServerSource(Protocol(tcp socket: <- : unknown sound action: resume

The stop command worked as expected, stopping the sound. The start, on the other hand, did as it said and started nothing.

I also tried "resume", in case I was just remembering wrong... but looks like not so much.

Change History (5)

comment:1 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

If you look at your server log (and you always should do that), you would have seen and reported:

Warning: invalid codec specified: None

You needed to specify which codec you want to use, ie:

xpra control :13 sound-output start vorbis

r10840 will choose one for you if you don't specify one, so this will now also work:

xpra control :13 sound-output start
Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 3 years ago by alas

I'll see about testing that shortly - but I had my sound apparently break leaving a session run overnight. I tried the speaker on/off (well, technically off/on) to see about restarting and got the following traceback (seems like it might be related to this ticket)

Traceback (most recent call last):
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 792, in check_enabled
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 731, in spk_on
TypeError: start_receiving_sound() takes exactly 2 arguments (1 given)

(Yes, I'll re-test that as well, just wanted to make the note before I lose it.)

comment:3 Changed 3 years ago by Antoine Martin

Good catch!

This should be fixed in r10860.

How did it break? What were the messages? (and should we be re-starting it?)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 3 years ago by alas

Resolution: fixed
Status: newclosed

The server control channel speaker-output start is working again as of 0.16.0 r10922 OSX client and 0.16.0 r10916 fedora 21 server.

I'm not sure how it is breaking exactly... I can only repro by leaving sound running in an idle session over night - but I see absolutely no output server side during the idle period, and the only thing I see client side is the periodic (every 20 seconds it looks like) message on an OSX client that the UI thread is blocked/running.

I do see an occasional message or two, in the middle of the night, about spinners on the client side:

2015-10-22 10:27:26,671 server is not responding, drawing spinners over the windows
2015-10-22 10:27:32,214 server is OK again

... which I suspect to be related.

Perhaps a patch for a client that will output audio status after recovering from a spinners episode? (In the meantime, I'll see if I can't spot, though -d sound logs for a 6-8 hour stretch are a daunting prospect... I might try though with a grep for the spinner message and search the nearby vicinity?)

All that aside, I will close this ticket, and open another regarding what's toggling the sound off if I manage to pin it down.

comment:5 Changed 3 years ago by Antoine Martin

Note about the sound turning off: the "server is OK again" message comes 6 seconds after the "not responding" message, which is longer than has been reported elsewhere. It could be a network drop out, maybe some service being restarted overnight? Does it happen always around the same time? This should be tracked in #855.
Packet delays should not cause the sound to stop.
There is one thing that can cause the sound process to stop without logging a message: if it gets killed. This could happen if the OS decides to kill it, for example if it uses too much memory.

See also #986

Last edited 3 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.