Haven’t tried it from Lua, but the following captures the essence, and can likely be done from [tt]os.execute[/tt] directly (avoiding the Shell script decompress)
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[/code]
But there’s a larger issue. I was running some tests and [tt]pluto-lzo[/tt], 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)
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…
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.
@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.
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.
It now creates all the intermediate/temporary files in [tt]/tmp/[/tt]. Only the resultant output file [temporarily] ends up in [tt]/www/[/tt]
If Vera reboots, or if someone manually restarts, at least the temporary files will be cleared up (leaving only the [tt]/www/Say.ID.mp3[/tt] 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 ([tt]/etc/cmh-ludl/[/tt]). With the change as made, it also supports it in the older location ([tt]/www/[/tt]), 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.
[quote=“guessed, post:68, topic:173748”]I also changed it so that the MP3 file can be in the standard upload directory ([tt]/etc/cmh-ludl/[/tt]). With the change as made, it also supports it in the older location ([tt]/www/[/tt]), 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.[/quote]
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.
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.
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)
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:
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)