Kodi Community Forum

I've been investigating a sporadic issue I noticed while using the airplay component in xbmc 13.1. One out of every three or four attempts to stream from an airplay client silently fails (I repro'd this on a multi-core x86_64 linux box). I tracked this down to a race condition between the thread running DVDDemuxBXA and the thread receiving callbacks from libshairplay.

In short, DVDDemuxBXA::Open needs to see a valid header at the start of the shairplay pipe but occasionally, shairplay triggers an audio_flush callback before the DVDDemuxBXA thread has a chance to read the header. The audio_flush callback nukes the contents of the pipe buffer so the Open call reads garbage rather than a proper header and the call fails. Since the shairport thread is still running, the client seems to think the stream is healthy even thought xbmc never successfully opened it.

The problem goes away if CAirTunesServer::AudioOutputFunctions::audio_flush is replaced with a no-op. This is admittedly a hack (although I personally didn't notice any side effects)

Do any of you know this code well and could provide some input on this?

thanks,

-Kevin

Mhhh thx for finding this out - will think about it ...

Does this fix the problem? (might even deadlock - not so familiar with our player):

http://pastebin.com/RxQPwq8a

As an alternative:

http://pastebin.com/BErpP79E

First patch causes the UI to freeze up. Second patch works beautifully.

I do wonder, though, if discarding the buffer is the correct behavior for the audio_flush callback... The "unofficial spec" (http://nto.github.io/AirPlay.html#audio-rtsprequests, scroll down to FLUSH) implies that the server is supposed to pause the stream, not discard any data

Ha - nice catch. I never thought about what else it could mean - i just like a reflex flushed the pipe there. Will ask the upstream dev if he thinks we even need to implement anything in there and change accordingly ...