Right now, with the current implementation, you cannot start playing until its fully downloaded. Worse yet, you can't do *anything* until its fully downloaded.
We could: (a) try to solve the issue of new Media(..) blocking UI thread without rewriting the whole plugin by moving the task of downloading to a background thread. This would still mean Media is non-streaming, and would change the behaviour to need to wait for success completion before playing, but would suck way less. (b) re-implement completely to support streaming. I suspect (a) is super trivial (Just follow advice of [1]?), and it is very likely we won't get to (b) any time soon. Patches welcome, though! [1]: http://cordova.apache.org/docs/en/edge/guide_platforms_ios_plugin.md.html#iOS%20Plugins_threading -Michal On Wed, Nov 13, 2013 at 3:22 PM, Michael Gauthier <m...@silverorange.com>wrote: > Can you start playing the local file before it's finished and will it play > to the end of the file, or just to the length of the buffer when playback > started? > > > On 2013-11-13 15:48, Shazron wrote: > >> Should have read the whole technote ;) AVPlayer *does* provide streaming >> support (it was new in iOS 4.0) while AVAudioPlayer does not. It's a whole >> new API in a new framework. We never did upgrade since this plugin was >> added in the iOS 2.0 days. Not sure if we are rewriting this plugin, but >> it >> using AVPlayer instead would be better. >> >> >> On Wed, Nov 13, 2013 at 11:41 AM, Shazron <shaz...@gmail.com> wrote: >> >> AVAudioPlayer does not provide streaming support anyway: >>> https://developer.apple.com/library/ios/qa/qa1634/_index.html >>> >>> Related: https://issues.apache.org/jira/browse/CB-1176 >>> The workaround here is to download the file first using the FileTransfer >>> API (which has progress callbacks) and then load it using the Media API. >>> >>> >>> On Wed, Nov 13, 2013 at 11:31 AM, Michal Mocny <mmo...@chromium.org >>> >wrote: >>> >>> And for what its worth, the exec bright is now async, so its likely that >>>> js >>>> execution is not actually blocked, but rather safari remote inspector is >>>> not showing output which the app UI thread blocked. >>>> >>>> Try to console.log(new Date()) and see if that is actually reporting a >>>> gap. >>>> If we fix this to move the download off-the-ui thread you will need to >>>> update your code to call mediaPlayer.play() from the success callback. >>>> >>>> >>>> On Wed, Nov 13, 2013 at 2:29 PM, Michal Mocny <mmo...@chromium.org> >>>> wrote: >>>> >>>> Yes, there is a bug that the media download is happening on the main ui >>>>> thread. You should be seeing a native warning message (see >>>>> https://issues.apache.org/jira/browse/CB-4133) about this. >>>>> >>>>> I've not found a bug filed specifically for this yet, so filed here: >>>>> https://issues.apache.org/jira/browse/CB-5378 >>>>> >>>>> >>>>> On Wed, Nov 13, 2013 at 1:43 PM, Nick Burka <n...@silverorange.com> >>>>> >>>> wrote: >>>> >>>>> >>>>> I’ve been implementing a simple Media playback app. It looks something >>>>>> like: >>>>>> >>>>>> console.log(’start'); >>>>>> mediaPlayer = new Media( >>>>>> uri_to_my_mp3_file, >>>>>> mediaSuccess, >>>>>> mediaError, >>>>>> mediaStatus); >>>>>> >>>>>> console.log(’end’); >>>>>> mediaPlayer.play(); >>>>>> >>>>>> When the JavaScript executes, it takes 20+ seconds between the ‘start’ >>>>>> and ‘end’ logs. Then when I seekTo() on the playing file, it’s >>>>>> >>>>> virtually >>>> >>>>> instantaneous. I presume that the Media class is downloading the entire >>>>>> file on instantiation? >>>>>> >>>>>> A few other people seem to have the same problem: >>>>>> >>>>>> >>>>>> http://stackoverflow.com/questions/19938383/phonegap- >>>> build-media-play-takes-a-long-time-to-start-playing >>>> >>>>> >>>>>> >>>>>> http://community.phonegap.com/nitobi/topics/phone_gap_media_ >>>> api_ios_slow_loading >>>> >>>>> >>>>>> Any help would be much appreciated. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >
