I have a motorhome that I upgraded with front and rear flat screen tvs, each connected to a Pi2.
The rear Pi2 has a USB wifi dongle and a 4T USB drive for media. Both Pi2s are connected using
powerline eth modems ($13 each at Amazon). This setup is unfinished but working well so far.
The front tv power is cut off when the vehicle is running (for safety). This power outlet supplies the
tv, Pi2 and the powerline eth modem. If this is done (vehicle started) when the tv is on, then the
kodi program (aka mediacenter) fails to finish starting when the vehicle engine is stopped and power
is restored to all 3 devices at the same time. The os is running and I can ssh into it. I can supply logs
via ssh if need be. The kodi log stops fairly early without a warning, and the journalctl log looks normal.
If the tv is turned off (with its remote) before starting the vehicle then when the vehicle engine is stopped
the Pi2 boots and kodi starts normally. I suspect the issue is hdmi-cec chatter when both devices are
starting together, but the powerline modem may be involved too.
You are asking for trouble with this setup. You really need to get a UPS for the Pi’s (I think I’ve seen others here posting about how they did a vehicle UPS for the Pi). By just killing the Pi every time, you will eventually get a corrupt SD card.
You mention CEC chatter. CEC is only over the HDMI cable. If I understand your setup; you have a Pi connected to the front TV (via HDMI) and another Pi on the rear TV (via another HDMI). Or is there something more complex, like the 2 TVs connected via HDMI?
And the 2 Pis communicate over Powerline. Could the Powerline be an issue then the motorhome generator is running? Generators are not real clean power sources and may interfere with the Powerline.
Or if the generator isn’t running, then you are using an inverter? I’m not sure that Powerline would work very good with an inverter either. You might consider using ethernet, or wireless.
I had another thought about this. It could be that the Pi is booting faster than the TV, and not receiving the EDID info properly from the TV. You may need to save the EDID info from the TV to a file on the Pi, and use edid_force_hotplug and edid_file options. Search the forums for help on this.
Thanks all for the feedback. I will try ‘bmiiham’s’ suggestion about EDID at our next stop.
I see the need for controlled shutdown but later if a sd problem happens. I think a consumer use
tv box should be fairly bulletproof on its own. Does the Vero box handle power-drop better?
I would like to delay mediacenter (aka kodi) starting for a few seconds. This would allow
time for all things to get stable. But am reluctant to play with systemd settings without advice.
In any case
Only a device with a read-only filesystem would be save against uncontrolled shutdown. So the Vero will be similar impacted to it than other OSMC devices while the NAND may slightly better handle it.
However hard powering off any computer will corrupt the disk eventually. It may be in the middle of writing to the database. No platform will handle this (without effectively a UPS to maintain power until shutdown is complete).
Best option is a permanent power supply for Pi and leave it powered all the time.
If you must go this route, buy a second sdcard that contains a backup.
When you eventually corrupt the first sdcard you can quickly switch (and make a new backup sdcard with the corrupted one).
Thanks again to all. I followed the suggestions of ‘popcornmix’ for bootdelay and both his and ‘bmillham’s’
for the EDID issue. It osmc now starts reliably for me. The problem that started this thread is solved.
I am now convinced I should figure out a solution to a controlled shutdown when power drops. The UPS
suggestions above are more expensive than I’d like. It seems to me a simple bit of circuitry with a capacitor
to hold up +5v briefly while a shutdown script is triggered should be really cheap. I have not yet searched
the web. Anyone have a pointer?
Why 15sec? I was assuming a few milliseconds would be enough. 15sec is a huge number of cpu cycles.
Can there be that much critical stuff to do before reaching a safe state? This ground must have been well covered
before now.
It takes more than milliseconds to shut down a Pi. You are flushing buffers to an SD card that doesn’t have the fastest write speed in the world. Try shutting down the Pi manually and check how long it takes. That will give you a good idea of how long you need to supply power. You could do something like a relay that would keep supplying power from the RV battery for 60 seconds.
Just off the top - everyone with a Pi has ‘some’ intentional or unintentional power cuts. If all or even
a smallish chunk of the buffered stuff were critical, and not written to SD because of the power cut,
then tons of Pi SDs would be corrupted – and I don’t see this happening. So I see this as good
evidence that nearly everything done during a controlled shutdown can be safely discarded (not done).
All those writes you mention are needlessly eating into the write cycle life of the SD leading to eventual data corruption …
I suspect SD corruption happens mostly in the brief grey area as voltage falls out of spec and unintended writes
are made to unintended memory locations. This is at a circuit design, not a programming, level.
It is not likely that config changes to kodi are coded to have ACID properties so if a power cut were to happen
while configs were being changed the result could be a broken system. I suspect the chances of this are
very small compared to the circuit design issue above.
All this has to be old ground, I just don’t know where to look yet.
Your thinking that pulling the power saves write cycles isn’t true. If you pull the power, then the EXT4 partitions journal hasn’t been flushed yet. If that’s the case, then the dirty bit will be set and the next time the Pi powers up, a fsck will run doing that flush. Or fixing the problems caused by pulling the power. So you still get the write cycles.
Sure, you can probably get away with just killing the power, but you will eventually have it happen right when the database was being written to. You now have a possibly corrupt database. Or some other important file.