Created attachment 356513 [details]
Potential patch

I've been testing against a local copy of http://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8

This is a variant playlist with a couple of alternate AUDIO tracks.

The behaviour is that the stream starts off playing at the lowest bitrate which gives us pads src_0 (video), src_1 (audio1) and src_2 (audio2). Immediately after the first fragments are downloaded the code realises it should play one of the higher bitrates and so gets ready to switch. In order to switch it has to wait for any fragment downloads on the original pads to complete. Once they complete, the code triggers a bitrate switch and creates a new set of pads and continues playing.

However, in our application, we don't attach to src_2 as we're only interested in the default audio pad. The code attempts to deal with this and describes the pad as un-linked. The bug is that between _src_chain and gst_adaptive_demux_stream_download_loop (inside gstadapativedemux.c) the code doesn't handle the un-linked case fully and it fails to call gst_adaptive_demux_has_next_period in the GST_FLOW_NOT_LINKED case. 
If src_2 finishes downloading first (or second), then this isn't an issue as the other pads complete the set of streams in gst_adaptive_demux_combine_flows. However, if src_2 is the last to finish downloading, the new pads aren't created and playback grinds to a halt.

I've attached a patch which simply duplicates similar code used in the GST_FLOW_EOS case above it. Although I believe it resolves this bug, I immediately hit another issue which I'll file a bug for if this patch does look sane.