A try to start a screen recording with RPScreenRecorder. I got the following error:
Recording interrupted by multitasking and content resizing
func startRecording() {
let recorder = RPScreenRecorder.shared()
recorder.startRecording(handler: { (error) in
if let unwrappedError = error {
print(unwrappedError.localizedDescription)
} else {
}
})
}
Before iOS 12.0 everything worked fine. From the update I get the error above.
My app has been rejected from App store for the same reason. So far the only workaround is to reboot the device.
I had a similar problem and here is how I solved it.
go to project then targets then capability switch on Background mode then enable audio and VOIP. It should work
I've done a lot of research on the errors and posted the solution Here.
For now my screen recording feature is bug free. But who knows what comes with the new OS updates
We've been rejected same issue several times.
But we found a senario to re-produce as bellow,
We reported it on Resolution Center in App Store Connect, then passed.
connect iOS(12.4) device to host launched XCode 10.3
(regardless of opened related project)
cold boot iOS device.
launch app and start recording video ASAP(until 30sec after booted)
Now iOS13, we don't face this error at the above senario.
Related
I'm quite new into flutter and coding in general. I'm trying to build a meditation app, that plays a bell every 30/60/120... seconds, depends on user input. My code works perfectly fine on Android device, but when running on iOS, it plays bell only once and doesn't play anymore. Any suggestions please? Thank you!
if (((widget.meditation.notification) != 0) &&
((_time % widget.meditation.notification) == 0)) {
print('notification $_time');
audioCache.play('audio/bell.wav');
}
Finally I found solution, simply everytime .release() must be called.
By default, the player will be release once the playback is finished or the stop method is called.
This is because on Android, a MediaPlayer instance can be quite resource-heavy, and keep it unreleased would cause performance issues if you play lots of different audios.
On iOS and macOS this doesn't apply, so release does nothing.
Having a weird problem with my app.
Trying to play a video in a loop (see the code below). VideoPlayer repeatMode is set to Ti.Media.VIDEO_REPEAT_MODE_ONE.
Works in simulator, works on iPhone 4s, works on iPad Air... does not work on iPhone 4 (all of them running iOS 7.1.1 apart from simulator - 7.1).
Exact symptoms: after one play, video should restart from beginning, but it stops. If controls are available, I can press play to start playing it again, then after reaching the end it stops again.
I could swear that it worked on iPhone 4 before the 7.1 upgrade, but somehow it stopped.
Anyone could replicate this issue? Or have any idea?
Sys info:
Titanium SDK: Tested with 3.2.3.GA; 3.2.2.GA; 3.2.1.GA; 3.2.0.GA
Platform & version: iOS 7.1.1 (11D201)
Device: works on iPhone 4s, iPad Air, simulator; fails on iPhone 4
Host Operating System: OSX 10.9.2
Titanium Studio: 3.2.3.201404181442
Xcode: 5.1.1 (5B1008)
Alloy: 1.3.1
Code for basic Alloy project to replicate:
index.js
var videoPlayer = Titanium.Media.createVideoPlayer({
autoplay : true,
fullscreen : false,
mediaControlStyle : Titanium.Media.VIDEO_CONTROL_DEFAULT,
repeatMode: Ti.Media.VIDEO_REPEAT_MODE_ONE,
scalingMode : Titanium.Media.VIDEO_SCALING_ASPECT_FIT
});
//Video is 12s long so it is easy to notice that it does not loop.
videoPlayer.url = "video/candles.mp4";
$.index.add(videoPlayer);
$.index.open();
index.xml
<Alloy>
<Window class="container">
</Window>
</Alloy>
I would appreciate any suggestions.
I have done some research and played around with the Titanium.Media.VideoPlayer and managed to work around the issue. Below you can find the solution in case anyone else encounter this problem.
First of all, some info on the problem.
I have found some forum boards where developers were having very similar problem with MPMoviePlayerController on iPad 1st gen. Looped video was less or more randomly freezing on loop. So I think there is a problem with the Apple video player on some devices, and not necessary with Titanium implementation.
My first approach was to try replay video on complete event that is fired when video stops playing, instead of using repeatMode.
So far so good. It worked on the first time, yay! But the happiness was rather short. During an hour of test of videoPlayer.play() on event complete, the video sometimes was repeating 10-30 times fine and then suddenly was freezing. What gives? Turns out the video player had some sort of a hiccup.
Normal sequence of events was as follows:
video ends, playbackstate changes to 2,
complete event is fired
I restart video on complete
playbackstate changes to 1, video is playing until the end.
For a mysterious reason once in a while this sequence got additional something happening:
video reaches the end - playbackstate changes to 2,
complete event is fired.
video gets restarted on complete
playbackstate changes to 1, video starts playing
suddenly playbackstate changes to 1, video stops, without firing complete event.
Solution
So, knowing all this, I have set up listeners to listen to playbackstate instead of complete and when I hear playbackstate: 1 then I restart video and tadaaa! Everything works!.
Caveat: not 'everything' unfortunately. I am using custom video controls, so I have lost pause, and stop ability (every time video playback state changes to 'stopped' I restart it forcefully). To make it work I have to remember to remove listener every time I press 'pause/stop' buttons and then reattach it afterwards.
Hope that helps someone.
I'm trying to implement a gamecenter aware app targeted to iOS 6. To give some info on the environment I'm working on mac os 10.7.5 with XCode version is 4.5.2 and xcode is running iphone and ipad simulator version 6.0. The problem is I cannot connect to gamecenter in sandbox mode neither through ipad or iphone simulator, but the same code works as desired while testing in my iphone.
I followed the gamecenter programming guide in apple's developer library and I got this atm it is called from applicationDidFInishLaunching in appdelegate:
- (void)authenticateLocalUser:(UIViewController *)currentViewController
{
if (!gameCenterAvailable) return;
GKLocalPlayer *localPlayer = [GKLocalPlayer localPlayer];
localPlayer.authenticateHandler = ^(UIViewController *viewController, NSError *error){
if (viewController != nil)
{
[currentViewController presentViewController:viewController animated:YES completion:nil];
}
else if (localPlayer.isAuthenticated)
{
NSLog(#"Player authenticated");
}
else
{
NSLog(#"Player not authenticated");
}
NSLog(#"Error: %#",error);
};
}
It outputs:
Error: Error Domain=GKErrorDomain Code=2 "The requested operation has been cancelled."
UserInfo=0x8690510 {NSLocalizedDescription=The requested operation has been cancelled.}
GKSConnSettings: set server: {
"gk-cdx" = "17.173.254.218:4398";
"gk-commnat-cohort" = "17.173.254.220:16386";
"gk-commnat-main0" = "17.173.254.219:16384";
"gk-commnat-main1" = "17.173.254.219:16385";
}
I already tried hosts file fix though my OS is not 10.8.2 but it didn't help. https://devforums.apple.com/thread/168811?tstart=0
Any idea what can be the possible cause?
Edit: Well, it turns out the output part starting with GKSConnSettings does not indicate any problems, that's the regular output while connecting to game center as I understood from what I read over internet. I printed the actual error message (GKErrorDomain = 2 ...) inside the authentication block.
I got the inspiration from : https://stackoverflow.com/a/8115807/837244, and decided to log in to game center account with a different piece of code. So in viewdidload I normally called:
[[GCHelper sharedInstance] authenticateLocalUser:self];
Now I commented that out, accessed game center through below URL scheme, logged in to my account and after that logged out.
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:#"gamecenter:"]];
And lastly reverted back by commenting out URL code and using the original code. Now it works fine, I guess the problem was that a game center account was already hooked up in simulator and it denied every login request bc of that. Hope apple goes clearer with error messages, it took a month to fix such a simple issue, may this help to others.
I know this question references specific Xcode and iOS simulation versions, but if your simulator is already logged in one account, and you don't mind losing whatever data you've got on the simulator (chances are small, but you never know), you can simply reset the settings and data on it.
Go to:
Simulator -> Reset Content and Settings...
...and confirm the action when prompted.
This is certainly true for Xcode7.x running an iOS 9.x simulator, someone else might be able to verify whether it's true for earlier versions (especially as I've unearthed quite an old question and answer).
Animal451
Necrothreadomancy: +1
I set the audio session category to kAudioSessionCategory_MediaPlayback, I active the session, which returns no errors, and still the iPod music stops when I lock the device. This happens on iOS 5 GM, so I guess this will happen in the final version. On iOS 4+ the current code works fine. Any ideas how to fix this? Huge thanks :)
It's not a bug. To save power locking the phone is now treated as if the user pressed the home button. The fact that applicationMusicPlayer stops now when locking is just a side effect of this change.
To work around this problem you should switch to AVPlayer and make use iOS 4's audio in background mode.
Fixed this issue for my particular problem - how to detect the difference between OS4 and OS5 behavior when device gets to the Lock screen.
In OS4 app does 'applicationWillResignActive' but on OS5 it goes all the way to 'applicationDidEnterBackground' which looks exactly the same as the user hitting the Home button.
It turns out that if you check the UIApplicationState of the application given in '- (void)applicationDidEnterBackground:(UIApplication *)application', it has 3 possible values:
typedef enum {
UIApplicationStateActive,
UIApplicationStateInactive,
UIApplicationStateBackground
} UIApplicationState;
When the user hits home on OS5, you get UIApplicationStateBackground, but when the user hits Lock, you get UIApplicationStateInactive.
Hope that helps.
Happy Holidays everyone.
I have used:
[UIApplication sharedApplication].idleTimerDisabled = YES;
in a number of Apps developed and running under iPhone OS 2.x and never had any problems with it. They were clock apps so needed to run constantly and ignore the iPhone's idle Timer setting.
However, trying to achieve the same with a new App running OS 3.0 (and which needs to be deployed under 3.0 as it uses some 3.0 APIs) I've found the idle Timer to be either ignored or inconsistent.
My App plays music from the iPod library and when the music is playing it auto-locks regardless of the above setting. But once you unlock it, it then doesn't auto-lock again unless you play music again, in which case it locks again after the iPhone auto-lock time setting.
I'm amazed no-one else has come across this as I imagine it would affect a large number of Apps.
Just to clarify:
1. The above code is in ApplicationDidFinishLaunching
2. I know that the phone won't auto-lock when testing from xCode regardless of settings
If anyone has any thoughts I'd be very grateful...
Our app uses the MPMediaPLayer. We also had the idleTimerDisabled=YES code in the ApplicationFinishedLaunching, which works EXCEPT if untethered, and there is already a current nowPlayingItem which is left playing (or unpaused, if paused at app startup). Obviously this is all with the Settings -> General -> Autolock set to some timed value.
By adding idleTimerDisabled=NO, immedately followed by idleTimerDisabled=YES in one of the other bits of code AFTER we had figured out what bit of music we would get playing seemed to solve the problem. Just setting it to YES was insufficient.. and subsequent queries had always indicated the correct value (YES).. so it appears the Apple code ignores the setting of the value IF there is a current piece of music and that is not changed by your code.. but does notice a change of value.
This is all under iOS 3.0.
Even in 2015, using iOS 8.2, this bug is still alive and kicking.
Here's my solution, using XCode 6.2.
iPhone - phone goes to sleep even if idleTimerDisabled is YES
Basically, even now, in 2015, the only way to safely make sure that the device doesn't go to sleep is to repeatedly call a piece of code to keep the device awake.
-(void)callEveryTwentySeconds
{
// DON'T let the device go to sleep during our sync
[[UIApplication sharedApplication] setIdleTimerDisabled:NO];
[[UIApplication sharedApplication] setIdleTimerDisabled:YES];
}
Sounds like a bug, file with Radar - I am not too surprised this has not been seen much as there are probably not a lot of apps that try to lock the screen open and play music.
Having same issue. It does work when the device is plugged in. You can press lock button on top, and my NSTimer fires later and causes a vibrate. However if the device is not plugged in pressing the lock button puts the device to sleep. Any solution would be greatly appreciated.
iCodeblog posted about the idletimer, I said it didn't work, and the person who develops 'cute clock' was nice enough to reply. You have to do a hack, play a 1 second or longer silent sound every 10 or so seconds with NSTimer. This keeps the device awake even if the user hits the lock button.
I develop Seconds - Interval Timer for iPhone and iPod touch and I've had no end of trouble with this. The idea of my app is that people create timers based on a number of intervals where each interval can have it's own playlist or track played.
In iOS3 I had the problem that I couldn't disable the idle timer by just setting idleTimerDisabled = YES. In the end I came up with the same solution as Neil whereby I would periodically set it to NO, then immediately to YES again. This seemed to work.
I'm now updating the app to iOS4 (I know, iOS5 is just around the corner...) and now I have the opposite problem. If the MPMediaPlayer changes track before the idle timer reaches it's limit it gets reset. I've just tested this by creating an interval in my app that was 55 seconds, my auto-lock was set to a minute. At 50 seconds the screen dimmed as it prepared to lock, but at 55 seconds when the music changed it went back to full brightness and then didn't lock as it should.
Overall, the implementation of this seems flakey at best.