Several attempts to connect to the backend fail before pairing has
been completed, which was producing errors that prevented the
messagebus and audio services from starting up.
Now the DeviceApi().is_subscriber property returns False if the
check fails, assuming unpaired == not subscribed.
Also stopped logging the call stack on the HTTPError exception, it
made an expected situation look like a major crash.
==== Tech Notes ====
Before the current chromecast application was quit when mycroft was started which caused some interference. Now the current app is quit right before starting playback on the device instead.
PR 1049 introduced several cosmetic PEP8 errors that were easily fixed.
Additionally there are unittests that include non-ASCII characters which are
failing. As Pt-PT support is a work-in-progress, I just commented them out
with TODOs next to them.
==== Tech Notes ====
Since the playback now is performed in a thread the curate_cache could
clean out generated speech before or in the middle of playing back the
queue.
==== Fixed Issues ====
#1141
==== Tech Notes ====
Curate cache now only removes cache files if the diskspace is below the
set percentage AND if below a set amount of free disk space
==== Tech Notes ====
- removed old main.py
- replace reference to ConfigurationManager in api tests
- reset configuration after use in configuration test
- Pep-8 issue
==== Tech Notes ====
Previous approach did not work as websocket client was not running, this
uses the standalone send functionality recently added to send a single
message.
==== Tech Notes ====
Since the voice is a quite large download stalling download is a real
possibility. Using wget allows for resume and retry of download in a
simple way.
==== Tech Notes ====
- Using download utility to download voice binary
- reverts to default voice if not premium
- uses default voice during download and switches over when done
The audio service could not handle https URLs. VLC can support them,
so https was added to its supported_uris. Additionally, the play( )
function in the audio service could not actually correctly search the
backends for a supported uri, so the code there has been fixed
When (re)booting a Mark 1 unit will show rolling eyes until it reaches
a "ready" state. This happens by sending a command to the Arduino.
There is also code that prevents sending commands our the serial port
if not running on a Mark 1. In certain situations, the message
indicating that the Mark 1 Arduino was found was posted to the
messagebus before it was fully open. When this was missed, the system
didn't think it was on a Mark 1 and the command to stop the eyes from
rolling (and for further interactions with the Mark 1 hardware) were
not sent.
The Mark 1 Arduino detection is now triggered when the messagebus
'open' notification is generated rather than when the object is
constructed.
==== Fixed Issues ====
#967 - Eyes never stop spinning on startup (Mark 1)
==== Fixed Issues ====
One exemple is reloading pairing skill after skill update (30-60 seconds)
results in a new pairing code being generated.
==== Tech Notes ====
Now compare individual skill modification dates and not a global last
modified skill.
This fixes at least a potential issue with the Mark 1 boot sequence.
The system posts a "system.version" message then registers a
listener for the response. There is a chance that the response
sneaks in before the handler is registered. This just reorders the
sequence of that code.
==== Fixed Issues ====
ISSUE #967 - Eyes never stop spinning on startup (Mark 1)
==== Tech Notes ====
The msm lock wasn't checked before reloading skills allowing skills to be loaded before msm wasn't finished installing requirements.
A check was added to ensure this along with a separate lock enforcing the handling of block_msm and release_msm in the correct order. If not the update procedure could cause a deadlock.