I cannot get AVAssetExportSession to work when the application is in the background.
My application has the Background Mode "Background Fetch" enabled.
When this UIApplicationDelegate method is called
func application(application: UIApplication, performFetchWithCompletionHandler completionHandler: (UIBackgroundFetchResult) -> Void)
is called I use AVAssetExportSession to export an AVAsset, using the method:
exportAsynchronouslyWithCompletionHandler
I then receive this error:
Error Domain=AVFoundationErrorDomain Code=-11800 "The operation could not be completed" UserInfo={NSUnderlyingError=0x147dae560 {Error Domain=NSOSStatusErrorDomain Code=-16980 "(null)"}, NSLocalizedFailureReason=An unknown error occurred (-16980), NSLocalizedDescription=The operation could not be completed}
However, when I have the background mode "Audio, Airplay and Picture in Picture", the export works.
This is great, however our submission is being rejected because we do not play any audio in the background.
is there any other way to export video in the background?
Cheers, Red
STEPS TO REPRODUCE
I have created a sample project to show this issue.
Download from: http://up.red.to/WKo1MMstzD
Run the app on a device
Accept the permissions
Press the home button
In Xcode, go to Debug -> Simulate Background Refresh
See error (printed in console and shown as a local notification)
Your question:
is there any other way to export video in the background?
Absolutely, with some limitations.
NSProcessInfo has a set of APIs for requesting more time to finish tasks when the application is in the background. For example:
id activity = [[NSProcessInfo processInfo] beginActivityWithOptions:NSActivityAutomaticTerminationDisabled reason:#"Good Reason"];
[exportSession exportAsynchronouslyWithCompletionHandler:^{
[[NSProcessInfo processInfo] endActivity:activity];
}];
That will get you more time. There are other APIs intended for synchronous operations, and in either case your application should still be prepared for the system to not allow more time. This was covered extensively in sessions at WWDC 2015.
You must also make sure that your background activity is not writing to a protected portion of the filesystem. Make sure the output location has the correct NSFileProtection attributes set to allow access even when the device is locked.
Now, specifically with background fetch you have a very limited amount of time to complete your work and call the background fetch completion handler. The background fetch API is intended to be used with NSURLSession to schedule background downloads that are executed out of your application process. Using the NSProcessInfo API will probably not buy you any more time here, and the background fetch API is a very poor fit for encoding/exporting media. The time required to complete for even small media files would exceed the time limit for the background fetch handler.
Related
I have been using NSURLSession to do background uploading to AWS S3. Something like this:
NSURLSessionConfiguration* configuration = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier:#“some.identifier"];
NSURLSession* session = [NSURLSession sessionWithConfiguration:configuration delegate:someDelegate delegateQueue:[NSOperationQueue mainQueue]];
NSURLSessionUploadTask* task = [session uploadTaskWithRequest:request fromFile:[NSURL fileURLWithPath:httpBody]];
[task resume];
In someDelegate, I have implemented didSendBodyData, didCompleteWithError and handleEventsForBackgroundURLSession.
I have three questions:
I have noticed that if I close the app while uploading is in progress, transfer will continue and successfully finish. Is handleEventsForBackgroundURLSession called when the transfer is finished while the app is closed?
Assuming that the answer to the first question is yes, how can I delete httpBody in handleEventsForBackgroundURLSession? This is a temporary file that is not needed once transfer is complete.
I would appreciate it if someone explained, in detail, how background transfer works in iOS. That is when memory is created, which callbacks are called at which states and how the app is woken up once the transfer is completed. Thanks.
When the app delegate's handleEventsForBackgroundURLSession is called, you should:
save the completion handler;
instantiate your background NSURLSession;
let all of your delegate methods to be called;
in your URLSession:task:didCompleteWithError:, you can remove those temp files; and
in URLSessionDidFinishEventsForBackgroundURLSession:, you can call that saved completion handler.
A few additional notes:
There seems to be some confusion about what happens when an app is terminated.
If the app is terminated in the course of its normal lifecycle, the URLSession daemon will keep the background requests going, finishing your uploads, and then wake up your app when it's done.
But manually force-quitting the app (e.g., double tapping on home button, swiping up on the app to force it to quit) is a completely different thing (effectively, the user is saying "stop this app and everything associated with it"). That will stop background sessions. So, yes, background sessions will continue after the app is terminated, but, no, not if the user force-quit the app.
You talk about setting breakpoints and observing this in Xcode. You should be aware that the process of being attached to Xcode will interfere with the normal app life cycle (it keeps it running in background, preventing it from being suspended or, during the normal course of events, terminating).
But when testing background session related code, it's critical to be test the handleEventsForBackgroundURLSession workflow when your app was terminated, so to that end, I'd suggest not using Xcode debugger when testing this dimension of background sessions.
I use the new OSLog unified logging system, because the macOS Console can watch what is logged by the app, while not having Xcode running at all. Then I can write code that starts some download or upload, terminates app and then watch the logging statements I have inserted in order to observe the restarting of the app in background via the macOS console. See Unified Logging and Activity Tracing video for a tutorial of how to watch iOS logs from the macOS Console.
I'm having issues with handling "out of space" / "full disk" errors on ios with NSURLSessionDownloadTask
If the disk is full due to downloads done in the app I get a call to
URLSession(session: NSURLSession, task: NSURLSessionTask, didCompleteWithError error: NSError?)
with the error having domain NSPOSIXErrorDomain and error code ENOSPC
But this only happens once for a task, not for all running
Ex: If I have 3 tasks running at the time, I only get this for one of them and the other 2 remain in the state Running
They don't receive any bytes, but they don't fail either.
Moreovever, calling cancel on any of those tasks changes their state from Running to Cancelling and they remain like this indefinitely.
My solution was, when I receive this error the first time, to call invalidateAndCancel for the session and handle failure for all running tasks.
This seems to work when the "full disk" is caused by the downloads made by the app.
But if "full disk" error is caused by external downloads (Ex: iTunes file sharing, downloading Podcasts, other apps downloading) I receive no error in the app
All my download tasks remain in Running, or Cancelling (if I try to cancel them)
They don't download anything, they don't fail with any of the callbacks for NSURLSessionDelegate or NSURLSessionDownloadDelegate
Before starting a download, I check the available space available on device
I also take into consideration the currently Running tasks
But I have no control over other downloads on the device that might end up triggering the "full disk" warning
How can I handle these cases?
Are the download tasks expected to remain in Running state though they are not downloading anymore?
Shouldn't I get a didCompleteWithError call with (NSPOSIXErrorDomain, ENOSPC) for each task, or for the session at least?
Or at least shouldn't I be able to successfully cancel them? and get a didCompleteWithError call anyway?
Is there a delegate call I'm missing, one that would let me know it's time to close all running tasks?
I'm using a shared background session for more background download tasks
The download tasks are created with NSURLSession's:
func downloadTaskWithRequest(_ request: NSURLRequest) -> NSURLSessionDownloadTask
The sesion configuration is created using NSURLSessionConfiguration's:
class func backgroundSessionConfigurationWithIdentifier(_ identifier: String) -> NSURLSessionConfiguration
The seesion is created using, NSURLSession's
init(configuration configuration: NSURLSessionConfiguration,
delegate delegate: NSURLSessionDelegate?,
delegateQueue queue: NSOperationQueue?)
I'm using a NSOperationQueue with a maxConcurrentOperationCount of 3
I have implemented my NSURLSessionDelegate and NSURLSessionDownloadDelegate
Tasks seem to run fine in foreground and background.
Thanks
Ps: using Xocde7, ios9 sdk, tested on an ios9 device
I had also asked Apple about this issue and the answer came back:
Seems like, because the background session uses the disk to persist its state, behaviour when the disk is full is not exactly reliable to return the ENOSPC
And the handling of full disk case is the developer's responsibility for now by:
checking for disk space before you start a download
monitor disk space when your app is downloading — If your app is in the foreground, or your app gets resumed (or relaunched) in the background, actively monitor the disk space available. If it’s below some threshold, suspend your downloads (by calling -cancelByProducingResumeData:, so you can resume them later on).
For a detailed answer check:
https://forums.developer.apple.com/thread/43263
I have some misunderstanding in using NSURLSession framework, that's why I decided to write small app from scratch without AFFramework/Alamofire.
I have an API that requires following steps to upload file:
POST file data
Get response (JSON)
Post some json fields to api/save
I have a background session with such config:
let configuration = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("myBackground")
let session = NSURLSession(configuration: configuration, delegate: self, delegateQueue: nil)
I've implemented 2 methods:
func URLSession(session: NSURLSession, dataTask: NSURLSessionDataTask, didReceiveData data: NSData)
where I aggregate all data
and
func URLSession(session: NSURLSession, task: NSURLSessionTask, didCompleteWithError error: NSError?)
where I tranform this data to response object. This response object if VERY important for me.
Everything works fine, while app is in foreground, but I have problems in background.
Case 1
App crashed right after I've started to upload data. According to WWDC I need to implement
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void)
and call this handler in didCompleteWithError method. But before calling this method I need to call api/save with data from upload response.
How can I get this data?
Case 2
Mostly similar case. User stops app while upload is in progress. Than loads app in few seconds, while session works with my task. Now session calls didReceiveData, but of course, some of data is missing. What should I do in such case? How to restore response data?
You don't mention implementing URLSessionDidFinishEventsForBackgroundURLSession (a NSURLSessionDelegate method). You really want to implement that, too. The basic process is:
In app delegate's handleEventsForBackgroundURLSession, you should:
start the background NSURLSession (which will start receiving delegate method calls associated with all of the uploads); and
save the completion handler (but do not call it, yet).
Then, in URLSessionDidFinishEventsForBackgroundURLSession (when you're done processing all of the responses), you call the completion handler you saved in handleEventsForBackgroundURLSession. (Make sure to dispatch that to the main queue.)
If you're doing all of that, when the background session is restarted, the didReceiveData calls will come in with the responses to your various uploads.
I just did a quick test, uploading five 20mb images and immediately terminating the app. Then, even though the app wasn't running, I watched the five files slowly show up on my server (obviously handled by the daemon process). When all five were done, by app was transparently restarted in the background, the handleEventsForBackgroundURLSession was called (which restarted the session), it let all of the didReceiveData calls quickly get called, and when that was done, URLSessionDidFinishEventsForBackgroundURLSession was called and my app only then called the saved completion handler.
In terms of why this isn't working for you, there's not enough to diagnose the problem. Possibilities include:
Maybe you terminated the app inappropriately. You can't kill the app by double tapping the home button and terminating the app there; you have to let it naturally terminate on it's own, or for diagnostic/testing purposes, I force it to terminate by calling exit(0) in code.
Maybe you didn't restart the session when handleEventsForBackgroundURLSession was called.
Maybe you called the supplied completion handler too soon (i.e. before URLSessionDidFinishEventsForBackgroundURLSession was called).
It's hard to say, but I suspect that there's something buried inside your implementation that isn't quite right and it's hard to say what it is on the basis of the information provided (assuming it isn't one of the above points). Unfortunately, debugging this background sessions is vexingly complicated because when the app terminates, it is no longer attached to the debugger, so you can't easily debug what happens after the app is restarted automatically by iOS). Personally, I either NSLog messages and just watch the device console (as well as watching what appears on the server), or I build some persistent logging mechanism into the app itself.
For testing Background session code it is recommended to test on a real device. When writing an app that uses NSURLSession’s background session support, it’s easy to get confused by three non-obvious artifacts of the development process:
When you run your app from Xcode, Xcode installs the app in a new container, meaning that the path to your app changes. This can confuse NSURLSession’s background session support.
Note: This problem was fixed in iOS 9; if you encounter a problem with NSURLSession not handling a container path change in iOS 9 or later, please file a bug.
Xcode’s debugging prevents the system from suspending your app. So, if you run your app from Xcode, or you attach to the process some time after launch, and then move your app into the background, your app will continue executing in situations where the system would otherwise have suspended it.
Similarly, the iOS Simulator does not accurately simulate app suspend and resume; this has worked in the past but it does not work in the iOS 8 or iOS 9 simulators.
Source: Apple Developer Forum
I need something similar to Facebook's offline post capabilities. Basically I want users to create content locally on the device regardless of connection state, and whenever internet becomes available it should POST/PUT to the server.
I've searched the internet for a solution and I found that NSURLSessionUploadTask can be used for POST-ing in the background. But I couldn't figure out if the following scenarios are supported:
Will my task remain in the background queue when the user is offline and will the operating system try to execute items in the queue upon reconnecting with a network?
What happens if the application is force-closed by the user or crashes?
What happens if the operation fails?
First of all, background NSURLSession allows file upload only. If that is ok for you:
The task will be in the queue until it receives a server answer.
If your app is force-closed, the task will still be executing. When the request is done, your app will be launched in non-interactive background state and receive application:handleEventsForBackgroundURLSession:completionHandler:. After you process the signal and call the completion handler or 30 second timeout, the app will be closed.
I the operation fails, you will receive URLSession:task:didCompleteWithError:
There is a good tutorial on background NSURLSessions. I suggest you to read all 4 parts of this great article.
If file upload is not an option for you, i suggest you to save information into local database and then wait for internet is reachable. (a good approach here is use of Reachability library, Alamofire allows to do that too). When internet becomes available, simply call your http requests with saved data.
We were running into connectivity issues with our internal apps, so we wrote a Swift framework that allows any network operations to be enqueued and sent whenever the device has access to the internet -
https://cocoapods.org/pods/OfflineRequestManager. You'll still have to handle the network request itself within the object conforming to OfflineRequest, but it sounds like a good fit for your use case.
The simplest use case would look something like the following, though most actual cases (saving to disk, specific request data, etc.) will have a few more hoops to jump through:
import OfflineRequestManager
class SimpleRequest: OfflineRequest {
func perform(completion: #escaping (Error?) -> Void) {
doMyNetworkRequest(withCompletion: { response, error in
handleResponse(response)
completion(error)
})
}
}
///////
OfflineRequestManager.defaultManager(queueRequest: SimpleRequest())
I'm currently writing an iOS app that allows users to stream music from soundcloud. Currently I am able to stream just fine from Soundcloud, in booth forefront and background app states. I have an issue when I download an MP3 files and attempt to play it and have continuously playback when the app in in the background, more specifically in the locked screen or the screen is off.
When I play a downloaded file and lock the screen, the audio continues to play for a while. Usually it plays for 2 -3 mins. After that playback will stop and any other downloaded mp3 files in the playlist will not playback until the user returns to the app. Items in the playlist that are not downloaded will playback perfectly if the user has an internet connection, regardless if a downloaded item failed to play previously.
There are times when I receive the following error:
AVPlayerItemStatusFailed: Error Domain=AVFoundationErrorDomain Code=-11800 "The operation could not becompleted" UserInfo=0x170270500 {NSUnderlyingError=0x170059380 "The operation couldn’t be completed. Operation not permitted", NSLocalizedFailureReason=An unknown error occurred (1), NSLocalizedDescription=The operation could not be completed}
I will additionally get the following notification from the AVPlayerItem
Notification: NSConcreteNotification 0x1700538c0 {name = AVPlayerItemDidPlayToEndTimeNotification; object = AVPlayerItem: 0x178009300, asset = AVURLAsset: 0x17822aaa0, URL = file:///var/mobile/Applications/51118E74-3334-4EFC-B148-B485DE675F9E/Documents/Downloads/SC_165903784.mp3}
This notification is received when the first item that is playing stop playing. It doesn't make sense that I get this notification when it doesn't finish playing to end of its duration.
My guess is that because the app is in background mode there is a limited time set for reading files, but I somehow doubt that.
I'm using the following to create a AVPlayerItem from a Local file.
NSURL* url = [NSURL fileURLWithPath:song.downloadFilePath];
[AVPlayerItem playerItemWithURL:url];
I have tried building my own AVQueuePlayer and also using iOS Hysteria Player, but both instances have given me the same bug for offline download playback.
Any insights or solutions are greatly appreciated.
Thanks!
Are you playing your files from the Documents directory? (Or anywhere besides the app bundle?)
If so, be sure to save the files to the directory using
[fileToSave writeToFile:filePath options:NSDataWritingFileProtectionNone error:nil];.
The NSDataWritingFileProtectionNone is the critical bit! What's going on, at least in my case, is this: iOS is trying to be secure, and so is by default enabling file protection on the files you add to the Documents directory (and also the other non-app-bundle directories as well, I believe). By adding NSDataWritingFileProtectionNone, you're requesting the system to no longer enable this protection on your files.
From Apple's iOS Documentation:
If you protect a file, your app must be prepared to lose access to
that file. When complete file protection is enabled, your app loses
the ability to read and write the file’s contents when the user locks
the device.
Now, as soon as I read that, I was almost positive that this was the cause for my app not being able to continue playback once the device was locked. For security's sake, iOS seems to default to automatically putting files under protection… but this keeps everything, including your app, from being able to access it while the device is locked. My bug was that it only played part of the song as soon as the device was locked, and that makes sense… since its access to the actual song file was revoked, it was only able to play the part of the song that had already been buffered into RAM!
This was the fix for a month-long problem I've been pulling my hair out to try to solve. I sincerely hope it fixes the issue for you too.
I believe this issue is caused by the limitation of AVQueuePlayer, and HysteriaPlayer using AVQueuePlayer as core player so that's why.
I've seen AVQueuePlayer document mentioned (I can't find it unfortunately) that it can't handle the queue mixed with local and remote audios.
There's some workarounds:
Use AVPlayer
Don't use AVQueuePlayer, handle the queue by yourself and feed it to AVPlayer.
Separate two AVQueuePlayer
One for local media, one for remote media. Insert and use PlayerItem and Player properly.
I would patch HysteriaPlayer to meet this requirement a month later, you can come back that time.