This project has moved and is read-only. For the latest updates, please go here.

Shoutcast support

Dec 12, 2014 at 10:18 AM

First of all, you've put together an impressive and terrific library, bravo!

Now, some questions. I have dozens of streams that don't work really well with your library, just to name a few:
and so on. Often I get these debug messages:
Media manager state in background agent: OpenMedia, message: 
MediaStreamFascadeBase.MediaManagerOnStateChange() to Opening: 
Media manager state in background agent: Opening, message: 
A first chance exception of type 'System.IO.FileNotFoundException' occurred in
A first chance exception of type 'System.Net.WebException' occurred in
Additional information: The remote server returned an error: NotFound.
Also, while we are at it. I usually start my streams like this:
BackgroundAudioPlayer.Instance.Track = new AudioTrack(null, "Radio Deejay", "Artist", "Album", null, "", EnabledPlayerControls.Pause);
Is it correct?

Thank you for your support and thousands of congratulations on your fantastic project!
Dec 13, 2014 at 12:37 PM
Thank you.

Are you seeing problems other than the "file not found"?

Which version of phonesm are you using?

I checked in a few things that should make switching streams when playing background audio more reliable a few hours ago (most of that is in 9fec76c56ff6).

If you are using a recent version of phonesm, I would suggest trying HttpConnection rather than the default portable HttpClient. Set the flag like this in AudioTrackStreamer's constructor:
            MediaStreamFacadeSettings.Parameters.UseHttpConnection = true;
With 8ff54251f6b0, it is just a matter of uncommenting this line. Given the known issues with using the pre-WinRT HttpClient to read long or endless streams (memory leaks, hogging nonvolatile storage, and a tendency to never stop reading a stream until the end is found or the app exits), that flag should probably be enabled by default.

While I didn't do any extensive testing, I was able to play the streams you listed on "Emulator 8.0 Update 3 WVGA 512MB" (I did have "UseHttpConnection" enabled in my development tree).

And yes, I think that the way you are setting the track should be fine (IIRC, you may have some trouble on WP7, but most people aren't targeting WP7 anymore).

Good luck.
Dec 15, 2014 at 4:44 PM
Edited Dec 15, 2014 at 4:51 PM

Sorry for getting to you so late but I didn't receive any notification by email. Must have gone in the spam folder. Anyway, I was testing not directly from the git source code but from the download package (there were few typos in the library that made me suspicious, like 'Fascade' instead of Facade).

Using the latest version directly from git and testing it against WinRT with my streams I can finally see that all is finally working well :) You can't imagine how happy I am!

Just one last thing. I see that you set the stream in the SM.Media.BackgroundAudio.MediaPlayerManager public member "Play". This class is marked sealed so I can't access from my main project. What's the correct way of setting the stream I'd like to play?

Edit: even if it's sealed it should be accessible. Checking if I'm missing something, I'll report to you later :)

Edit2: MediaPlayerManager is not set as public so it's not accessible from the outside. Marking it as public allows me to do so :)
Dec 16, 2014 at 8:21 PM
Edited Dec 16, 2014 at 8:23 PM
Yes, well, the WP8.1 background audio code still has some rough edges... But good to hear that it is working for you. At this point, you will just have to modify the MediaPlayerManager code. Going forward, the URL should probably come from the foreground app and may need to be persisted by the background task. There has been a memory leak that seems to be much better since VS2013 Update 4 that I'm still investigating. Keep an eye on the checkins over the next week or so (depending on how much of a chance I get to muck with this stuff).

You may also want to take a look at: Overview: Background audio (Windows Phone Store apps).
Dec 19, 2014 at 2:04 PM
Updated to your latest commit and it's showing improvements in stability, great! :)

Anyway, is it normal that I see tons of 'System.Threading.Tasks.TaskCanceledException' in the output window when closing the stream (either by calling stop on the backgroundaudioplayer or setting to null its track) ?

Also, when changing between 7-8 streams in a row, I ofter get the audio backend to hang, never getting to listen to anything else. The only solution is to restart the app.

PS: I'm currently testing the BackgroundAudioStreamingAgent.WP8 with UseHttpConnection set to true.
Dec 19, 2014 at 2:23 PM
Edited Dec 19, 2014 at 2:23 PM
Yes, all those TaskCancelledException are noisy. There a are a few things running in parallel and each gets stopped by a cancellation token. Every place where the exception is re-thrown also generates one of those output window messages. It doesn't help that some of the guts of phonesm are way more complicated than they should be.

Did you testing include 333311796ef3? It fixed a problem I saw when hammering the "next" button in HlsView.Win81. If so, your debug output should show a warning along the lines of: "builder is busy" (I don't recall the exact text off the top of my head).
Dec 19, 2014 at 2:52 PM
Yes, i've updated the source just an hour ago. Never had problems of "builder is busy" or anything related to the builder.

I've launched the test app in debug mode and this is what's happening:
  • Stream starts and correctly plays. This is the output window:
Media manager state in background agent: Opening, message: 
<Limit 25,00MiB>
Media manager state in background agent: Playing, message: 
AudioPlayer.OnPlayStateChanged() track.Source <none> track.Tag;stream.nsv      playState TrackReady
AudioPlayer.OnPlayStateChanged() track.Source <none> track.Tag;stream.nsv      playState Paused
AudioPlayer.OnPlayStateChanged() track.Source <none> track.Tag;stream.nsv      playState Playing
  • I select a new stream: first I set the track to null, then I define the new track. This is the output window regarding the "stopping" process:
AudioPlayer.OnUserAction() track.Source <none> track.Tag;stream.nsv      action Stop
Media manager state in background agent: Closing, message: 
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in
AudioPlayer.OnUserAction() track.Source <none> track.Tag <none> action Stop
AudioTrackStreamer.CleanupMediaStreamFacade() NotifyComplete
And this is the "new stream" process:
AudioPlayer.OnBeginStreaming() track.Source <none> track.Tag
Media manager state in background agent: Opening, message: 
<Limit 25,00MiB>
Media manager state in background agent: Playing, message: 
Media manager state in background agent: Closing, message: 
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in
Bear in mind that this happens only after I've switched between 5-6 streams in a row. If I change stream only a couple of times everything goes well.
Dec 19, 2014 at 4:02 PM
Hmmm... I'll try some button mashing in BackgroundAudio.Sample.WP8. Have you tried without setting it to null? That is needed when using Player Framework, but (hopefully) not in background audio.

Do you happen to know if this only happens if you switch while a stream is opening (after setting the track but before playback starts)?

Dec 19, 2014 at 4:36 PM
It doesn't get better or worse if I just replace the stream, if I set the track to null before changing or even if I call Stop() and then select a new stream.
Anyway this is what I've modified in your project to test my scenario:

AudioPlayer.cs (OnUserAction)
                case UserAction.Play:
                        player.Track = track;

                        if (PlayState.Playing != player.PlayerState && null != player.Track)

Duplicated your AudioPlayer.UpdateTrack method here replacing player with BackgroundAudioPlayer.Instance.
In prevButton_Click , nextButton_Click the following:
//BackgroundAudioPlayer.Instance.SkipPrevious() -- or SkipNext
_currentTrack--; //or ++
Created a list of streams directly here as follows (for your convenience)
static readonly AudioTrack[] AudioTracks =
            new AudioTrack(null, "RTL 102.5", null, null, null, ";stream.nsv", EnabledPlayerControls.All),
            new AudioTrack(null, "Whatever Radio", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio 105", null, null, null, ";stream.mp3", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Number One", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Studio Più", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Pico Classic", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Millenote", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Deejay", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Flash", null, null, null, "", EnabledPlayerControls.All),
            new AudioTrack(null, "Radio Pico", null, null, null, "", EnabledPlayerControls.All),
        static int _currentTrack = -1;
After some "button smashing" (ahaha) this is what happens:
MediaStreamFacadeBase.MediaManagerOnStateChange() to Playing: 
Media manager state in background agent: Playing, message: 
BufferingManager.UpdateBuffering done buffering: duration 00:00:09.9003896 size 59559 starting True memory 1,27 MiB
  Audio count 567 size 88869 newest 00:00:14.7852784 oldest 00:00:00
Media CloseMediaCalled: Playing -> Draining at 19/12/2014 17:28:34 +01:00
TsMediaManager.SetMediaState() Playing -> Closing
TsMediaManager.ReportState() state Closing message 
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in
TsMediaStreamSource.CloseAsync(): close RanToCompletion
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in
MediaStreamFacadeBase.MediaManagerOnStateChange() to Closing: 
Media manager state in background agent: Closing, message: 
TsMediaManager.CloseReadersAsync() closing readers
TsMediaManager.CloseCleanupAsync() waiting for tasks
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in
Dec 20, 2014 at 7:09 PM
What are you using for testing? I've been using "Emulator 8.0 Update 3 WVGA 512MB", but have not gotten it to stop working. There have been some problems with background audio in earlier WP builds (I would expect trouble with "Emulator 8.0 WVGA 512MB"). I'll give it a try on some actual hardware as well.
Dec 20, 2014 at 8:31 PM
I'm using a Lumia 1520 with 8.1 DP. Never used the emulator as it's not a good reference with these sort of things :)
Dec 21, 2014 at 3:25 AM
While the emulator can goof things up, it usually doesn't fix them. It does make it easier to control the firmware version.

I tried with Lumia 920 on 8.1 Dev Preview. The closest I came to what you describe is when I used the system controls (with the app in the background) and hit a flaky station. Since OnBeginStreaming() calls "NotifyComplete()" without specifying a stream, playback stops. Hitting "Play" started playback again. One could retry in OnBeginStreaming() and/or fall back to the next stream when a given stream isn't available. I suppose one could play fake static and retry opening the channel until it became available or until the user hit the "next" or "previous" button.

Note that I have not tried setting the track from the foreground.
Jan 29, 2015 at 12:12 PM
I'm digging up this old thread because I have new evidence. Basically, I've set up a list of 20+ streams and periodically (every 10 seconds) the track changes and goes to the next one. The first 9 streams are ok but starting with the 10th and going forward all streams suddenly stop working (even though they were just a moment ago). Closing and restarting the app usually solves the problem although sometimes a phone reboot is necessary (built-in Music app strangely stops playing any cloud/local mp3 files!).

This is happening on a 925 8.1 Cyan, 1520 8.1.1 DP (Cyan), Emulator 8.1 WXGA 4.5 inch. I'm changing streams from the foreground thread and I'm using the WP8.0 background audio library.
Jan 29, 2015 at 3:56 PM
Which version of phonesm are you using? Is it always after the 9th stream or is it that it usually breaks around the 10th? Does changing the order of the streams make any difference? Is the background audio memory usage doing anything strange (that's the "<10,46MiB/10,99MiB>" stuff in the debug output)?

Having to reboot the phone doesn't sound good, but it might suggest that something is getting seriously wedged (some kind of deadlock).
Jan 29, 2015 at 4:03 PM
Latest commit available (ce1de859ee7a). It's always after the 9th stream even by changing the order but I'm going to do more testing on this regard: I want to check if putting on top of my list streams with a low bitrate will allow me to go further (meaning there's some kind of leak in the opening/closing of streams).
I haven't noticed anything unusual (right up untill the start of the 10th stream everything goes well) with the memory usage, but I'm totally going to study it further.

I'll report in with any new finding.
Jan 30, 2015 at 9:28 AM
That sounds very odd. You might try alternating between two streams to see if things still blow up after the 9th switch.

I've been meaning at some point to implement a less complicated read scheme for audio-only streams. Much of the processing pipeline isn't necessary for handling that case (not that the general case needs to be as complicated as it is either).
Jan 30, 2015 at 10:18 AM
Just a quick update as I've got a lot of work to do :|

Same thing happens with a totally different order of the streams. Even by switching between two of the most stable of my streams the problem occurs after the 9th play: sometimes, I don't know why, the stream doesn't start right away and goes in a sort of stall. Hitting stop and then play fixes the issue (not a big problem TBH) but when this happens it adds anyway to the 9-play count limit I've been hitting.

I've been unable to attach to the debugger as I'm busy with other things ATM, but I'll try and report with some more substantial findings later today.
Jan 30, 2015 at 4:13 PM
Here's the debug output copied exactly as displayed on my computer:
This is a little bit more readable having stripped out all the exceptions from it:

Hope it can be of any help!
Feb 4, 2015 at 3:40 PM
Nothing in those logs is jumping out at me, but I'll try to replicate your setup here.
Feb 20, 2015 at 2:21 PM
Updated to your latest commit (b6b377283519) and still hangs at the 9th / 10th play :D
Have you had the chance of looking into this? May I help you setting up the environment into which the bug occurs? How can I send you the modified files?
Feb 21, 2015 at 12:01 AM
I'm seeing problems with just one stream (when it ends) and the "SM.Media.BackgroundAudioStreamingAgent.WP8 loading delays" thread mentions having problems after eight streams.

I was hoping the "UseSingleStreamMediaManager" would help, but it has not. I'll try to figure out what is going on...
Feb 21, 2015 at 12:02 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.