When using AVPlayer with MTAudioProcessingTap, stopping at a breakpoint anywhere in the application, on any thread, will cause mediaserverd to die temporarily.
This can be observed by setting a breakpoint anywhere in Apple's sample app. [AudioTapProcessor]
https://developer.apple.com/library/ios/samplecode/AudioTapProcessor/Introduction/Intro.html
For example, you can set it in the updateCenterFrequencySliderValue: method in MYSettingsViewController.m. (I also have an even smaller sample app I can post if it's helpful.)
This error message usually only appears in the device's Console log (viewable in Organizer), but sometimes also appears in the app's debugger log:
<Error>: 17:48:04.833 ERROR: [0x28c0000] 75: AudioQueueProcessingTapGetSourceAudio posting message to kill mediaserverd (45)
Playback usually resumes several seconds after continuing past the breakpoint. The AVAudioSessionMediaServicesWereResetNotification is not posted.
Is this expected behavior, or does it indicate a problem? Is there any way to avoid it? If you are using MTAudioProcessingTap and regularly encounter this, has it been an issue for your development or debugging process?
(I'd also be interested in any feedback on whether MTAudioProcessingTap is ready for primetime generally, since it's a relatively new and lightly documented component.)
Thanks in advance!
Related
First off, I'm on iOS 13.6.1
I'm downloading HLS videos to later play offline. It all works as expected when in foreground, all the logic does what it should and there doesn't seem to be any problem.
But when the app goes to background I stop getting updates for the AVAggregateAssetDownloadTask (I mean, I don't see the logs in the delegate callbacks printing in the Xcode console).
I followed the documentation:
NSURLSessionConfiguration sessionSendsLaunchEvents is set to true
The AppDelegate implements handleEventsForBackgroundURLSession
The Session delegate implements URLSessionDidFinishEventsForBackgroundURLSession
Also, I have background modes enabled for fetch.
The crazy thing is, if I hook up the instruments network monitor, I do get all the updates. And I see that the download keeps going in the background.
Even without the changes mentioned in the documentation indicated above, I still see that the download keeps going in the background with the monitor open.
But it seems that the network monitor keeps the app alive somehow, because if I don't open it, then I get zero updates.
To be clear, I'm not even thinking about downloads starting or finishing in the background, and waking the app or anything of that. I just want to start a download, go to the background and have the download keep downloading stuff and notifying me (which AFAIK is done in a separate process, and I can confirm from the network monitor it is).
An example:
open the app
start a download
go to background
no updates are shown
open the instruments network monitor and connect to the app running in the device
suddenly start getting updates
I'm running out of ideas. Nothing makes sense anymore, short of a bug in the framework.
Any sort of idea will be greatly appreciated, no matter how simple it may appear.
Thanks in advance!
PS: when going to settings>storage I sometimes see that the file size grows while in the background, which would mean that the download is continuing even if I don't see updates from the delegate callbacks. At some points I saw the file size unchanged over a period of background time, but that might have been an unrelated thing (I hope).
I was testing my app in the simulator when suddenly this error appeared on the console. I have no idea what it even relates to - whether it's Firebase, local notifications, or something else. I can't find any information about it online either. Does anybody know what this error means?
[BackgroundTask] Background Task 17 ("APMAnalyticsMeasurementBackgroundTask"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.
Problem
I am using Haptic Feedback in my app for when the user moves some tiles. When the tiles are moved very quickly, causing the haptic feedback to trigger quickly, I get this warning in the console after 30 seconds:
2019-01-20 17:29:04.658240+0000 Loopover[17824:4937487] [Feedback] AVHapticPlayer async call finishWithCompletionHandler: (type=3) did not get a reply after 30 seconds (notified of 0 mediaserverd death(s) in this time)
How is the Haptic Feedback triggered?
I am triggering the Haptic Feedback using UIImpactFeedbackGenerator as shown:
UIImpactFeedbackGenerator(style: .light).impactOccurred()
What does this mean?
Is this warning something I should be worried about? If I move the tiles normally, no problems occur.
What should I do, if anything?
Is this warning something I should be worried about? What should I do, if anything?
I guess no, and none. In Apple's doc about UIFeedbackGenerator https://developer.apple.com/documentation/uikit/uifeedbackgenerator, they say you should "Trust the system" about that.
Talking about methods like impactOccurred():
Note that calling these methods does not play haptics directly.
Instead, it informs the system of the event. The system then
determines whether to play the haptics based on the device, the
application’s state, the amount of battery power remaining, and other
factors.
Haptic feedback is currently played only:
On a device with a supported Taptic Engine
When the app is running in the foreground
When the System Haptics setting is enabled
And about the "Trust the system":
As a general rule, trust the system to determine whether it should
play feedback. Don't check the device type or app state to
conditionally trigger feedback. After you’ve decided how you want to
use feedback, always trigger it when the appropriate events occur. The
system ignores any requests that it cannot fulfill.
I hope this helps!
I'm debugging a background task issue where my app is being killed by the watchdog when socket data is received too often in the background.
Does the watchdog perform it's operations under the context of a debugger?
My answer is: I do not believe so.
Based on some logs I have seen about apps failing to respond for 10 seconds while paused in the debugger, I would say yes it is watching, but it does not enforce its rules. It simply informs you.
I have an application that handles applicationWillResignActive and applicationDidBecomeActive notifications by doing stuff like pausing/unpausing BG music, etc.
I am experiencing a weird bug, in which in every 3-4 times becoming inactive and returning (e.g. locking/unlocking the device), the app seems to be completely stuck for a few minutes - meaning, I see the view I'm supposed to see, but I can't touch anything, and music isn't playing.
I debugged it, and it seems that the applicationDidBecomeActive notification is not getting called what so ever.
I looked at the log of my app and literally didn't see anything there for the entire time the app seemed stuck.
The only interesting thing is that in the device's console I could see this line appearing about 10 seconds after I unlock the device and noticing the stuck application.
Mar 20 11:51:13 unknown MobileStorageMounter[4882] <Notice>: (0x3f4d948c) idle_timer_callback: Exiting after idle timeout
Not sure if it's related.
Anyone had a similar problem?
It could be that a call to TestFlight is timing out, and prior to the timeout the app locks the main thread, which freezes the interface, until the request is processed or times out. This could happen if the request failed to complete before the system pushed the app into an inactive state, meaning that when it returns to an active state it would still be trying to listen for a response to the request that it will never receive, hence the timeout. The same can occur with Flurry Analytics (at least older versions of the SDK that I have used), and they happen to me as well when calling my own homemade API's and API responses are delayed by a second or two.
Turns out it was a bug in the TestFlight SDK, upgraded from 0.8.2 to 0.8.3 and problem was solved