Stream info broken with Media Player Library 0.7.0

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a custom receiver with mpl 0.7.0 and SmoothStreamingProtocol.
2. Call cast.player.api.Player reload() after select a new audio stream.
3. Call getStreamCount() after reload.

What is the expected output? What do you see instead?
Expected behaviour is to get the real amount of streams in the manifest as 
happened until mpl 0.6.0 and before the call of reload(). But now every call of 
getStreamCount get the amount of streams in the manifest twice. A second switch 
of the audio stream, a new call of reload() and call again getStreamCount() 
delivers an tripled stream count of the manifest file. A call before the first 
reload() gets the right amount of streams.

Please use labels and text to provide additional information.
Chromecast firmware 16664, Cast receiver lib 2.0 and media player lib 0.7.0, 
Chrome cast sender.

I don't know if this problem happens only with the SmoothStreaming protocol. We 
don't use hls and the dash implementation from cc seems to be broken or does 
not support features we use for dash.

Btw: Until mpl 0.6.0 audio streams which are not playable by the chromecast 
device are suppressed by the streaming protocol. We use for every available 
language in a vod stream a aac stereo stream and a ac3 6 channel stream. With 
mpl 0.6.0 I did not see the ac3 streams which was ok because they are not 
playable. Now with mpl 0.7.0 I get all audio streams, but the only option to 
distinguish between the streams is the bitrate because all other information of 
getStreamInfo() are similar.

Original issue reported on code.google.com by sebastia...@gmail.com on 3 Jun 2014 at 1:43

[GoogleCodeExporter]

This was a regression in 0.7.0, thank you for reporting it and sorry for the 
inconvenience. This will be fixed in the next media player library update.

Original comment by vadi...@google.com on 10 Jun 2014 at 5:57

[GoogleCodeExporter]

Fixed with mpl 0.8. Bug can be closed. Thanks!

Original comment by sebastia...@gmail.com on 16 Jul 2014 at 6:28

[GoogleCodeExporter]

Original comment by anad...@google.com on 16 Jul 2014 at 6:30

• Changed state: Fixed