Hello Gurpreet!

For some but not all error situations you can see meaningful information in the console. 

Regarding the issue you report with React JS - do you see the same problem with our technical example when navigating between pages?

https://sitepal.com/api/examples/react/index.html

If not, then please look closely to see if you can identify the differences between your implementation and our technical example. Full source code is available.

If you cannot, please contact our support & share with us a simple example of your own that demonstrates the problem. We would need the source code for your example so our engineering can build it and advise.

Regarding your question about interrupt mode - normally interrupt mode should be set in the vh_sceneLoaded callback. But you can certainly switch back and forth between interrupt mode & queue mode at anytime after the Scene is loaded.

There is no way to check the mode - so your best bet is to remember the mode in a status parameter of your own. Thedefault mode is 'queue' - and anytime you modify the mode you would want to update your status parameter. Bear in mind that the status attributes (including interrupt mode) are Scene specific. So if you are loading different Scenes in different pages, you would need to update the status on each as needed to support your logic.

Hope this helps - pls let me know if I can further advise.

Best regards,

Gil

The SitePal Team

I saw. Thanks

I checked the logs and responded to you with detailed info.

Please check.

Hello Pavel! 

This is typically an indication of failure of the TTS request.

Failure could be the result of bad input - or could be something else

I'd need your account ID (or login email) to check our logs & advise further.

Please share either here or by sending a note to our support.

Standing by,

Gil

The SitePal Team

Pavel, 

Thank you for your patience & feedback as we investigated & addressed this issue.

The nature of the problem, which involved a particular sequence of events and timing, was challenging to track down. Thanks to your assistance we were able to.

Best regards,

Gil

Hi Pavel - this issue should now be fixed. Please clear your browser cache and let me know if you still see the problem.

Best,

Gil

Hi Pavel - 

We are working on it. I expect that we will have an update soon. 

Thanks for your patience - will advise asap.

Thank you for the detailed info. 

We'll look into it and advise asap

Hello Pavel - 

We've recreated your example on our test server here - https://www.workboy.com/qa/vue_client_example/index.html

(you need to accept the provisional cert)

We can see, both in your example and in ours, that the third audio sometimes does not play and appears to be skipped. But that is not actually the case.

What happens is that the delayed stopSpeech call is called after sayText is called, but before the audio starts.
So the audio never starts playing and appears to be skipped.

This behavior is per spec. not a bug, but a feature :-)

In your original note you say that - "After few calls, the sayText() does not start speaking." 

it sounds like you may describing a different problem than the one demonstrated by your example.
If that's the case - pls provide a clearer explanation and/or better example - and we will investigate asap.

Best,

Gil