SikuliX

Sikuli java script instability

Asked by Sabir

Hi,

We are running complex Java Sikuli code inside a Docker container, with the following specification :

Sikuli 1.1.2
Java : openjdk version "1.8.0_171"
System : Ubuntu 16.04.4 LTS
Xfce Desktop 4.12
Docker 18.09.0
Sikuli WaitScanRate: 5
Sikilu MinSimilarity: 0.7
-Dsikuli.Debug=3

We are testing an Angular web application running in Chromium Version 64.0.3282.167

While searching for images, we avoid searching in the whole screen and we give enough wait time for Sikuli to do its work. We use only region.exits methods (not wait or found). We have implemnted almost all the Sikuli best practices we found in the documentation and elsewhere...

Each test suite is run inside a fresh and distinct Docker container, and we launch up to five suites (hence maximum of five containers, but usually one or two container) on the same Docker machine, on the same time. No CPU or memory issues were observed.

Randomly and in different code methods, we get image not found :-(

Evry time an image is not found we take a whole screenshot for debugging. When we re-run the same image search, in the same env (In the same Docker), on machine developper, using the taken debug screenshot, and the same searched image, we are not able to reproduce the unfound image search :-( And we do not have enough details with "-Dsikuli.Debug=3"

How to get more details and logs about what Sikuli is doing and what change from execution to another?
Is there any technique to let Sikuli save its own screenshot where it searched after an image search failure?
Could any lack of graphical ressources impact Sikuli work? How to debug that?
Could any lack of physical resources (CPU/Memory) impact Sikuli image search? (we are not able to reproduce the bug....)

We spent days of investigation to make this code stable :-( and any suggestions or advices are more than welcome.

Many Thanks.

Question information

Language:
English Edit question
Status:
Answered
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
masuo (masuo-ohara) said : 		#1

Do you mean there is an image in the screenshot you take when an image is not found?

Revision history for this message
Sabir (issamx) said : 		#2

No. For more debug, I take a screenshot of the page where Sikuli was not able to find the Image I search... just for debugging purpose....

Revision history for this message
masuo (masuo-ohara) said : 		#3

example to capture screenshot when the image do not appear

import datetime
import shutil
SCREENSHOT = getBundlePath()+"\screenshot"

#---------------------------
def capture_screen():
    tmppath = SCREEN.capture(SCREEN.getBounds()).getFile()
    capturefile = datetime.datetime.today().strftime("%Y%m%d-%H%M%S") + ".png"
    savepath = os.path.join(SCREENSHOT, capturefile)
    shutil.move(tmppath, savepath)

#---------------------------
if not exists("image.png",5):
    capture_screen()

Revision history for this message
Sabir (issamx) said : 		#4

Thx for your help. But taking the screenshot is not my problem :-(

My issue is :
Randomly and in different code methods, we get image not found :-( I'm looking for ways to debug what's happening and to make my code more stable. I laready followed all best practices of Sikuli, and did not get yet the reason of this instability.

Thx again

Revision history for this message
RaiMan (raimund-hocke) said : 		#5

--- I laready followed all best practices of Sikuli, and did not get yet the reason of this instability.
Then the last possible reason is, that in those situations the image does not appear within the given wait time (3 seconds in the standard).
Settings.AutoWaitTimeout = 5.0; //increase to 5 seconds

As a general advice: switch to the latest SikuliX version 2.0.0 (latest stable on MavenCentral)
This is the release version of the latest 1.1.4-SNAPSHOT.

BTW:
Sikuli WaitScanRate: 5
... might be a misunderstanding and does not maske sense in your situation anyways:
you are saying, that SikuliX should do 5 retries in 1 second, which usually in the average is not possible (only in cases where you consequently work with rather small regions). Raising the waitscanrate costs much cpu and storage. On slower to normal machines the standard of 3 is hard enough.

Revision history for this message
Sabir (issamx) said : 		#6

Congratulations for v 2 version :-) Yes Il will do that switch.

However for Settings.AutoWaitTimeout = 5.0; it's useless in my case. I was only and exlusively region.exists(target,timeout) for image searching. With a timeout >= 3 seconds already. Any risk with that ?

Ok for Sikuli WaitScanRate, I let it to its default value.

Many Thanks.

Revision history for this message
RaiMan (raimund-hocke) said : 		#7

--- With a timeout >= 3 seconds already. Any risk with that ?
No risk with that.
You can always use individual timeouts with wait/exists.
You can be generous with the value: as high as it may be, if the image appears earlier, the find is a success and terminated.

Can you help with this problem?

Provide an answer of your own, or ask Sabir for more information if necessary.

To post a message you must log in.