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
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.
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]
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.
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 :-)
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?
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.
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.
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
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.
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"
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 = ]
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.
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.