I’ve recently encountered an issue that I seem unable to solve. I am creating a simple component for an application that plays audio files (primarily .mp3 and .wav) and after doing some testing, the application appears to work fine in Chrome.
However in IE9, which is the only major browser that I am concerned with I seem to hit a brick wall when serving my audio files.
The files are currently being requested through a Controller Action as shown:
public ActionResult PlayAudioFile(string id)
{
AudioFile af = FileAgent.GetAudioFile(id);
try
{
//Grabs the file via a Provider
Stream resultStream = StorageProvider[af.Provider].ReadFile(af.Location);
resultStream.Position = 0;
//Added several headers in attempts to resolve the issues
Response.AppendHeader("Content-Disposition", "attachment; filename=audio.mp3");
Response.AppendHeader("Content-Length", resultStream.Length.ToString());
Response.AddHeader("Accept-Ranges", "bytes");
Response.Headers.Remove("Cache-Control");
Response.AddHeader("Content-Range","bytes 0-" + (resultStream.Length-1).ToString() + "/" + resultStream.Length.ToString());
//Returns the file and associated file type (from the Provider)
return new FileStreamResult(resultStream, resultStream.ContentType);
}
catch
{
//Uh oh. Error
}
}
The above works great for Chrome and has worked in a variety of HTML5 Players, such as jPlayer, audio.js and MediaElement. However, when the file is requested by something like the following (using jPlayer syntax):
$(this).jPlayer("setMedia", {
mp3: '@Url.Action("PlayAudioFile","Home")?id=D00023',
});
or audio.js syntax:
player.load('@Url.Action("PlayAudioFile","Home")?id=D00023');
and associated audio.js audio tag:
<audio preload="auto" crossorigin="use-credentials"></audio>
Which fires the proper action and returns the FileStreamResult, however it appears that all of the players are having difficulty deciphering the file and reading it properly. I have tried several players and have run into this same issue in all of them.
Any suggestions would be greatly welcome. Thanks.
NOTES:
-
As mentioned in one of the comments, I have attempted using multiple and a variety of comment types to resolve this issue. None of which have worked.
-
When exploring some possible root causes of this issue, I noticed that removing the [Authorize] attribute cleared up some of the issues with directly accessing the file, but all of the players were unable to load the file within IE9.
-
I am now convinced that this could be a credentials issue and that when I need to request the file through jPlayer or audio.js (or what have you) I need to include the necessary credentials to allow it to access the file through the controller.
-
Attempted to use
$.ajax({ withCredentials: true})and<audio crossorigin='use-credentials>. Both without success.
HEADER INFORMATION:
Both of the requests (the working one in Chrome and the non-functional one in IE9) both have these same headers:
Cache-Control: public, max-age=3600, s-maxage=0
Date: [Current Date Time]
Expires: [Current Date Time + max-age]
Vary: *
Content-Length: 77870
Content-Type: audio/mpeg
Last-Modified: [Date]
Accept-Ranges: bytes
Content-Range: bytes 0-77869/77870
Server: Microsoft-IIS/7.5
After delving further into the issue, it became apparent that the issue was being caused by the encoding of the .mp3 files themselves during the recording process. I elected to process them through Audacity and after doing so they were recognized by IE9 (as well as other browsers).