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

[totaam]

Issue migrated from trac ticket # 1003

component: server | priority: minor | resolution: fixed

2015-10-15 02:50:36: afarr created the issue

---

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: 10.0.32.136:2200 <- 10.0.11.153:52981)) : stopped
[tlaloc@jimador ~]$ xpra control :13 sound-output start
X11ServerSource(Protocol(tcp socket: 10.0.32.136:2200 <- 10.0.11.153:52981)) : started None
[tlaloc@jimador ~]$ xpra control :13 sound-output resume
X11ServerSource(Protocol(tcp socket: 10.0.32.136:2200 <- 10.0.11.153:52981)) : 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.

[totaam]

2015-10-15 05:31:49: antoine changed owner from antoine to afarr

[totaam]

2015-10-15 05:31:49: antoine commented

---

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

[totaam]

2015-10-15 18:26:24: afarr commented

---

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.)

[totaam]

2015-10-16 03:27:41: antoine commented

---

Good catch!

This should be fixed in r10860.

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

[totaam]

2015-10-22 18:32:44: afarr changed status from new to closed

[totaam]

2015-10-22 18:32:44: afarr set resolution to fixed

[totaam]

2015-10-22 18:32:44: afarr commented

---

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.

[totaam]

2015-10-23 05:27:10: antoine commented

---

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