A weather board freezes when it is a live browser page and runs for days when it is files on timers. Pull the forecast from a public weather API every 60 minutes, rebuild the radar loop on the same short timer, keep the last good files on the server, and let the player pull the playlist and store its own copy. A network drop pauses updates, not playback.
A weather board that freezes is usually a browser problem, not a weather problem. The setup that runs for days unattended plays files, not pages: a script pulls the forecast from a public weather API once an hour, rebuilds a radar loop every 10 minutes, and publishes both into a playlist that the player pulls on a timer and keeps on the unit. When the network drops, updates pause and playback runs on from local storage. This page gives you the two refresh intervals and the reason for each, the cache rule that keeps a failed feed from blanking a slide, the setup steps, and the three checks that tell you the screen is safe to leave alone. The same design suits a lobby screen, a counter display or a shop-floor notice board.
Why does a weather screen freeze after a few days?
It freezes because something on the screen is still computing. A browser window left open for days grows its memory use until the system kills it. A page that loses its connection stalls on a spinner no visitor can dismiss.
The shortcut most people try first is a fullscreen browser pointed at a weather page. Pages are written for someone sitting at a keyboard: scripts keep loading, sessions time out, update prompts and pop-ups appear, and after enough days the tab is holding media from every loop it ever played. When memory runs out, the system closes the tab and the screen goes black until somebody reboots it. Players catch the same buildup, and the out-of-memory exception that appears after hours is the player-side version of the failure.
The design that survives is the opposite: the screen decodes files it already holds. Nothing on the display unit renders a page, so there is no session to time out and no heap growing while you are not looking. Day 14 runs like day 1, and the only thing that can go stale is the data, which the next two intervals handle.
What do you need to run weather on a digital signage player?
You need three things: a public forecast feed from your national weather agency, a small script on any server the screen can reach that renders the feed into JPG, PNG or MP4 files, and the player set to pull that playlist on a timer.
The IMD Signage Player has no weather widget. What it does have is a documented way to pull a playlist from your own web server on a timer, and that turns the job into plain media work: render the forecast as a PNG, encode the radar loop as an H.264 MP4, and the player treats both like any other slide; JPG, PNG and WebP images and MP4, M4V and WebM video all play, with H.264 MP4 the one we recommend.
If you would rather not run a script at all, a cloud CMS app with a hosted weather widget can be installed on the unit instead, and then the refresh behavior belongs to the widget vendor. Hold any candidate to the week test before you commit: one week of playback with the network unplugged for one hour in the middle. The basics of the player itself are in the guide to choosing a digital signage player.
A factory floor adds one more problem, getting web weather data to the screen without opening a path into the controls, and the article on displaying web weather data on a factory screen covers exactly that.
How often should a signage screen refresh the forecast?
Pull the forecast feed every 60 minutes: the United States National Weather Service rebuilds its gridpoint forecasts about 4 times a day with no fixed publication schedule, so hourly polling catches every update within the hour at 24 requests a day.
The basis for the interval is the agency's own published record: its maintainers state that the API updates about 4 times daily, that forecast offices are expected to revise at least twice a day, and that there is no definitive timetable. Polling every 6 hours could land between revisions and leave a 12-hour-old forecast on the screen. Polling every 5 minutes adds 288 requests a day to catch the same 4 changes. Hourly sits in the middle: 24 requests a day, and the newest release reaches the screen in at most about 70 minutes, 60 to the script's next render plus 10 to the player's next pull.
How often should the radar loop refresh?
Refresh the radar loop every 10 minutes: weather radar sites complete a full volume scan every 4 to 10 minutes, so a pull on that interval catches every scan, keeps the loop about 10 minutes behind the live picture on average, and makes 144 requests a day.
The 4 to 10 minute range is the radar's own scan cycle, the time an antenna needs to sweep a complete volume, and different sites sit at different points in that range. Build the loop from about 12 frames covering the last hour as an H.264 MP4; that reads as motion without a large file. Pull every 5 minutes only when the board is the building's storm-watching display: average lag drops to about 5 minutes and the request count doubles to 288 a day. One safety line belongs here: a radar loop on a lobby screen lags the sky by minutes, so treat it as awareness and take real warnings from the agency's official alert channels.
What does an example lobby setup add up to in numbers?
A single lobby screen on this design makes 168 requests a day to the weather API, plays a radar loop that averages 10 minutes behind the newest scan and never runs past about 20 minutes, and shows a forecast never more than about 70 minutes behind publication.
Scenario: a cafe lobby with one 1080p screen, 1920 x 1080, running an eight-slide playlist in which one slide is the forecast PNG and one is the radar MP4. The script runs on a small server at the site and the player pulls the playlist on the same radar timer.
- Forecast fetches by the script: every 60 minutes = 24 requests a day.
- Radar fetches by the script: 6 per hour x 24 h = 144 requests a day.
- Total load on the weather API: 24 + 144 = 168 requests a day, all from the one server. A second screen, or a tenth, adds pulls on your own server and 0 new requests to the API.
- Player pulls: 144 a day on that timer; the radar MP4 changes on nearly every pull, so expect up to 144 small downloads a day on this screen.
- Radar lag: about 5 min from scan to the script's next poll, under 1 min to encode, about 5 min from publish to the player's next pull, so roughly 10 min typical and about 20 min worst case (10 + 1 + 10).
- Forecast lag: at most 60 + 10 = 70 minutes behind publication.
- One week unattended: 168 x 7 = 1,176 requests, no human touches.
The decision: 168 requests a day is a rounding error for the API and for the small server, and the totals stay flat however many screens hang off the same script.
What happens to the screen when the network drops?
A network drop stops the updates, not the show: the playlist the player pulled is stored on the unit, the app is designed to restart the show within seconds if it stops, and your server keeps serving the last good files until the feed answers again.
Two caches do the work. On the server, write each new file completely before swapping it over the old one, and when the weather API times out, publish nothing and try again on the next cycle: a failed fetch never blanks a slide. On the player there is nothing to configure, because the show it pulled is kept in internal memory and keeps playing from local storage while the network is down. When the connection returns, the next pull brings down the missed radar loops and the newest forecast, with no visit to the screen. A power cut ends the same way: with the player set as the home app, it is designed to bring the show back full screen at power-on, with no launcher and no keyboard. The walk-through of offline playback and autostart covers that side in detail.
How do you set up weather on a signage screen step by step?
Setup is under an hour of work: point a script at the gridpoint feed, render two files on the two timers, publish both into one playlist, and set the player to pull it on the radar timer and bring the show up on its own at power-on.
- Point the script at your national weather agency's public gridpoint forecast endpoint for the screen's coordinates.
- Render the forecast slide as a PNG at the screen's resolution: current conditions, today's high and low, and the next 3 days, rebuilt every 60 minutes.
- Encode the radar loop as an H.264 MP4, about 12 frames covering the last hour, rebuilt every 10 minutes.
- Apply the swap rule to both files: finish writing the new file, then replace the old one, so a half-written file never reaches the player.
- Publish both into the playlist your server hands the player.
- Set the player to pull that playlist on a timer, timer set to 10 minutes.
- Set the player as the home app, so the show starts full screen at power-on with no launcher and no keyboard.
- Watch one hour at the screen: the radar slide should replace itself within 10 minutes of a new scan and the forecast within about 70 minutes of a new release.
How do you check the screen will survive a week without you?
Three checks on install day tell you the screen is ready to be left alone: pull its network cable for 10 minutes, power-cycle the screen, and stop your script for a full hour. A setup that passes all three plays through anything an ordinary week brings.
Run them in this order:
- Network. Disconnect the screen's network for 10 minutes. The show should keep playing from the player's stored copy with no gap, and the first pull after reconnecting should bring the missed files down; the file dates in the playlist folder show the catch-up.
- Power. Switch the screen off and back on. The show should come up full screen on its own, with no remote, no keyboard and no clicks.
- Server. Stop the script for 60 minutes. The screen should keep playing the last good radar loop and forecast the whole time; start the script again and the newest files should land on the next pull.
Recommendation: pull the forecast every 60 minutes and the radar every 10 minutes, keep the last good copy of both files on the server, match the player's playlist pull to that radar timer, and set the player as the home app so the show is designed to return full screen after a power cut. Drop the radar pull to every 5 minutes only for a board whose job is storm awareness in the wet season, and leave every other number where it is. Run the three checks above before you call the screen done.
Questions
Does the weather data need an account, a key or a subscription?
In the United States the National Weather Service's public API answers anonymous requests, so no account and no key are involved. The IMD Signage Player's software ships with no subscription. If you install your own cloud signage app with a hosted weather widget instead, that app's terms and refresh behavior belong to its vendor; judge it by the same week test this page describes.
How much network data does the setup use per month?
The weather API sees only the server's requests, 168 a day. What each screen downloads is mostly the radar loop: if the MP4 runs about 2 MB, then 144 downloads a day is about 290 MB, which is roughly 8.7 GB over a month, plus a few megabytes of forecast PNG and playlist files. Trim the frame count or the resolution if the screen sits on a metered link.
Can the screen go dark outside opening hours?
Yes, with a limit. The player takes one daily on time and one daily off time; outside those hours it shows black at minimum brightness. It cannot switch the backlight off, so the panel still draws a small amount of power overnight, and the schedule repeats the same times every day with no per-weekday dates.
What changes when the weather agency is outside the United States?
The intervals hold. Most national agencies run their main forecast cycles every 6 hours and revise in between, so 24 polls a day still catch every release, and weather radar networks scan on similar few-minute cycles worldwide. Point the script at your agency's gridpoint feed and watch the first week of file dates to see how often your local feed actually changes.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.