I have created a sample project in choreograph which is responsible for playing a video on pepper's tablet, it works nicely in choreograph. now i packaged and uploaded it on the robot and called this behavior (by albehaviormanger) in my python code as following:
behaviormanager = session.service("ALBehaviorManager")
if (behaviormanager.isBehaviorRunning(choregraph_Code)):
behaviormanager.stopBehavior(choregraph_Code)
behaviormanager.runBehavior(choregraph_Code)
It works but sometimes the video stopped suddenly, in every single run in a different moment! so whats the problem with it?
also I tried to play videos from net by:
tabletService.enableWifi()
tabletService.loadUrl(url)
tabletService.showWebview()
but after some time it stops too
so does any one know what's a problem?
Most likely your problem here is that Autonomous Life is resetting the tablet. And that happens because Autonomous Life doesn't know that your behavior is running.
Autonomous Life has the concept of "focused activity"; of which there can only be one at a time (lower priority activities will not be started, and when a higher activity priority is started, the lower priority one will be stopped). Between activities, Autonomous Life resets the tablet, but won't do so inside an activity.
So instead of doing ALBehaviorManager.runBehavior, you should use ALAutonomousLife.switchFocus (with the same behavior path as a parameter), and AutonomousLife won't reset your tablet.
(Not all behaviors are intended to be activities; some activities have sub-behaviors, and some behaviors may be expected to be running quietly in the background without getting the focus - that's not a good practice, but sometimes happens)
Related
I have been working for 2.5 years on a personal flight sim project on my leisure time, written in C++ and using Opengl on a windows 7 PC.
I recently had to move to windows 10. Hardware is exactly the same. I reinstalled Code::blocks.
It turns out that on first launch of my project after the system start, performance is OK, similar to what I used to see with windows 7. But, the second, third, and all next launches give me lower performance, with significant less fluidity in frame rate compared to the first run, detectable by eye. This never happened with windows 7.
Any time I start my system, first run is fast, next ones are slower.
I had a look at the task manager while doing some runs. The first run is handled by one of the 4 cores of my CPU (iCore5-6500) at approximately 85%. For the next runs, the load is spread accross the 4 cores. During those slower runs on 4 cores, I tried to modify the affinity and direct my program to only one core without significant improvement in performance. The selected core was working at full load, though.
My C++ code doesn't explicitly use any thread function at this stage. From my modest programmer's point of view, there is only one main thread run in the main(). On the task manager, I can see that some 10 to 14 threads are alive when my program runs. I guess (wrongly?) that they are implicitly created by the use of joysticks, track ir or other communication task with GPU...
Could it come from memory not being correctly freed when my program stops? I thought windows would free it properly, even if I forgot some 'delete' after using 'new'.
Has anyone encountered a similar situation? Any explanation coming to your minds?
Any suggestion to better understand these facts? Obviously, my ultimate goal is to have a consistent performance level whatever the number of launches.
trying to upload screenshots of second run as viewed by task manager:
trying to upload screenshots of first run as viewed by task manager:
Well I got a problems when switching to win10 for clients at my work too here few I encountered all because Windows10 has changed up scheduling of processes creating a lot of issues like:
older windowses blockless thread synchronizations techniques not working anymore
well placed Sleep() helps sometimes. Btw. similar problems was encountered when switching from w2k to wxp.
huge slowdowns and frequent freezes for few seconds on older single threaded apps
usually setting affinity to single core solves this. You can do this also in task manager just to check and if helps then you can do this in code too. Here an example on how to do it with winapi:
Cache size estimation on your system?
messed up drivers timings causing zombies processes even total freeze and or BSOD
I deal with USB in my work and its a nightmare sometimes on win10. On top of all this Win10 tends to enforce wrong drivers on devices (like gfx cards, custom USB systems etc ...)
auto freeze close app if it does not respond the wndproc in time
In Windows10 the timeout is much much smaller than in older versions. If the case You can try running in compatibility mode (set in icon properties on desktop) for older windows (however does not work for #1,#2), or change the apps code to speed up response. For example in VCL you can call Process Messages from inside of blocking code to remedy this... Or you can use threads for the heavy lifting ... just be careful with rendering and using winapi as accessing some winapi (any window/visual related stuff) functions from outside main thread causes havoc ...
On top of all this old IDEs (especially for MCUs) don't work properly anymore and new ones are usually much worse (or unusable because of lack of functionality that was present in older versions) to work with so I stayed faith full to Windows7 for developer purposes.
If none of above helps then try to log the times some of your task did need ... it might show you which part of code is the problem. I usually do this using timing graph like this:
both x,y axises are time and each task has its own color and row in graph. the graph is scrolling in time (to the left side in my case) and has changeable time scale. The numbers are showing actual and max (or sliding avg) value ...
This way I can see if some task is not taking too much time or even overlaps its next execution, peaks are also nicely visible and all runs during runtime without any debug tools which might change the behavior of execution.
I need some help deciding which classes to adopt in my app that has to fulfill these requirements:
Firing of the alarms at exact times (down to the second)
Can have multiple alarms in the system (triggering at different times).
Should awaken the device if asleep and keep it awake until the user completes a defined task.
Should run on as many Android versions as possible, at least from 4.0 and up (the fact that you can use an old phone to run this app is a plus).
I've coded a small demo with AlarmManager & BroadcastReceiver to get an understanding of how all of this works. I've studied the docs for AlarmManager, BroadcastReceiver, WakefulBroadcastReceiver, and JobScheduler and even though I understand the differences, I don't know which one(s) will satisfy my requirements.
From the documentation, I get the impression that I might need to write multiple versions of my app to accommodate the different Android versions it will run on. This would be a nightmare!
Any suggestions on which classes to use? I would hate to go in one given direction only to later find out that I need to rewrite everything.
Thanks!
You don't need multiple versions of your app, you just need multiple "scheduler" implementations, each with just a couple files, and all call the same app logic.
Firing of alarms at exact times (down to the second)
Well, there's only one option that handles this. You need an AlarmManager.setExact. This is strongly discouraged, because it tends to waste battery.
Can have multiple alarms in the system (triggering at different times).
Every option there handles that, as long as you give them different ids.
Should awaken the device if asleep and keep it awake until the user completes a defined task.
Sounds like you need to have your alarm call Context.StartForegroundService, and leave that foreground service running until the user completes the task. Again, this is discouraged, because it wastes battery.
Should run on as many Android versions as possible, at least from 4.0 and up (the fact that you can use an old phone to run this app is a plus).
AlarmManager and foreground services run on all versions of Android, though the call to start a foreground Service has changed slightly with Android O, the concept is identical.
While your app is doing something important that needs to execute RIGHT NOW, even if the screen is off, then you should grab a wakelock. A wakelock prevents the CPU from pausing itself, so that you can process what needs to immediately occur. If the code can wait until the screen is turned on, then please do not use a wake lock. JobService grabs a wakelock always, so JobService code does not need to grab a separate wakelock. If you have no service running, including a JobService, then Android will randomly stop your app, even if you have a wakelock. So you always need a service of some sort, while doing any important work.
Is there some type of notifications that iOS emits when app get force quited?
By force quite i mean tapping the home button while app is in active state and then removing it from multitasking menu.
I want to be able to detect force quit, to gracefully handle everything.
We have an issue like this with one of our games and our publisher wants us to handle this.
This is not standard Cocoa App, this is game ported from PC, written mostly in C++.
This happens only on iPad Mini 2nd gen, when app is force quit-ed it will crash on next launch.
On other devices, when app is activated it will load up properly and continue with proper scene loading order.
Does iPad mini 2nd gen has something different from other devices regarding development?
Crash logs says that app crashes immediately after force quit, well duh...
- (void)applicationWillTerminate:(UIApplication *)application
is not really useful, it doesnt detect force app quit.
The idea is that your app should handle termination the same regardless of whether it was initiated by the operating system or by the user. You are encouraged to save the app's state and reload on the next start. And it's probably a good idea to save state when your app is sent to the background because according to the second paragraph below, applicationWillTerminate is not always called when the system kills your app.
According to the documentation
This method lets your app know that it is about to be terminated and purged from memory entirely. You should use this method to perform any final clean-up tasks for your app, such as freeing shared resources, saving user data, and invalidating timers.
Also
For apps that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the app. For apps that support background execution, this method is generally not called when the user quits the app because the app simply moves to the background in that case. However, this method may be called in situations where the app is running in the background (not suspended) and the system needs to terminate it for some reason.
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
Any ideas about why it could be so slow will be greatly appreciated!
EDIT:
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue
Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.
As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.
So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.
As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.
Same issue with Corsair K70 Keyboard.
Quickly reconnecting keyboard fixes this, until next time. Usually happens after some DirectInput devices removed from the system or go to sleep.
This has been plaguing me as a developer and my friend as a user for years. All games using DInput, SDL SDL_INIT_JOYSTICK or anything depending on that, took extremely long to initialize.
It was caused by a faulty driver of a DAC, and as pointed out by DaFox, disabling the corresponding USB Input Device resolved the issue. Although it's labeled with a different manufacturer name, the vendor IDs match.
The hardware ID of the device is USB\VID_262A&PID_9023&REV_0001&MI_00.
Same issue appears to happen with a Steelseries Apex 7 keyboard. Unplugging and plugging that keyboard back again got rid of 3 freezes (of 10 seconds each) while enumerating USB devices.
Does the N900 allow me to display additional information in parallel to the native application or does the latter always have priority over my process?
I'm interested in displaying additional information based on caller id.
If it's possible, can you name any pitfalls or give small python code examples / or tipps to get started?
detecting incoming call might be the smallest problem you will see in this journey - you can start with this thread
now consider few other factors before you decided whether you want to continue or not:
calls come not only as phone call but also as SIP call, Skype call, GTalk call, etc
call signaling is relatively resource-heavy due to time constraints vs blocked by I/O, etc
call dialog should work ok in portrait and landscape, so you might need to go down extending call architecture not writing my own little thing in 1-2 weekends
internal eMMC storage is not quick and gets slow on 2+ threads trying to write
if you are Ok with risk to spent time and bump into limitations of Maemo5 platform put on end-of-lifecycle hook -- consider learning down googleing keywords maemo5 telepathy mission-control . this is starting point not definitive guide -- you have to learn quit many different things before you start to approach plugging call progress dialogs.