locked
Can't Play an MP3 File from Local Data in an Audio Tag RRS feed

Answers

  • Hello there

    Thanks for your comments.

    There doesn't appear to be any caching.  If I set the .src property to file A (using "http:\\.."), then set it to file B, then close my internet connection, and then set the .src property to file A again, the file is not played.

    The issue with the downloaded .mp3 file not being played correctly has inexplicably disappeared.

    Regards

    Geoff Olding

    Wednesday, August 29, 2012 5:49 PM

All replies

  • Hi Geoff

    You have two options:

    1- Add the mp3 file in a folder inside your project, in Visual Studio, and call the src like: /music/mymusic.mp3

    2- Acess the local data folder using "ms-appdata:///local/" and not "C:/Users/..."

    Thursday, August 23, 2012 12:03 PM
  • You can also have the user choose the audio file to play by using the FilePicker

    -Jeff


    Jeff Sanders (MSFT)

    Thursday, August 23, 2012 1:19 PM
    Moderator
  • Thanks for your reply

    I have made this change, however I can't get it to work.  I have changed the src to something like "ms-appdata:///local/Audio/Core/C8.mp3", however I get the same effect (no error is displayed but no sound is played). 

    Regards

    Geoff Olding

    Friday, August 24, 2012 8:54 AM
  • Can you post a part of your code here? This way I try to help you. =]

    If the src in the audio tag is "ms-appdata:///local/Audio/Core/C8.mp3" the .mp3 file should be in: "C:/Users/Goldsworth%20Systems/AppData/Local/Packages/931bd7a1-ce4d-40ab-9a38-f5029272f6fc_sv7e3mmwz1bcp/LocalState/Audio/Core/C8.mp3"

    Friday, August 24, 2012 11:23 AM
  • Hello there

    Thanks for your kind offer.

    From some more investigations, I have worked out that it is something to do with the download leaving the file in some sort of invalid state. 

    As I say, I can take the downloaded file and successfully play it in another application (without having to close down my application).  I can also restart my application and playing the local file then works.  I have put in a workaround to copy the file (using copyFileAsync()) and playing the copy - this works correctly.

    For the record, the relevant parts of my code are as follows.

    This code creates the file:

    /*  Opens a file, creating it if necessary
    Follows with the new file's handle, "" if the file does not exist (and we are not creating), or null */
    function mOpenFile_Follow(oFolder, sEntity, bCreate, fnFollow) {

        try {
            var sFile = sFLGetName(sEntity);

            oFolder.getFileAsync(sFile).then(function (oFile) {
                UTFollow(fnFollow, oFile);
            }, function (oError) {
                try
                {
                    if (mbIsNotFoundError(oError)) {
                        if (bCreate) {
                            oFolder.createFileAsync(sFile).then(function (oFileNew) {
                                UTFollow(fnFollow, oFileNew);
                            }, function (oError) {
                                MUThrowException(oError, "mOpenFile_Follow", fnFollow);
                            });
                        }
                        else {
                            // File does not exist, and we are not creating it
                            fnFollow("");
                        }
                    }
                    else {
                        MUThrowException(oError, "mOpenFile_Follow", fnFollow);
                    }
                }
                catch (exThis) {
                    MUHandleException(exThis, "mOpenFile_Follow", fnFollow);
                }
            });
        }
        catch (exThis) {
            MUHandleException(exThis, "mOpenFile_Follow", fnFollow);
        }
    }

    I then pass this file handle to the following function to download it:

    /* Downloads a file from a remote website to the specified file
    Follows with true, or null */
    function mDownload_Follow(sRemoteURL, oFile, fnFollow) {

        try {
            var sURI = Windows.Foundation.Uri(sRemoteURL);
            var oDownloader = new Windows.Networking.BackgroundTransfer.BackgroundDownloader();
            var oDownload;
            var oPromise;
         
            // Create a new download operation.
            oDownload = oDownloader.createDownload(sURI, oFile);

            // Start the download and persist the promise to be able to cancel the download.
            oPromise = oDownload.startAsync().then(function () {
                try {
                    fnFollow(true);
                    }
                    catch (exThis) {
                        MUHandleException(exThis, "mDownload_Follow", fnFollow);
                    }
                },
                function (oError) {
                    MUThrowException(oError, "mDownload_Follow", fnFollow);
                },
                function () {
                    //  Progress (could probably remove?)
                });
        }
        catch (exThis) {
            MUHandleException(exThis, "mDownload_Follow", fnFollow);
        }
    }

    Many thanks

    Geoff Olding

    Saturday, August 25, 2012 10:52 AM
  • A bad file state is usually because you have not closed flushed the stream (or closed the file). 

    -Jeff


    Jeff Sanders (MSFT)

    Monday, August 27, 2012 6:37 PM
    Moderator
  • Thanks for your reply

    I did suspect this was the case, however I am unable to find any way to either close the file or flush the "stream" (it is not really a steam - we are using the background downloader).

    Any ideas as to what I need to do?

    Regards

    Geoff Olding

    Tuesday, August 28, 2012 6:31 PM
  • Hi,

    Addition to Jeff and geovanneb's reply, if the mp3 file comes from the web, you may wish to specify the http address in the src attribute directly. The file will automatically be downloaded and cached. This will save you a lot of effort. All you need to do is to specify the src attribute, without messing with background transfer and storage file APIs. The code can also be easily ported to a web application, where background transfer and WinRT file APIs cannot be used. In addition, most web servers support progresive audio/video download, so you can start to play the first part of the audio, while the remaining of the file is still being downloaded. Some servers even support streaming, so you can skip to 1:00:00, even if the data for the first hour has not been downloaded.

     

    If you want to manually download the file, please make sure the file has been completely downloaded before trying to play it. Also make sure you're downloading the file to the correct directory. As pointed out by geovanneb, files in local folders can be found at C:\Users\[your name]\AppData\Local\Packages\[your package]\LocalState\[subfolders if any]\[file name]. Morevoer, after the file is downloaded, remember to remove the download operation. This should close the downloaded file. Refer to http://code.msdn.microsoft.com/windowsapps/Background-Transfer-Sample-d7833f61/sourcecode?fileId=43575&pathId=698809060 for a sample.

    Best Regards,

    Ming Xu.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework

    Wednesday, August 29, 2012 3:04 PM
    Moderator
  • Hello there

    Thanks for your comments.

    There doesn't appear to be any caching.  If I set the .src property to file A (using "http:\\.."), then set it to file B, then close my internet connection, and then set the .src property to file A again, the file is not played.

    The issue with the downloaded .mp3 file not being played correctly has inexplicably disappeared.

    Regards

    Geoff Olding

    Wednesday, August 29, 2012 5:49 PM