On 20 November 2012 14:01, Tanu Kaskinen <[email protected]> wrote: > On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote: >> On Tue, 2012-11-20 at 17:59 +0000, Ian Malone wrote: >> > Thanks, I'll give it a go. I think handling the already_owner case in >> > reserve.c as well might be worthwhile since there may be other ways to >> > get to that state. >> >> I think it's a bug in the application if it calls rd_acquire for a >> device that it already owns. An assertion might be the way to go. If not >> an assertion, then at least an error. > > When writing that, I didn't realize that the current code already > returns an error if dbus_bus_request_name() returns > DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of > handling it, so in my opinion nothing needs to be done here. >
Okay I agree there is probably a more serious bug somewhere. I'll just point out that the current response does not result in an error in verbose output and that encountering that response results in removing the reserve method and handlers, meaning if the service isn't broken before it happens then it certainly is afterwards. Moving on: 0001-reserve-Call-change_cb-only-if-there-actually-was-a-.patch I think we might be getting somewhere. This doesn't actually fix the problem, the service without a reservedevice1/audioN method still gets produced (this is the use case of trying KDE audio properties), but playback doesn't work, so it may be doing something related to the problem: pulseaudio -v output, no patch: http://pastebin.com/yfGEu1qx pulseaudio -v output, patched: http://pastebin.com/HkjSST4p -- imalone http://ibmalone.blogspot.co.uk _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
