We have moved at community.getvera.com

Author Topic: Say action - different problems and solutions  (Read 22573 times)

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Say action - different problems and solutions
« Reply #60 on: January 27, 2013, 05:53:24 pm »
Haven't tried it from Lua, but the following captures the essence, and can likely be done from os.execute directly (avoiding the Shell script decompress)

Code: [Select]
target="/www/cmh/skins/default/icons/"
files="Sonos.png Sonos_0.png Sonos_25.png Sonos_50.png Sonos_75.png Sonos_100.png"

for i in ${files}
do
  if test -e ${i}.lzo;
  then
    echo "${i}.lzo exists, decompressing..."
    if pluto-lzo d ${i}.lzo ${i};
    then
      echo "Removing ${i}.lzo"
      mv ${i} ${target}
      rm "${i}.lzo"
    else
      echo "Error decompressing ${i}.lzo"
    fi
  else
    echo "no ${i}.lzo exists"
  fi
done

But there's a larger issue.  I was running some tests and pluto-lzo, used in Vera's file upload, is trashing the file.  It does end up with a LZO suffix, but the file is only 16 bytes long.

I've always side-loaded these various files via scripts, so never noticed that before.  If apps.mios.com is using the same technique, then we can't have these marked as compressed.

As a result of this, I didn't test the above any further.  Of course, we can mod it to not apply compression (etc)

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #61 on: January 28, 2013, 05:05:28 am »
We can do uncompress+move in one call using pluto-lzo.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Say action - different problems and solutions
« Reply #62 on: January 28, 2013, 10:11:06 am »
We can do uncompress+move in one call using pluto-lzo.
Yes, I know.  I whipped out an outline of a script to get syntax, and the basic concept down.  I then started running it, and realized that pluto-lzo is corrupting binary files so never got to the "optimization" phase. 

There's a bunch of stuff extra I'd do there, but it was like "painting deck-chairs on the Titanic" at that point...

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #63 on: January 28, 2013, 03:23:22 pm »
If pluto-lzo is not working well, we have to use the other alternative, that is specifying in app store where to install the (uncompressed) files.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #64 on: January 30, 2013, 03:54:07 pm »
I have now commited my changes.
TTS is finally working well now (quick starting, proper ending, long text managed, possible grouping of several Sonos units, ...) 8)

Please note that you must manually upload the new file Sonos_silence.mp3 to /www/Sonos_silence.mp3.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Say action - different problems and solutions
« Reply #65 on: January 30, 2013, 04:24:17 pm »
@lolodomo,
For files that don't need to be in /www/ we should just leave them in their regular install directory.  Then (one day) they'll get cleaned up correctly when a plugin is de-installed.

So things like tmp files (etc) should be done somewhere that will inherently get cleaned up (like /tmp), perm (install) files can be in /etc/cmh-ludl, and then only the "result" files that a user needs to be downloaded will end up on WWW

...that should keep it cleaner for folks, just in case we accidentally blow out the FS and they need to "reboot" to clean out stuff.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #66 on: January 30, 2013, 04:35:33 pm »
As you previously said pluto-lzo is not working well, I have forgiven the idea of a proper installation.

What is certain is that the MP3 file can be everywhere on the system, we have only to adjust the CONCAT_EXECUTE variable in the plugin to reflect its location.

The png files required to be in a specific directory.

I think we have to find a solution that would work either from the app store installation or from the UI (manual upload). In the second case, we konw where are put the files and we know that they are compressed.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Say action - different problems and solutions
« Reply #67 on: February 24, 2013, 05:34:59 pm »
Ok, so I tweaked the code a little.

It now creates all the intermediate/temporary files in /tmp/.  Only the resultant output file [temporarily] ends up in /www/

If Vera reboots, or if someone manually restarts, at least the temporary files will be cleared up (leaving only the /www/Say.ID.mp3 file if we didn't get to remove it ourselves)

I also changed it so that the MP3 file can be in the standard upload directory (/etc/cmh-ludl/).  With the change as made, it also supports it in the older location (/www/), but the logic here is to minimize the work-required for "Say" to function if we move forward with an apps.mios.com deployment.

ie. I wanted to upload it via apps.mios.com, and not run into the bug they have about "location" being lost on each patch.

These changes are in place, and the Wiki has been changed to reflect where the manual-upload of the MP3 needs to go.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #68 on: February 25, 2013, 04:29:17 pm »
I also changed it so that the MP3 file can be in the standard upload directory (/etc/cmh-ludl/).  With the change as made, it also supports it in the older location (/www/), but the logic here is to minimize the work-required for "Say" to function if we move forward with an apps.mios.com deployment.

ie. I wanted to upload it via apps.mios.com, and not run into the bug they have about "location" being lost on each patch.

The problem is that in case of a manual installation, the user still needs to use WinSCP rather than the Vera dashboard upload feature due to the automatic compression.

I think we should run a script that will try to uncompress PNG or MP3 files inside the directory /etc/cmh-ludl/. If the decompression fails, the user will be able to try again.
For the icons, we could even automatically create a symbolic link to the files in /etc/cmh-ludl/
That way, everything has to be upoloaded in /etc/cmh-ludl/ and a script launched automatically by the plugin at startup is in charge to uncompress PNG/MP3 files and to create symbolic links for the PNG files. And no difference between a manual install and an installation from the store, except that from the store the decompression step will even not be necessary.
« Last Edit: February 25, 2013, 04:30:57 pm by lolodomo »

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Say action - different problems and solutions
« Reply #69 on: February 25, 2013, 05:46:22 pm »
There are multiple bugs in this space.

The first is that, locally, file upload is corrupting BINARY Uploads.
The second is that, via apps.mios.com, the UI is forgetting about file location upon repeat upload (patching) of source files.

I updated the Wiki instructions to clarify that the MP3's need to be uploaded via WinSCP (et-al).  This instruction was there before, but it wasn't clear in the previous instructions.

My changes were mostly to handle the 2nd case above, since we cannot "uncorrupt" a binary loaded via the UI, that's something the MiOS team will have to address.... one day.

Quote
For the icons, we could even automatically create a symbolic link to the files in /etc/cmh-ludl/
Yes, symlinks would be a better option.  I'm hesitant to put actual content into /www (generally) since they might not be "found" when a problem occurs (file system limits, etc) and they're not guaranteed to succeed across production releases.  But symlinks would be recreated when not there (if we code it that way), and the SAY Output would also be recreated.

Something that symlinks when we startup would "fix" this in all cases....  including someone migrating across Vera hardware (where they might not be expecting to copy stuff under /www)


Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #70 on: February 25, 2013, 06:04:43 pm »
New feature added: Say calls are now managed in a queue. It allows you to call several times the Say actions without waiting for the ending of the previous call. While there are calls in queue, each message is said successively without restoring the context between each message.
Please note that group zones are not correctly managed in case of two successive calls with different group zones.

As an example, try this:
Code: [Select]
luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text = "Here is a first test.", Volume="70"}, xxx)
luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text = "Voici un second test.", Language="fr", Volume="60"}, xxx)
luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text = "Here is a thrid test.", Volume="50"}, xxx)
luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text = "Voici un quatri?me test.", Language="fr", Volume="40"}, xxx)
« Last Edit: February 25, 2013, 06:10:05 pm by lolodomo »