webOS v4 R416 fails to clean stale widget JSON/library entries after CMS content changes; stale GetData requests persist
Environment
- CMS: Xibo CMS 4.5
- Player: Xibo for webOS v4 R416
- Player package:
Xibo-for-webOS_v4_R416.ipk
- Display: LG webOS display 23 (
webOS_dev)
- Display client type/version:
lg, client version 4
- CMS location/timezone: America/New_York
R416 is the current webOS v4 release; Xibo’s announcements list R416 as released July 1, 2026.
Symptoms
We restored a CMS/database environment to a Xibo 4.5 server. The WebOS players had previously failed to update weather on the older server as well.
For display 23, the current CMS schedule referenced WeatherTest / layout 458 and ForecastIO widget 3504. The CMS’s RequiredFiles response correctly contained widget 3504 and layout 458.
However, the R416 player retained obsolete widget/layout/library state from the previous content set and repeatedly requested obsolete widget JSON files.
We instrumented the CMS XMDS endpoint temporarily to capture the widget ID contained in GetData requests.
The player repeatedly generated requests such as:
widgetId=9
widgetId=9
widgetId=9
widgetId=10
widgetId=10
widgetId=8
The CMS HTTP logs showed the corresponding GetData requests returning HTTP 500.
The Player’s own submitted logs also showed:
Download widget data file failed!
Download error 9.json
Download widget data file failed!
Download error 10.json
while the player was simultaneously reporting layout 458 as valid.
Important test
We used the Player’s normal Purge All function.
The R416 source shows that Purge All calls:
LibraryManager.r.clearAllFiles();
ScheduleManager.P.resetPlayer();
CMS.A.connect();
and clearAllFiles() sets:
v_RequiredFiles = [];
localStorage.library = [];
Despite this, after reconnecting and restarting the player, the stale widget requests returned.
We again captured the requests and saw the same obsolete IDs.
This strongly suggests that stale persisted/player-library state is being reconstructed during subsequent schedule/RequiredFiles processing rather than simply being left untouched by the purge.
Code path identified
In the extracted R416 JavaScript, parseRequiredFiles() begins by calling:
CacheMgr.y.clearJSONFiles();
which empties the Player’s in-memory jSONFiles collection.
Later, during the cleanup/storage stage, the code calls:
LibraryManager.r.removeJSONFiles();
The original R416 implementation of removeJSONFiles() starts with:
JSONFiles = CacheMgr.y.getJSONFiles();
unUsedFiles = markRemove.files;
filesToRemove = JSONFiles.filter(function(file) {
return unUsedFiles.some(function(u) {
return u.filename === file.filename;
});
});
Because clearJSONFiles() has already emptied the JSON list, JSONFiles can be empty at the point removeJSONFiles() executes. Consequently, obsolete JSON/widget files may never be selected for removal.
There is also a separate apparent type mismatch.
The R416 implementation of:
this.removeFile = function(filename)
searches v_RequiredFiles using:
v_RequiredFiles[i].filename === filename
but both observed callers invoke it as:
LibraryManager.removeFile(file)
where file is the file object.
This means the comparison can effectively be:
"9.json" === { ...file object... }
which cannot match.
We observed this same call pattern in both the JSON cleanup path and the storage-pressure cleanup path.
Result
Because the obsolete entries aren’t successfully removed from v_RequiredFiles, the subsequent download/library processing can continue to include the stale widget JSON files, and the Player’s persisted library is then saved again.
This matches the observed persistence of obsolete widgets across:
- normal reconnect
- Player restart
- CMS-side Purge All
Weather result after clean reset
As a control, we eventually performed a factory reset of the LG display, installed the unmodified official R416 IPK, reconnected it to the same CMS, and left the layout/content unchanged.
After that clean Player state was established, the Weather widget began updating successfully on display 23.
That is strong evidence that the CMS Weather widget itself is functional and that the stale Player-side library/state was a significant part of the observed failure.
Additional context
All WebOS displays in the original environment had previously failed to update weather on the older CMS/server, so we do not yet know whether the R416 library problem explains the original fleet-wide failure or whether there is an additional Weather/GetData issue.
There is also an existing Xibo issue concerning WebOS/weather behavior: #3880, “Weather widget: displays showing different weather data,” which was open as of the current issue listing.
Requested investigation
Please investigate whether R416 has a bug in its RequiredFiles/library reconciliation sequence whereby:
clearJSONFiles() empties the JSON tracking list before removeJSONFiles() uses it.removeJSONFiles() therefore fails to identify obsolete JSON files.removeFile() is called with a file object instead of the filename expected by its implementation.- Obsolete widget JSON files remain in
v_RequiredFiles / localStorage.library.
- The Player subsequently continues attempting
GetData for widgets that are no longer present in the CMS schedule.