This is the stream that I'm using to test:
http://hls.iptv.optimum.net/news12/nipadlive/index_new.m3u8?callsign=N12KN

It's a live stream with two alternate audio playlists alongside the main video one and it has 4 different bitrates of video. The playlists only have 3 segments each.

The stream fails to start up cleanly about 1 in 4 tries. In those cases the first video segment plays (lowest bitrate), then the video freezes for about a segment duration whilst audio plays. Then the audio freezes whilst the video plays the second segment to catch up. At that point the audio and video are back in sync and it continues to play correctly.

What's happening is the first video segment is downloaded, and at the same time all three available audio segments in both spanish and english are downloaded. The downloads are fast so the code decides to switch to a higher bitrate. If the variant switch decision happens after the last 2 audio segment downloads have started (i.e. 4 segments already downloaded) then the adaptivedemux code waits until they complete before switching. The pads haven't been removed and re-added yet as that is waiting on the preroll on all pads being handled so that the caps are available. The preroll on the audio has to wait for:

1. The playlist to be updated on the server with a new segment. 
2. The playlist to have actually been downloaded - polled by the client.

Because the audio playlists don't initially contain any more segments, there's a delay before the pads are exposed. The delay is long enough that the first video segment has finished playing and so it stalls.

The example stream is a worst case in that it has only has 3 segments per playlist. But the problem could still happen with longer playlists if the audio segments download quickly relative to the video segments.

I'm not sure what the best approach to fix this is. Could pads be enabled as soon as their stream is prerolled, and not wait for the others?