We have moved at community.getvera.com

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

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #45 on: January 26, 2013, 06:16:51 am »
Files from the trunk.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #46 on: January 26, 2013, 06:27:36 am »
I think the following actually works...

Code: [Select]
cat input.mp3 silence.mp3 > output.mp3

This 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 ?

Offline hek

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 714
  • Karma: +60/-1
Re: Say action - different problems and solutions
« Reply #47 on: January 26, 2013, 11:28:46 am »
Great work @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 #48 on: January 26, 2013, 05:17:42 pm »
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 [os.execute(...)] 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 cmh-ludl.  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.  :(

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #49 on: January 26, 2013, 06:40:44 pm »
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 ?

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 #50 on: January 26, 2013, 07:56:33 pm »
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
Code: [Select]
    pluto-lzo d <srcFile> <dstFile>
We should use a mv 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:
Code: [Select]
    os.execute('mv Sonos*.png /www/<wherever>')
If we need to go pluto-lzo d anything, then perhaps we can put a "Sonos.sh" script in that does the work, and we jut os.execute() that. 

That would compartmentalize any apps.mios.com installation work-arounds into something readily moved if they ever fix that system.

Offline Brientim

  • Sr. Hero Member
  • ******
  • Posts: 2497
  • Karma: +78/-7
Re: Say action - different problems and solutions
« Reply #51 on: January 26, 2013, 08:07:29 pm »
When you upload files to apps.mois.com, it has a check box to select to compress or not.

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 #52 on: January 26, 2013, 08:15:51 pm »
When you upload files to apps.mois.com, it has a check box to select to compress or not.
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 ;)

Offline Brientim

  • Sr. Hero Member
  • ******
  • Posts: 2497
  • Karma: +78/-7
Re: Say action - different problems and solutions
« Reply #53 on: January 26, 2013, 09:10:48 pm »
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.

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 #54 on: January 26, 2013, 09:32:23 pm »
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...


Send from my Macbook Pro using a Keyboard, typed by hand  8)

Offline Brientim

  • Sr. Hero Member
  • ******
  • Posts: 2497
  • Karma: +78/-7
Re: Say action - different problems and solutions
« Reply #55 on: January 27, 2013, 12:29:52 am »
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???

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 #56 on: January 27, 2013, 12:48:17 am »
Hasbro of UI? Curious comment...
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.

Offline Brientim

  • Sr. Hero Member
  • ******
  • Posts: 2497
  • Karma: +78/-7
Re: Say action - different problems and solutions
« Reply #57 on: January 27, 2013, 12:56:45 am »
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.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #58 on: January 27, 2013, 04:20:17 am »
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.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Say action - different problems and solutions
« Reply #59 on: January 27, 2013, 05:01:32 am »
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