A ticker is drawn by the player's web engine on the CPU, frame after frame, and a low-power Android box runs out of its 16.7 ms frame budget, so the scroll stutters and the not-responding dialog can follow. Update the player and CMS first, cut the ticker band height, keep video off the same layout, and move marquee content to a stronger box if the symptoms survive.
Marquee scrolling is the heaviest thing an Android signage player draws. The ticker line is rendered by the player's web engine on the CPU, frame after frame, and a low-cost box runs out of frame time first, so the scroll stutters while everything else on the layout looks fine. The "app is not responding" dialog is Android stepping in when the player's main thread misses a deadline. Both problems have fixes, and the order matters: update the player and the CMS, shrink the ticker region, then decide honestly whether the box has the compute for marquee content at all.
Why the ticker strains the CPU while video stays smooth
The player draws the ticker with its web engine, the same text-and-layout machinery that builds the rest of the screen. A marquee animates continuously, so the engine works on that region every animation frame for as long as the ticker is on screen. Marquee scrolling is intensive work for a web engine, and the rendering improvements that exist for it reach the player through CMS updates, so an out-of-date CMS keeps the heavy drawing code in front of the box.
Video does not share that path. A layout's video playback is handled by the platform's media pipeline, designed to decode video separately from the web engine's drawing work. That is why one layout can play video smoothly and still stutter on the ticker: the video pipeline has headroom and the CPU-side web engine has none.
The budget is small. A panel refreshing at 60 frames per second allows 16.7 ms per frame, because 1000 ms divided by 60 is 16.7. That allowance covers everything on screen: the marquee, the slides, the clock. When the marquee pushes the per-frame work past it, frames get dropped and the scroll visibly jerks.
Symptoms and what each one points to
- The ticker stutters while video in the same layout plays smoothly. The web engine has run out of frame time; the video pipeline is fine. Video trouble looks different, a black region where the picture should be, and Android signage player shows a black screen on video covers that failure.
- The identical layout, feed and network run smoothly on a stronger box and jerk on the low-power one. The difference is CPU headroom on the box. This is the cleanest test there is, and it settles more than any amount of settings work.
- Android shows the "app is not responding" dialog, with Wait and Close, during playback. The player's main thread missed a deadline the platform sets. Android's own documentation gives an app 5 seconds to answer an input event and 10 seconds to finish a foreground broadcast receiver; miss one and the system offers the dialog. On a screen with no touch input those deadlines still exist. This is a bug in the player app's timing, so the fix ships with a player update.
- The line scrolls at an even speed but bounces slightly up and down as a whole, and the bounce changes with the text content. On Android boxes this is a container sizing quirk in the web rendering; Windows players scroll the same content clean. It is a rendering artifact, not load, so hardware changes will never remove it: report it to the player vendor and plan around it.
- Feed items are missing or stale. That is data retrieval, upstream of rendering. Check the feed address and the CMS side first, because a dead feed and a jerky scroll have different fixes.
Checks, in order
- Confirm the feed arrives. Current items should be visible in the region. If they are, retrieval works and the problem is rendering.
- Update the player app. Look through the release notes for a fix to the not-responding dialog. Vendors treat that dialog as a player bug and do ship fixes for it.
- Update the CMS. Marquee rendering improvements are served from the CMS, so an old CMS keeps serving the heavy drawing code even to a fresh player build.
- Run the identical layout on any second player you have, over the same network. Smooth there and jerky on the low-power box closes the case: compute. This is the same discipline as testing media on the exact box before rollout, which video bitrate for signage player: test before you deploy applies to video files.
- Re-read the symptoms. Dialog gone but the scroll still uneven: continue with the layout work below. Dialog still appearing: the box is undersized, and the decision is hardware.
Example: trimming a 1920 x 120 px ticker band on a low-power box
The inputs: a layout canvas of 1920 x 1080 px, the standard Full HD canvas most layouts are built on; a ticker band spanning the full canvas width and 120 px tall, a common bottom-bar ticker, chosen here as a typical case; and a 60 frames per second refresh target, the rate Android aims for on a normal display. The frame budget follows from the rate: 1000 ms divided by 60 is 16.7 ms per frame.
The rule: the recurring pixel work of a marquee scales with the animated area times the frame rate. It is a first-order model, enough to see where the load lives and which change buys what.
The arithmetic. Band area: 1920 px x 120 px = 230,400 px. Per second at 60 fps: 230,400 px x 60 = 13,824,000 px/s, about 13.8 million px/s of pixel work, every second, before anything else on the layout runs. Cut the band height to 60 px and the work per frame falls to 1920 px x 60 px = 115,200 px, so 115,200 px x 60 = 6,912,000 px/s, about 6.9 million px/s. The width factor works the same way: a 960 px band across half the canvas cuts the per-frame work in half again.
The result: halving the band height halves the recurring load, and the headroom left inside each 16.7 ms frame roughly doubles. The decision: band height moves the load exactly with it, so cut it before anything else. If the box still stutters or still shows the dialog with the band at 60 px, 115,200 px per frame, it has no marquee headroom. Swap the marquee for a static text item that changes on a timer, say every 10 seconds, or move ticker layouts to a player with more CPU headroom.
The fix, in order of cost
First, software. Player update for the not-responding dialog, CMS update for the marquee drawing. Both are an afternoon's work and undo the worst of it.
Second, the layout. Cut the ticker band height, as the example above works out. Keep everything else on the layout static, so the marquee is the only region animating every frame. And think hard before a ticker shares a layout with video, because video eats the same frame budget, and a video plus a webpage region on one layout has a harder conflict of its own: why a video and a webpage region will not play at the same time.
Third, keep it readable. Whatever height the band ends up, check the letters against the farthest viewer before you commit; the letter-height and distance math is in what size digital signage screen do you need?.
Fourth, hardware. If the dialog or the stutter survives both updates and the smaller band, stop putting marquee layouts on that box. Keep it for static shows: slides, timed text, menu boards with no animation. Put ticker content on a player with more CPU headroom, sized with your heaviest layout in hand. Our panel-mount displays are Android all-in-ones with the player software included, and the displays category lists the sizes; whichever hardware you buy, run the ticker layout on the exact unit before you commit the wall. For a factory notice board where the ticker is the whole message, a dedicated industrial scrolling marquee sign driven from the control system is a separate path that leaves the signage player out of the loop.
Recommendation: Update the player app and the CMS before you touch anything else; they fix the not-responding dialog and carry marquee rendering improvements. Then cut the ticker band to 60 px or less on a low-power Android box and keep it off layouts that also play video. If the stutter or the dialog survives those changes, treat the box as undersized for marquee content: run it with static slides and timed text, and move the ticker to hardware with more CPU headroom.
Questions
Will a faster network or storage stop the ticker stutter?
No. The feed items and the media are already on the box before the scroll starts; the stutter happens while the web engine draws each frame. Network and storage upgrades never reach that stage. Spend the effort on the layout: a shorter ticker band, no video sharing the frame budget, and current player and CMS software.
What should I do when the not-responding dialog appears on a live sign?
Choose Wait so the player keeps running through the current showing. The dialog is the platform reporting that the player missed a deadline; closing it takes the app down. Treat it as a player bug first: update the player app and the CMS, then slim the layout so the marquee is the only region animating every frame.
Can I keep the box and just remove the scroll?
Yes. Replace the marquee with a static text item that changes on a timer, say every 10 seconds. The layout then redraws only when a slide or the text item changes, which is the same work a slide show already does. A box that janks on a marquee will usually run that kind of show cleanly.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.