I think the following actually works…
cat input.mp3 silence.mp3 > output.mp3I have now fixed the Say action when text is longer than 100 characters.
How it works?
Thanks
Matteo
How it works?
Thanks
Matteo[/quote]
Text is cut in fragments of 100 characters max. To do that a space is searched.
Then each fragment is translated by Google to produce a mp3 file.
Finally all files are concatenated in a unique mp3 file that is played by the Sonos.
How it works?
Thanks
Matteo[/quote]
Text is cut in fragments of 100 characters max. To do that a space is searched.
Then each fragment is translated by Google to produce a mp3 file.
Finally all files are concatenated in a unique mp3 file that is played by the Sonos.[/quote]
That is simply great! Thanks
Which version of the Plug in should i install to test it?
Files from the trunk.
[quote=“hek, post:41, topic:173748”]I think the following actually works…
cat input.mp3 silence.mp3 > output.mp3This solution is working and solve the ending problem.
For your information, Sonos is able to manage bitrate change in a file. My silence file can be at 128 or 32 kbps, it is working (in fact I made my first tests with a short music file).
So I have produced (with Audacity) a silence file, 10 seconds at 32 kbps. It produces a file of size around 40 kb. I uploaded the file in /www/silence.mp3 and my current version of the plugin uses it.
My question to finish the work and commit my changes is: if I join the silence file to the plugin files, where will it be installed by default, considering the future automatic installation from the app store ?
I would use a file of the same “naming” model as the plugin files, and keep it in the cmh-ludl directory. I think ALL of the files should live there, from an installation standpoint, and we need to write a [[tt]os.execute(…)[/tt]] script to move them into place when the Plugin starts.
In the current Apps.mios.com model, you have to enter (and re-enter) the new location for anything that doesn’t live in [tt]cmh-ludl[/tt]. Each time we’d have to patch, we’d have to re-enter any custom location information.
This bug has been in the Apps store for ~1yr now, and there’s no fix targeted for it. It’s one of the things that made be put the brakes on going further to get the plugin into the store… the maintenance was going to be too high once the custom images had been added. 
Good idea.
That way it will even work using the manual upload and the user will not have to take care where to put the file.
The only thing we have to consider is that the files will be lzo compressed ?
I have to remind what is the command to uncompress…
We do the copy at each restart ?
We do a copy, keeping the files at their original place too or we move them ?
Not all files get compressed, so it may not be needed. I haven’t played with working out which ones do/don’t “naturally” get compressed by apps.mios.com.
If we need to perform any decompression step, then we can run
pluto-lzo d <srcFile> <dstFile>We should use a [tt]mv[/tt] command instead of a copy. This can be executed [unconditionally] at each restart and since we’re effectively moving the files into place, it’ll be benign/low-cost on subsequent calls.
I would think something like:
os.execute('mv Sonos*.png /www/<wherever>')
If we need to go [tt]pluto-lzo d[/tt] anything, then perhaps we can put a “[tt]Sonos.sh[/tt]” script in that does the work, and we jut [tt]os.execute()[/tt] that.
That would compartmentalize any apps.mios.com installation work-arounds into something readily moved if they ever fix that system.
Yes, but I’m looking to make it so that we NEVER have to tweak/re-enter settings into apps.mios.com. So, if it defaults to compress (and “re-defaults” (looses") the setting upon patching) then we’ll run with it compressed and have our scripts handle the rest.
If it remembers this setting, on a per-file basis, then we could use it. Basically what we’re planning here is to work-around the deficiencies of apps.mios.com, since they’re [currently] preventing us from putting the plugin into that system due to it’s buggyness 
As far as It does not remember it on a file by files setting as it does not for location but they need to look at including a library rather then manually entering per file on each version.
Yes, I totally agree with the logic being applied… And, as there are known issues with both the apps.mios.com and its deployment of files files, managing this within the script would be an ideal way to negate any user concerns. It would for the first time where icons are included, manual operations would be consistent with uploading other files and not require additional management overheads by the end user.
I wish they would get tapatalk working again, it is so much easier than working with a mobile browser.
On the plus side, at least we’re not seeing anymore “Sent from my WT19i using Tapatalk 2” messages…
[size=8pt]Send from my Macbook Pro using a Keyboard, typed by hand[/size] 8)
Yes, I made sure I never posted with a signature from Tapatalk…
Hasbro of UI? Curious comment… Transformer, not listening, great toy, gender biased, alway growing???
A toy UI, with a matching colour scheme, and readily breaks/needs to be replaced. Something not suited for heavy use. I change the expression every few weeks.
I thought it might be something along those lines of being a toy, but, you explained it very well. And, I can now picture it.
When files are uploaded from the ui, they are lzo compressed. Verified yesterday with a MP3 file and if I correctly remember it is the same thing with a PNG file.
The shell script is a good idea but here again we will have to decompress it first.
With the shell script, we could have another problem: run permission missing. As the script will be simple, we may keep it in the lua code of the plugin, it will avoid one preliminary step (uncompress of the shell script).
By default, root uses ash shell. I know sh, csh, ksh but not ash Not a problem by the way.
When runnign os.execute from lua, the command is run using what shell ? ash ? I know how to check it but if someone has the answer, that would avoid me to loose few minutes ;D