What is the reason for the below function returning onResult with dji error (drone and remote are connected), usually it works but fails from time to time...
calling: DJISDKManager.getInstance().getProduct().getCamera().setMode(SettingsDefinitions.CameraMode.MEDIA_DOWNLOAD,listener)
result: Execution of this process has timed out(255)
Related
Ive got a problem when trying to create a new visual for a query (source is Google BigQuery).
I'm using a similar query, that is already working (but with an extra filter), making the new query take a little longer.
It runs for about 10 minutes, and return this error message:
Details: "ODBC: ERROR[HY000] [Simba][BigQuery] (115) Operation timeout.PollJob"
So add an time limit parameter: "connect timeout=10000", but it doesnt work neither.
driver={Simba ODBC Driver for Google BigQuery};oauthmechanism=1;refreshtoken=TOKEN;catalog=mm-datamart-kd;connect timeout=10000
If someone get the error or have a solution for this error message. I would be grateful if you give me your advised.
Thanks!
I'm attempting to play a live stream on ChromeCast. The stream is thrown fine and starts playback appropriately.
However when I play the stream longer: somewhere between 2-15 minutes, the player stops playing and I get MediaStatus.IDLE_REASON_ERROR in my RemoteMediaClient.Callback.
When looking at the console logs from ChromeCast I see that 3-4 calls are failed. Here are the logs:
14:50:26.931 GET https://... 0 ()
14:50:27.624 GET https://... 0 ()
14:50:28.201 GET https://... 0 ()
14:50:29.351 GET https://... 0 ()
14:50:29.947 media_player.js:64 [1381.837s] [cast.player.api.Host] error: cast.player.api.ErrorCode.NETWORK/3126000
Looking at Cast MediaPlayer.ErrorCode Error 312.* is
Failed to retrieve the media (bitrated) playlist m3u8 file with three retries.
Developers need to validate that their playlists are indeed available. It could be the case that a user that cannot reach the playlist as well.
I checked, the playlist was available. So I thought perhaps the server wasn't responding. So I looked at the network calls response logs.
Successful Request
Stalled Request
Note that the stall time far exceeds the usual stall time.
ChromeCast isn't making these calls at all, the requests are simply stalled for a long time until they are cancelled. All the successful requests are stalled for less than 14ms (mostly under 2ms).
The Network Analysis Timing Breakdown provides three reasons for stalling
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
While I do believe the first one should not be the case, the later two can be. However in both cases I believe the fault lies with cast.player.
Am I doing something wrong?
Has anyone else faced the same issue? Is there any way to either fix it or come up with a work-around.
I am doing a method where I am using 2 Parse.Cloud.httpRequest calls, with one being inside of the other. However, this method seem to fail with an alarming frequency. Like 1 in 5 tries, each time the error is:
Request failed with response code 500
{"uuid":"bc75e304-8964-30f9-c9d5-92fabf02f624","status":500,"error":{"code":-1,"error":"Request timed out"},"headers":{},"text":"{\"code\":124,\"error\":\"Request timed out\"}","cookies":{}}
I looked up code 124, and it corresponds to
Timeout 124 Error code indicating that the request timed out on the server. Typically this indicates that the request is too expensive to run.
I am only running a couple REST requests per minute and the run of the method does not exceed 3 seconds. I checked the same calls via REST and there is never any problems.
What's the cause for this problem and can I fix it by upgrading my parse account?
I tried with this below code to find out whether the webpage is opened or not, but this code is not working for me. System is just flashing only the first opened webpage URL.
surl ="http://www.google.com/"
set shapp=createobject("shell.application")
For Each owin In shapp.Windows
msgbox owin.document.location.href
if Instr(1,owin.document.location.href,surl)>0 then
msgbox "Window opened"
end if
Next
set shapp=Nothing
The error message is:
Script execution time was exceeded on script "D:\ie_open.vbs" Script execution was terminated
Given the error message "Script execution time was exceeded ...", the problem may be caused by a too small time out. See here. Use something like:
cscript //T:0 "D:\ie_open.vbs"
to test this assumption.
A default timeout value can be stored in the registry in either of the following locations:
HKCU\Software\Microsoft\Windows Script Host\Settings (per user)
HKLM\Software\Microsoft\Windows Script Host\Settings (global)
Deleting the Timeout value removes the preset timeout.
Instead of owin.document.location.href Use oWin.locationURL
I'm having trouble with an old legacy app that recently started crashing. I'm trying to investigate the DebugDiag analysis, but don't have much luck. Either there is a sql query that locks and somehow the calling thread doesn't die away? Then again callstack points to oledb32!CImpIErrorInfo::GetHelpFile+a1.
Here's the info from DebugDiag which I think is relevant to this problem:
The following threads in w3wp.exe_MyApp_PID_7572_Date__10_21_2010__Time_08_43_22AM_720_Manual Dump.dmp are making a database operation using ADO.
The call to MSADO15!CERRORLOOKUP::GETHELPINFO originated from oledb32!CImpIErrorInfo::GetHelpFile+a1
...clip...clip...
Thread 17 - System ID 4160
Entry point msvcrt!_endthreadex+2f
Create time 21.10.2010 0:08:16
Time spent in user mode 0 Days 00:11:22.781
Time spent in kernel mode 0 Days 00:27:49.953
This thread is making a database operation using ADO.
The call to MSADO15!CERRORLOOKUP::GETHELPINFO originated from oledb32!CImpIErrorInfo::GetHelpFile+a1
Function Source
ntdll!GetUILangID+31
ntdll!LdrpSearchResourceSection_U+186
ntdll!LdrFindResource_U+18
kernel32!FindResourceExW+65
user32!LoadStringOrError+31
user32!LoadStringW+18
msado15!FetchInfo+ba
msado15!CErrorLookup::GetHelpInfo+1e
oledb32!CImpIErrorInfo::GetHelpFile+a1
msvbvm60!ExecProj::SetModuleCount+a
msvbvm60!CEcProjTypeComp::Release+4
msvbvm60!RcmConstructModuleInstance+8f
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!_vbaPrintObj+51
MSWCRUN!DllUnregisterDesigner+8ad3
MSWCRUN!DllUnregisterDesigner+accb
MSWCRUN!DllUnregisterDesigner+af8c
MSWCRUN!DllUnregisterDesigner+a7de
MSWCRUN!DllUnregisterDesigner+7b51
MyApp!DllCanUnloadNow+212e
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!_vbaPrintObj+51
MSWCRUN!DllUnregisterDesigner+8ad3
MSWCRUN!DllUnregisterDesigner+7d13
MSWCRUN!DllUnregisterDesigner+6e64
MSWCRUN!DllUnregisterDesigner+9097
MSWCRUN!DllUnregisterDesigner+8fa6
vbscript!IDispatchInvoke2+b2
vbscript!IDispatchInvoke+59
vbscript!InvokeDispatch+13a
vbscript!InvokeByName+42
vbscript!CScriptRuntime::RunNoEH+234c
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34
...clip...clip...
Client connection from 194.241.111.228:26238 to 81.175.250.2:80
Host Header 81.175.250.2:80
GET request for /MyApp/netk.asp
HTTP Version HTTP/1.1
SSL Request False
Time alive 00:49:33
QueryString
Request mapped to
HTTP Request State HTR_READING_CLIENT_REQUEST
Native Request State NREQ_STATE_PROCESS
Hard to say, but I'd start with throwing ProcessMonitor/RegMon/FileMon/TcpViewer from live.sysinternals.com. Fiddler wouldn't be a bad idea either.
Then, if you still get no clues, I'd break out WinDBG, which is always my nuclear option, because the learning curve is so massive. But, assuming, you learn the commands, you could break on the crash, then walk the stack backwards and potentially figure out where the error is coming from.
And of course, you could just reinstall everything and that will probably solve all your problems.