Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 1 day, 19 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 3 days, 16 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 4 days, 13 hrs ago - more...
|
2013-06-12
, 09:51
|
|
Posts: 1,417 |
Thanked: 2,619 times |
Joined on Jan 2011
@ Touring
|
#2
|
As Estel said, or even just a sharing app to make dumping pics to an FTP as easy as sharing up to youtube or picasa.
things also needed for anti corp/gov protesters.
-easy audio I/O data app using ax25, fax, or psk31 so off network data becomes possible using CB,PMR,FRS,MURS, amateur radio, amateur satellite, shortwave, marine radio, and business radio; preferably using the easy share with a service so that anyone can use a FM radio to send a picture or file even if the local phone cells are shut down. There is plenty of linux source code ready to go for this but something like kpsk is simple for non tech users. Right now you can for example with a coat hangar yaggi antenna, a FM walkie talkie or radio scanner, an audio patch cable, and a radio fax or SSTV program on your computer receive pictures from the space station or weather satellites.
-Voice crypto for GSM voice calling
there is more discuss here http://talk.maemo.org/showthread.php?t=74348
Last edited by biketool; 2013-06-12 at 10:02.
things also needed for anti corp/gov protesters.
-easy audio I/O data app using ax25, fax, or psk31 so off network data becomes possible using CB,PMR,FRS,MURS, amateur radio, amateur satellite, shortwave, marine radio, and business radio; preferably using the easy share with a service so that anyone can use a FM radio to send a picture or file even if the local phone cells are shut down. There is plenty of linux source code ready to go for this but something like kpsk is simple for non tech users. Right now you can for example with a coat hangar yaggi antenna, a FM walkie talkie or radio scanner, an audio patch cable, and a radio fax or SSTV program on your computer receive pictures from the space station or weather satellites.
-Voice crypto for GSM voice calling
there is more discuss here http://talk.maemo.org/showthread.php?t=74348
Last edited by biketool; 2013-06-12 at 10:02.
|
|
2013-06-12
, 10:08
|
|
Posts: 167 |
Thanked: 204 times |
Joined on Jul 2010
|
#3
|
Thinking aloud here, not providing answers yet...
- does this need to be done at camera / application level? Can it be done at filesystem level? We want to react when a photo is successfully written to a filesystem, not to the photo being taken and processed.
- I appreciate that we don't want to run rsync from cron for power/bandwidth reasons, but could we create a watched directory to which the camera saves and a way of (doing arbitrary thing) to back it up? Could it be based around inotify/incrond? (http://www.cyberciti.biz/faq/linux-i...e-directories/)
If that provides the trigger, it should be pretty easy to whip up scripts to sync new files to [rsync|webdav|whatever]. Is there still a need to build it specifically into or around the camera?
Edit: we seem to have inotify-tools, which provides inotifywait; this could be used to detect close-of-write on a new file in the camera directory. What we do from there is open to debate...
Last edited by magick777; 2013-06-12 at 10:31.
- does this need to be done at camera / application level? Can it be done at filesystem level? We want to react when a photo is successfully written to a filesystem, not to the photo being taken and processed.
- I appreciate that we don't want to run rsync from cron for power/bandwidth reasons, but could we create a watched directory to which the camera saves and a way of (doing arbitrary thing) to back it up? Could it be based around inotify/incrond? (http://www.cyberciti.biz/faq/linux-i...e-directories/)
If that provides the trigger, it should be pretty easy to whip up scripts to sync new files to [rsync|webdav|whatever]. Is there still a need to build it specifically into or around the camera?
Edit: we seem to have inotify-tools, which provides inotifywait; this could be used to detect close-of-write on a new file in the camera directory. What we do from there is open to debate...
Last edited by magick777; 2013-06-12 at 10:31.
 |
|
2013-06-12
, 10:37
|
|
Posts: 6,445 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#4
|
Expanding on magick777's idea, an instant backup of any new file at filesystem level (even if only in specified watched directories) will have additional advantages:
1. An instant backup of any new files
2. "No officer, I did not upload the picture of you beating that kid specifically. You know, I have this instant backup app..."
1. An instant backup of any new files
2. "No officer, I did not upload the picture of you beating that kid specifically. You know, I have this instant backup app..."
|
|
2013-06-12
, 10:57
|
|
Posts: 167 |
Thanked: 204 times |
Joined on Jul 2010
|
#5
|
Crude, bleeding edge proof of concept for waiting on camera images using inotifywait. Requires inotify-tools.
It currently waits on a close-after-writing in the camera directory, lists the number of images and the filename of the newest. It should be fairly easy to trigger whatever desired upload actions from there.
and subsequently a quick hack to upload the newly-created image via curl... in this case, to a WebDAV folder. Working for me...
Last edited by magick777; 2013-06-12 at 11:34.
It currently waits on a close-after-writing in the camera directory, lists the number of images and the filename of the newest. It should be fairly easy to trigger whatever desired upload actions from there.
Code:
maemo:~# cat /usr/bin/camwatch #!/bin/bash WATCH_PATH="/media/mmc1/DCIM" FILENAMES="*.jpg" WATCH_COUNT=0 COUNTER=0 declare -i WATCH_COUNT; declare -i COUNTER; inotifywait -m --format '%f' -e close_write $WATCH_PATH | while read FILE do WATCH_COUNT=$WATCH_COUNT+1; COUNTER=$(ls -1 $WATCH_PATH/$FILENAMES | wc -l); NEWEST=$(ls -t1 $WATCH_PATH | head -n 1); echo "$COUNTER $NEWEST"; done
Code:
#!/bin/bash WATCH_PATH="/media/mmc1/DCIM" FILENAMES="*.jpg" WATCH_COUNT=0 declare -i WATCH_COUNT; inotifywait -m --format '%f' -e close_write $WATCH_PATH | while read FILE do WATCH_COUNT=$WATCH_COUNT+1; NEWEST=$(ls -t1 $WATCH_PATH | head -n 1); curl -T $WATCH_PATH/$NEWEST http://<user:pass>@files.memotoo.com/webFolder/DCIM/; echo "uploaded $WATCH_PATH/$NEWEST"; done
Last edited by magick777; 2013-06-12 at 11:34.
|
|
2013-06-12
, 13:35
|
|
Posts: 167 |
Thanked: 204 times |
Joined on Jul 2010
|
#6
|
Further thoughts pursuant to adapting this to Estel's use case:
- there needs to be a functioning network connection, which we should check before blithely issuing upload commands. If there isn't we ideally should be able to do nothing and fix it opportunistically later.
- ideally, we should be able to cope with a retrospective upload of multiple files if a transfer has failed, or not been attempted due to lack of connectivity. This would strongly favour using rsync, possibly against all photos with today's date. If the images exist on the receiving side, no problem, if they don't then we catch up as many photos as we took today but haven't uploaded yet.
- use of rsync would also permit deletion-on-upload of images, using the --remove-source-file flag. Combining the two would mean "every time a photo is taken, upload and delete from phone any photos having today's date", which might be nice for security-sensitive photography.
- use of rsync over SSH provides encryption and widespread compatibility with most Linux machines, probably easier to use than setting up WebDAV or FTP
- for Joe Average, users need to be warned as to what this will do to their bandwidth if they turn it on and take a hundred photos...
- there needs to be a functioning network connection, which we should check before blithely issuing upload commands. If there isn't we ideally should be able to do nothing and fix it opportunistically later.
- ideally, we should be able to cope with a retrospective upload of multiple files if a transfer has failed, or not been attempted due to lack of connectivity. This would strongly favour using rsync, possibly against all photos with today's date. If the images exist on the receiving side, no problem, if they don't then we catch up as many photos as we took today but haven't uploaded yet.
- use of rsync would also permit deletion-on-upload of images, using the --remove-source-file flag. Combining the two would mean "every time a photo is taken, upload and delete from phone any photos having today's date", which might be nice for security-sensitive photography.
- use of rsync over SSH provides encryption and widespread compatibility with most Linux machines, probably easier to use than setting up WebDAV or FTP
- for Joe Average, users need to be warned as to what this will do to their bandwidth if they turn it on and take a hundred photos...
|
|
2013-06-12
, 14:17
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#7
|
Thanks @magick777 and @pichlo for all the input, and @Estel for the idea.
I've come up with this:
This is untested (I've written it on Notepad). This could be run permanently (or manually before starting a photo shooting session).
Thanks to inotify, there should be (almost) no impact on battery life.
I'll give it a try when I'm home!
I've come up with this:
Code:
WATCH=/home/user/MyDocs/DCIM CLOUD=user@remote.host:/path/ inotifywait --monitor -e close_write --format "%w" $WATCH |\ while read file do echo (dbg) added $file, synchronizing.. # convert/mogrify to make a smaller version? rsync -avz $WATCH $CLOUD done
Thanks to inotify, there should be (almost) no impact on battery life.
I'll give it a try when I'm home!
| The Following 4 Users Say Thank You to reinob For This Useful Post: | ||
 |
|
2013-06-12
, 14:51
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#8
|
Thanks for all your input guys, I haven't expected such feedback in so short time. Of course, we don't need to hold religiously to monitoring camera activity - it was just me thinking loudly, if there are better methods available (like in magick777 analysis), lets use them.
Question here - monitoring things via inotify all the time (as opposed to just after camera activity) won't cause dramatic increase of power usage during idle? Sadly, I have no clue about monitoring such things at filesystem level, so my question ma be dumb - I just wonder if it require us to actively monitor something (which, while neglible during heavy usage, would much reduce standby time), or it works by some notification magick, that doesn't consume anything 'till trigger happens.
Again, thanks a lot for super-positive response!
Last edited by Estel; 2013-06-13 at 08:54.
Question here - monitoring things via inotify all the time (as opposed to just after camera activity) won't cause dramatic increase of power usage during idle? Sadly, I have no clue about monitoring such things at filesystem level, so my question ma be dumb - I just wonder if it require us to actively monitor something (which, while neglible during heavy usage, would much reduce standby time), or it works by some notification magick, that doesn't consume anything 'till trigger happens.
Again, thanks a lot for super-positive response!
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2013-06-13 at 08:54.
|
|
2013-06-12
, 15:29
|
|
Posts: 167 |
Thanked: 204 times |
Joined on Jul 2010
|
#9
|
As I understand it, inotify asks the kernel to keep a watch on the given inodes and the kernel generates an event when those inodes are modified. The monitoring itself shouldn't cause any appreciable cost in terms of power consumption, although, of course, any actions triggered in function of that monitoring still consume power.
As for the bash script, it seems I've been a little hasty in reinventing the wheel; there is a Debian package called inoticoming, which is intended precisely to monitor an incoming directory via inotify and run an arbitrary command when files are placed into it. The squeeze version installs cleanly on my N900, see
http://packages.debian.org/squeeze/inoticoming
As for the bash script, it seems I've been a little hasty in reinventing the wheel; there is a Debian package called inoticoming, which is intended precisely to monitor an incoming directory via inotify and run an arbitrary command when files are placed into it. The squeeze version installs cleanly on my N900, see
http://packages.debian.org/squeeze/inoticoming
 |
|
2013-06-12
, 15:31
|
|
Posts: 889 |
Thanked: 2,087 times |
Joined on Sep 2010
@ Manchester
|
#10
|
Maybe it could be triggered when the cover closes rather than when camera-ui is activated. In the situations specified I would want as much power as possible dedicated to taking pictures.
 |
| Tags |
| inotify, interlace image |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 22:26.
Lately, our awesome contributor Copernicus (of Pierogi's fame) become real tornado master, and entered unbeliveable whirlwind of development. He is throwing new pasta applications at AK-47 rate, including (but not limited too) an all-purpose Torch and LED manipulation tool, which Lanterne:
http://talk.maemo.org/showthread.php?t=90229
...which does everything that is possible with N900's leds and more (like morse code text interpreter for sending!), or all-purpose audio and conversation recording tool, Orecchiette (currently heavy in development, alpha stage):
http://talk.maemo.org/showthread.php?t=90398
Still, Copernicus is eager for more, and asked users of his applications about ideas for usefull (and doable in less than lifetime
Actual background:
Amongst many things, I'm volounteering as activist, "fighting" against law-breaking corporations and, sometimes, corrupt or abusive members of uniformed services. Often, it requires taking proof-photos, and *very* often I'm risking losing device/sd card with proofs, to corporate security personnel or folks like that. Even worse, sometimes, I need to skip photo'ing some very important thing, in order to keep all material gathered to that point in safety.
Now, there are those wifi SD cards, which - in pair with closed source, windoze receiver software - automatically transfer photos to other machine, as soon as they're made. But, range of such card is pathetic, usable only in studios (if wifi coverage is good enough), and are not working with mobile connection.
Why not make our irreplaceable N900 even much better tool?
Idea:
Program, that would run when camera application is active (wrapper around camera-ui? It needs to live only when camera lives, to avoid power wasting), and monitor pre-defined folder. As soon as new file (photo) appears in that folder, it would automagically send it through internet, via pre-defined method (e-mail for good start, more advanced usage could be pre-defined ftp server. We already have at least 2 FOSS ftp clients for Maemo, that could be utilized, or lend necessary source code), of course utilising network access (most likely, gprs, but no reasons, why it shouldn't work via wifi too).
Thos would make life *much* easier, not only for activists - it could be utilized by "average joe" too, allowing to take pictures of high-size (for example RAW and JPG bundle from cssu'ish camera-ui, or fCam, or even vanilla camera-ui photos at highest settings), without risk of getting out of available space (custom option to delete file after successful sending?).
Just wild idea - I think it should be doable by someone who know how to watch for camera-related dbus events.
/Estel
// Edit
Also see:
http://talk.maemo.org/showthread.php?p=1351537
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2013-06-13 at 08:56.