HOW2 capture time of power-failure?

I need to capture the time-after-a-sound-file-starts-playing until the power is cut, with a resolution of 30 secs., over a period of 30 minutes.

While `ogg123 SoundFie.ogg` is playing, could the play-time be updated every 30 secs? How?

== TIA.

PS. power-cuts without `umount` are no problem for rPi's SD nor USBstik.

Reply to
not.socialnetwork
Loading thread data ...

snipped-for-privacy@gmail.com wrote in news:m2jbi3$geq$ snipped-for-privacy@dont-email.me:

However a power failure in the middle of a write commonly corrupts SD cards and in some cases has been known to make them unusable.

Most RTC chips have a small amount of battery backed scratchpad RAM. Store timestamps for the start time + the current time in the scratchpad and update at least every 30 seconds. Due to the risk of a power failure while updating the current time, you should use a checksum and use two different locations, alternating between them.

The details of how to implement this in a Python script will depend on the chip on your RTC module . . . .

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)  
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk  
 Click to see the full signature
Reply to
Ian Malcolm

Power is cut? What does that mean?

How are you playing it, what is the player software?

Usually you can get a pretty good idea of the time of a power cut by looking at /var/log/messages and seeind when the last message was written before the cut.

POwer cuts are no problem for reading any medium. It is writing that is the problem.

>
Reply to
William Unruh

Pi's don't require much power, so you could keep the Pi running for a short time using stored power, and feed the real power loss signal into one of it's GPIO inputs, to be actioned by relevant software (such as logging the event and/or telling another system across the network), and finally trigger a clean shutdown before the stored power source runs out.

The risk is the flash memory microcode being interrupted in the middle of a critical operation, leaving some structure like the logical to physical block map corrupt, i.e. shuffling some of the blocks in the flash memory, although it may decide it's not going to play at all when next powered up. Enterprise class SSDs will protect themselves from this type of event, but cheap SD cards and USB sticks don't.

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel

You could start a background process at the same time as the player to save a timestamp every 5-10 seconds.

Reply to
Joe Beanfish

Apparently the rPi as . It's never failed during 5 cuts/day for 200 days.

No Python. Just a bash script. ======================================= From: William Unruh

]Power is cut? What does that mean? In the next paragraph, you've decided you know what it means.

]How are you playing it, what is the player software?

`ogg123 SoundFie.ogg` means , is being played by "ogg123".

]Usually you can get a pretty good idea of the time of a power cut by ]looking at /var/log/messages and seeing when the last message ] was written before the cut.

tail /var/log/messages

Reply to
not.socialnetwork

You're probably getting away with it because for your application, all you're doing is mostly reading the SD, so there's probably little to no data needing to be written at power off time, and at boot time, an automatic fsck will happen which (for the most part) will keep you good.

You could simply have:

#!/bin/bash

while true; do date >> /var/log/timefile ; sync sleep 5 done

and at boot time put something like:

touch /var/log/timefile echo "--- we rebooted ---" >> /var/log/timefile

in e.g. /etc/rc.local

Will that work and not result in SD corruption? Hard to be sure. Give it a go and let us know :-)

-Gordon

Reply to
Gordon Henderson

Make a file with the following content

#!/bin/bash for ((i=0;i/dev/null do date >/tmp/timestamp sleep 10 done sleep 10 done

and run it in the background when you start the ogg program.

Reply to
William Unruh

Not a good idea to write to /tmp as that will get cleared when the Pi is next powered up (unless you change the default actions for /tmp).

Change "date >/tmp/timestamp" to "date >~/timestamp" to write to the home directory. Also add a "sync" line in after it to force flushing of the write buffers.

The very long "while ps auxww |grep ogg123 |grep -v grep >/dev/null" could be replaced by "while pidof ogg123 >/dev/null".

I'm not sure why you've got two loops there, the for () loop, and the while loop?

Reply to
Dom

True. Put it somewhere that is not cleared. (I do not have /tmp cleared on reboot, but I agree that many do).

Fair enough.

So that the script will terminate when ogg123 actually finishes its playing of the file. And so that it does not do it immedately since this program might start before the ogg123 program gets going and terminate before the ogg123 even gets started.

>
Reply to
William Unruh

I have an APC SMART-2200 UPS on my machine and I run apcupsd on it. So when the power fails, it logs that (to the second) and when it comes back, it logs that too after the reboot is complete.

--
  .~.  Jean-David Beyer          Registered Linux User 85642. 
  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521. 
 Click to see the full signature
Reply to
Jean-David Beyer

I've got the PlayControlScript on a stikUSB. So that's where I'll put for the next test. It's difficult moving the data between 4 stages to get it to USEnet!

--
Probably the timer needs to be "BACKgrounded"? 
So far I've not understood how the following trace shows what's 
 Click to see the full signature
Reply to
not.socialnetwork

--
>>> ]You could start a background process at the same time as the player to 
>>> ]save a timestamp every 5-10 seconds. 
 Click to see the full signature
Reply to
not.socialnetwork

A different take on this...

ogg123 prints it's progress. You could start a frequent sync in the background (if the default system sync isn't frequent enough). Then redirect stderr of ogg123 to a file. Later you can examine the last timestamp in that file to see how far you got. Looking back farther in the file you can also find which file was being played.

$ ogg123 TheBrightestStar.ogg 2>oggtime $ tr '\015' '\012'

Reply to
Joe Beanfish

Ditto on my Linux/Debian boxes too. :) Just remember to tell BIOS to automatically turn on power after a power loss. :/

--
"He who storms in like a whirlwind returns like an ant." --Borneo 
    /\___/\         Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site) 
 Click to see the full signature
Reply to
Ant

Yes!! That's a better/direct way, which I've partially confirmed.

But I want to also test/confirm the general method, for apps which don't have the special facilities of ogg123, that you were able to use.

I need to read-up on 'starting/stopping background/foreground' processes, after I've cleared some other chaos here.

Thanks.

Reply to
not.socialnetwork

Use "&" to start something in the background. Use "$!" to get the pid of the last background process started. Use "wait" to wait for a (or all) background process(es) to finish. Use "kill" to stop a background process. Here's something to start playing with:

#!/bin/sh echo "foreground pid $$ starting" (echo "background started";sleep 5;echo "background finished") & bgpid=$! sleep 1 # wait around for background process to finish before quitting #echo "waiting for background pid $bgpid" #wait $bgpid # stop background process before quitting echo "killing background pid $bgpid" kill $bgpid echo "foreground pid $$ finished"

Reply to
Joe Beanfish

--- Nice tutorial. Thanks.

I've spent quite some time trying to analyse your code. The very 1st line [of linux syntax] is problematic for me: apparently the EVALUATION of [what ever that is] is embedded in the reporting of . IMO has too many hidden-hooks to catch you; like special rules for the 17th Tuesday of a non-leap-year.

After the multics OS failed, from excess complexity, Unix was a spoof-name, trying to emphasise simplicity. Later, the blokes who designed unix abandoned it, for a simpler design: plan9.

IMO prose is not a suitable substitute notation for a musical-score.

Here's a more graphic notation. Time moves-left-to-right. [..(...).]..

timer starts = [ play starts = ( play ends = ) timer detects that play ended and records time and then stops = ]

Reply to
not.socialnetwork

The string pid is just a string that (like the string foreground), just gets echoed to the terminal.

The $$ get's replaced by the process id number of the current shell process.

See

formatting link
in the section 'Other Special Parameters'.

Also see the page

formatting link

$ echo "$$"

9569 $ echo '$$' $$

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email. 
(nomail.afraid.org has been set up specifically for 
 Click to see the full signature
Reply to
David W. Hodgins

Not Linux. bash man bash $$ is the pid (program identifier) of the current program ( the script in this case). So that line produces the output foreground pid 783 starting where 783 is actually the number for the script itself.

Not Linux. bash. And not hidden, but you do need to learn it.

AFter this your comments degenerate. ...

Reply to
William Unruh

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.