Automated and On-Demand Restarts: How We Keep Hundreds of Raspberry Pis Healthy

A Raspberry Pi that has been running continuously for weeks, playing audio 18 hours a day, will eventually accumulate small problems: a process that has consumed slightly more memory than it should, a network connection that is half-stale, a stream handle that is open but no longer responding correctly. None of these are catastrophic on their own. Together, they explain why a device that was working fine on Monday is producing glitchy audio or showing intermittent offline states by Friday.

The most effective and least invasive way to prevent this is also the most boring: a regular restart. RoomStream automates this across the entire fleet so that it happens without anyone thinking about it.

The Daily Restart

Every device in the fleet restarts automatically once per day, on a scheduled basis. The restart is coordinated at the platform level so that devices in the same zone do not restart simultaneously — one device coming back up while another is still rebooting avoids a gap in audio coverage for that zone.

The timing is configurable per chain and per hotel, and is generally scheduled for the lowest-traffic period of the day for that type of property. For a hotel, this is typically around 4–5 AM, when lobbies and common areas are empty and the impact of a brief pause in music is zero.

No administrator needs to schedule, trigger, or verify these restarts. They happen automatically and the dashboard shows the result.

Visibility, Not Just Automation

The dashboard shows, for each device, whether it has already completed its daily restart today — and whether that restart was successful or is still pending. This context matters during diagnosis: a device that has been showing odd behaviour but has not yet had its daily restart is very likely to resolve on its own in a few hours. A device that restarted an hour ago and is still showing the same problem needs a different kind of investigation.

Without this visibility, the default response to any device problem is "have you tried restarting it?" — which is sometimes the right answer and sometimes a waste of time. Knowing restart status before picking a course of action saves diagnostic time across a large fleet.

Full Restart vs. Player Restart: The Right Tool for Each Problem

A full device restart reboots the entire Raspberry Pi — the operating system, the network stack, the agent, everything. It is the most thorough recovery action and resolves the widest range of problems. It takes 45–90 seconds and causes a brief pause in audio.

A player restart restarts only the audio playback process, without touching the operating system or network configuration. It is appropriate for a narrower set of problems: a stream that has stalled, a decoder that has got stuck on a malformed audio segment, audio that has stopped while the device itself is fully online and healthy. A player restart resolves these in seconds rather than the minute-plus of a full reboot, and causes less disruption.

Both options are available from the device's configuration page with a single click. Choosing between them is a matter of what the dashboard is showing: if the device is online and connected but audio has stopped, player restart first. If the device is offline or behaving erratically in multiple ways, full restart.

The Result at Scale

With a fleet of several hundred devices spread across 50 hotels, the difference between "someone has to remember to restart each device periodically" and "they restart themselves, and you can see which ones have not managed it" is the difference between a system that requires constant monitoring and one that takes care of itself. The daily restart routine eliminates a whole category of gradual degradation issues that would otherwise surface as unexplained audio problems over time.

On-demand restarts handle the rest: the occasional device that needs immediate intervention, resolved remotely in seconds without dispatching anyone. The combination means that most device health maintenance across the entire fleet happens without the IT team needing to be involved at all — and when they do need to be involved, the tools to act remotely are already there.