v2.6.4

v2.6.4

Reverts every encoder change from 2.6.1 through 2.6.3. The Nvidia Shield had regressed.

Fixed

• Animated radar and animated rain/snow stopped working on the Nvidia Shield, a device that had worked reliably through every prior version this session. This was a side effect of three consecutive attempts to fix a black-screen issue on a single low-power projector — requesting a specific H.264 profile and level, disabling B-frames, and widening the keyframe interval. None of those actually resolved the projector's problem, and the cumulative changes broke a device that was already fine.

Changed

• Video encoding no longer requests a specific H.264 profile, level, or B-frame count. Back to letting the encoder pick its own defaults entirely — the exact configuration the Shield ran reliably on before 2.6.1. Keyframe interval is back to 1 second.

Notes

• The low-power projector's animated radar/precipitation still won't work, and that's no longer being treated as an open problem. A device log showed its decoder rejecting a routine buffer renegotiation with the identical error for two different counts offered — the signature of a vendor firmware limitation, not something an encoder setting can work around. Continuing to tune parameters for a device that likely can't be fixed, at the cost of one that demonstrably could, wasn't the right trade. This is already documented in the README and CONTRIBUTING for anyone who hits the same hardware.
• If you're on the Shield or similar hardware, this should look exactly like it did before v2.6.1. If you're on the affected projector, leave Animate radar and Animate rain and snow off — everything else in the plugin is unaffected.

Full Changelog: v2.6.3...v2.6.4

v2.6.3

v2.6.3

Reverses part of 2.6.1, based on new evidence from an actual device log.

Changed

• Removed the explicit H.264 Level 3.1 request added in 2.6.1. A second device log showed the actual failure repeating every ~5 seconds, essentially at the start of every fresh decode attempt rather than partway through a single loop — which disproves the theory 2.6.2 was built on (a repeated SPS mid-stream). More tellingly, the decoder rejected two different proposed buffer counts with the identical error, which reads as a flat refusal rather than "this number is too high."

  Level directly governs how much output buffer capacity a decoder must support, making it a real candidate for having caused or worsened the failure rather than fixed it — the symptom shifted by exactly one frame after that request was added, not away. It's now left unset again, as it was before 2.6.1, so the encoder picks whatever level its own hardware defaults to. Baseline profile and disabled B-frames are both kept, since neither directly drives buffer count the same way.

Notes

• This is an experiment, not a confident fix. If the same failure still appears at roughly the same cadence, that would point to something in this specific vendor decoder that may not be fixable by tuning the encoder at all — at that point, disabling animated features on that class of hardware becomes the more honest answer than continuing to guess.
• No settings changed.

Full Changelog: v2.6.2...v2.6.3

v2.6.2

v2.6.2

A third attempt at the black-screen-during-animation issue — this time based on an actual device log rather than another hypothesis.

Fixed

• Animated radar/precipitation could go black partway through the loop on at least one specific device. A logcat capture from the affected projector showed the real cause: its decoder (OMX.MS.AVC.Decoder, a vendor-specific chip typical of budget Android TV hardware) hit a mid-stream renegotiation event, failed to agree on an output buffer count, and its own driver deliberately blanked the screen after giving up — not a crash, an intentional failure response.

  The most plausible trigger was a repeated SPS (sequence parameter set), re-emitted at every keyframe under the previous 1-second keyframe interval. The keyframe interval is now widened to 10 seconds — longer than either animation's longest possible loop — so each clip is a single keyframe and a single SPS at the very start, with nothing mid-stream left to trigger a renegotiation.

Notes

• Still not confirmed fixed. Please test on the same device. If it still happens, we've at least gone from "cause unknown" to "cause identified, trigger still uncertain" — a real narrowing, and worth another log capture if so.
• No settings changed, no version-visible behavior change if this works — the loop should look identical, just play all the way through.

Full Changelog: v2.6.1...v2.6.2

v2.6.1

v2.6.1

A second attempt at the black-screen-during-animation issue on lower-power devices, based on a much more specific symptom than before.

Fixed

• Animated radar/precipitation could go black partway through the loop, always at the same frame, on lower-power devices. That deterministic failure pointed at something structural in the video stream rather than generic weak-hardware slowness. Two likely causes, both addressed:

  • The video's resolution (1280×720) requires at least H.264 Level 3.1 to be valid by spec at all — the encoder was never told this, so it picked a level on its own, suited to its own hardware, with no guarantee that matched what a separate, weaker decoder chip on the same device could reliably sustain.
  • B-frames were never explicitly disabled. They cost more decoder-side reference buffer capacity than a simple sequence that only looks backward, which fits "plays fine for a while, then fails at the same specific point" better than a level mismatch alone.

  Both are now handled: B-frames are disabled outright, and Level 3.1 is requested explicitly — but only when the device's own encoder confirms it's actually available, so this can't introduce a new failure on hardware that doesn't offer it.

Notes

• Still not confirmed fixed on the actual affected device. Please test on the same lower-power projector before treating this as resolved. If the screen still goes black at the same frame, the cause is something else, and that would be worth knowing precisely — including whether it's still exactly frame 12, or has shifted.
• No settings changed.

Full Changelog: v2.6...v2.6.1

v2.6

v2.6

New feature, a possible fix for a device-specific issue, and documentation catching up to reality.

Added

• Marine conditions — a new Weather info toggle showing wave height and period, wherever there's a large enough body of water nearby to have real data. Off by default. Confirmed to work for both open ocean and the Great Lakes, not just coastal cities.

Fixed

• Possible fix for a black screen during animated radar/precipitation on lower-power devices. The video encoder never specified which H.264 profile to target, so every device encoded using whatever its own encoder defaulted to — often a profile chosen for better compression that some weaker or older hardware decoders can't play back. Now requests the far more universally-compatible Baseline profile, but only when the device's own encoder confirms it supports it, so this can't break encoding on a device that previously worked fine.

  This is not yet confirmed fixed — please test specifically on the affected device before treating it as resolved.

Documentation

• The screensaver interaction is now stated plainly, not left as an unstated risk. Turning on animated radar or animated rain/snow can prevent the screensaver from starting while they're active — this is now confirmed behavior, not a hypothetical. It comes from how video playback signals the system to stay awake, which is outside this plugin's control. This almost certainly applies to any video wallpaper, including community video packs, and the contributor guide now says so.
• Marine conditions was missing from the README's feature list despite being fully implemented — added.

Notes

• No settings were removed or renamed. If you're updating from 2.5, nothing you had configured changes.

Full Changelog: v2.5...v2.6

v2.5

v2.5

Everything since v2.4.3.

Added

• Satellite imagery background, from NOAA's GOES satellites — public domain, keyless. A close crop for the continental US; a whole-Earth view from the nearest satellite elsewhere, where one is usably in view; a plain "not available here" for the real gap in coverage, roughly the Middle East through Southeast Asia, where neither satellite has a usable view.
• Real moon phase. The night scene used to draw a fixed crescent regardless of the date. It now shows the actual current phase — new, crescent, quarter, gibbous, full — computed from the date with no network call, and correctly mirrored for the Southern Hemisphere, where a waxing moon is lit on the opposite side from what Northern Hemisphere viewers see.
• Reduce screen burn-in — a subtle, slow pixel-shift applied to the panel, on by default, to spread wear on OLED and plasma displays. Imperceptible on anything else.
• Settings reorganized into 8 categories — Location, Appearance, Weather info, Clock, Screen & layout, Experimental, Demo mode, Housekeeping — replacing one long scrolling list.

Fixed

• Weather for a location far from the device's own time zone could show the wrong day/night phase, wrong-timed advice, or the wrong "yesterday" comparison. All three had been using the device's clock instead of the displayed location's, which only matters when they differ — most visibly for New Zealand viewed from a US-based device. Fixed using the location's own UTC offset.
• The radar map's credit line was wrong. It named OpenStreetMap regardless of settings, even though the map has been drawn from bundled Natural Earth data for a long time. Now credits correctly.
• Three separate settings had ended up silently duplicated during earlier development — a checkbox appearing twice in the list, a duplicated string resource, and a duplicated internal property — all traced back to the same root cause and all now a single, correct copy each.
• A community pack description still claimed animated (Lottie) packs kept the weather readout, a claim already corrected in the contributor documentation once the Lottie limitation was found, but never fixed in the app itself.

Removed

• The Lottie self-test diagnostic tool. It existed to answer one question — whether the launcher could load a Lottie animation from this plugin's URI at all — and it already gave a clear answer, so it was just clutter after that.

Notes

• Satellite coverage depends on which of two US weather satellites can usably see a given location; there's a real gap with no free alternative.
• No settings were removed in the reorganization, only regrouped — anything you used before is still there, just under one of the 8 categories.

Full Changelog: v.2.4.4...v2.5

v2.4.3

v2.4.3

Fixes a build failure introduced in 2.4.2. No functional changes.

Fixed

• worldEventWallpaper and localVideoWallpaper were accidentally deleted while editing 2.4.2, the same class of mistake as an earlier build break — a file edit that removed more than intended. Both are restored exactly as they were; neither was meant to change.

Notes

• If you never managed to install 2.4.2, this is the version to use instead.
• World weather watch and local video backgrounds are unaffected in behavior — they simply didn't compile in 2.4.2 and now do.

Full Changelog: v2.4.2...v2.4.3

v2.4.2

v2.4.2

Fixes the blank animated radar screen introduced in 2.4.1.

Fixed

• Animated radar and animated rain/snow could return a blank wallpaper. Both encoded video synchronously, inline, inside getWallpapers — a Binder call with a hard timeout of a few seconds. 2.4 stayed just under that limit at 7 frames; 2.4.1's move to 13 frames for smoother motion pushed the same inline encode over it on slower hardware. When a Binder call times out, the caller gets nothing back at all, which is why this showed as an empty screen rather than an error.

  Both now return immediately. If a previously-encoded video is still valid, it's served right away; otherwise a background thread encodes while this refresh falls back to the still wallpaper, and the launcher is asked to check again once the new video is ready — typically within moments rather than the next full refresh cycle. Encoding can no longer block the call that serves the wallpaper, regardless of frame count or device speed.

Notes

• No settings changed. If animated radar or animated rain/snow were already enabled, this takes effect immediately with no action needed.
• Worst case now is one still-wallpaper refresh while a video re-encodes, rather than a blank screen.

v2.4.1

v2.4.1

A follow-up to 2.4, tuning the animated radar now that it's actually working.

Changed

• Animated radar uses all available frames instead of every other one. The
  previous version skipped alternate frames to keep an embedded Lottie file
  smaller — a constraint that no longer applies now that radar is encoded as
  video. Skipping them was pure loss, so all frames RainViewer provides are now
  used.
• Typically 13 frames instead of 7 for the same two-hour window, roughly
  doubling the temporal resolution — about one frame every 10 minutes rather
  than every 20.
• The hold per frame was shortened to compensate, so the loop plays back at
  close to its previous length (around 5 seconds) rather than taking twice as
  long to cycle through twice the material.

Notes

• Encoding takes a little longer and produces a slightly larger file, since
  there's roughly twice as much source material to draw and compress each
  refresh. Memory use is unaffected — frames are still composed and discarded
  one at a time.
• No settings changed. If animated radar was already enabled, this takes effect
  on the next refresh with no action needed.

Full Changelog: v2.4...v2.4.1

v2.4

v2.4

Animation finally works, and the plugin can now tell you when there's a new version.

Includes everything from 2.3, which was built but never released.

Animation, rebuilt from scratch

Animated radar had rendered blank on an Nvidia Shield since it was added. A diagnostic built into the previous version found why: the launcher renders Lottie shape layers correctly, but never displays embedded image assets. Radar is raster imagery, so a Lottie made of image layers could only ever be blank. No amount of fixing the file would have helped.

• Animated radar now encodes a short H.264 video on the device and hands that to the launcher, which plays it through a media player. The radar, the vector map, the weather panel and the severe weather banner are all part of the frames, so nothing is lost.
• Animated rain and snow likewise. The falling particles were shape layers and would have worked, but the scene behind them was an embedded image — rain would have fallen over nothing.
• Animated wallpaper packs now work, and are no longer behind the Experimental toggle. A contributor's Lottie is vector artwork, which renders fine. The only thing that ever failed was the weather panel the plugin injected into it. That injection is gone, so packs play exactly as their author made them: motion without the weather readout, the same trade as video packs.
• Frames are composed and encoded one at a time, so memory stays flat regardless of loop length. Encoding runs at 720p, which upscales acceptably for radar and is several times faster than 1080p.

Added

• Look for updates — Never, Weekly, Every two weeks, or Monthly. Weekly by default. When a newer release exists, a small line appears alongside the on-screen credits, and the Check for updates action says which version is waiting.

  It only ever notifies. Nothing downloads or installs on a schedule — an app that silently replaced its own APK would be alarming, and updating stays your decision. The first check runs shortly after installing rather than a week later.

Fixed

• The background reloaded every few seconds. Timestamped output filenames, added so the launcher couldn't serve a stale cached image, meant every request returned a new URI — and Projectivy re-requests on its rotation interval. The rendered file is now reused unless something affecting its appearance has actually changed.
• In-app updates downloaded but wouldn't install, with no permission prompt. REQUEST_INSTALL_PACKAGES isn't a runtime permission, so no prompt is possible — it's a special app access granted in Settings. The updater now checks first and opens the right screen. On the Shield: Settings → Device Preferences → Security & restrictions → Unknown sources.

Corrected documentation

CONTRIBUTING.md previously stated as fact that animated Lottie packs kept the weather readout. That was published before it had been tested on hardware, and it was wrong. Apologies to anyone who built around it.

It now explains the real constraint for animators: vector renders, raster doesn't. Shape layers, paths, fills, gradients, strokes, trim paths, transforms and keyframes all behave. Anything embedded as an image will be absent.

Still to verify

The two animation options remain behind Experimental features, off by default, because on-device video encoding is new here and untested across devices. Encoding takes a few seconds per refresh, and everything falls back to a still wallpaper on failure.

One known trade-off: video playback often keeps the screen awake, so these may prevent a screensaver from starting. If that happens it's inherent to the approach rather than a bug — turn the animation off. The alternative would be redrawing radar as vector contours, which would render but couldn't carry the weather panel.

Full Changelog: v2.2.1...v2.4