xpra icon
Bug tracker and wiki

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

Opened 6 years ago

Closed 6 years ago

Last modified 11 months 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 (6)

comment:1 Changed 6 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 6 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 6 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 6 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 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 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 6 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?
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

Version 1, edited 6 years ago by Antoine Martin (previous) (next) (diff)

comment:6 Changed 11 months ago by migration script

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

Note: See TracTickets for help on using tickets.