Ground truth is the value that exists in gracenote.
The local record is a cached value of that ground truth.
The view displayed is a cached value of the view constructed from that local record.
Presumably we agree that
- what is displayed (showing channels that the user has removed)
- is not what should be displayed.
So we agree there is a bug.
OK, next, why is the bug occurring? Because it's considered too expensive to reconstruct on demand the view that should be displayed on every display occurrence.
Now if you want to call this something other than a cached view, and if you want to describe the problem as something other a (lack of) a cache invalidation protocol, well you can invent your own special purpose terms. But it's unclear what the point of that is, given that ever SW (or for that matter HW) engineer in the world understands the problem immediately in terms of a cache that is being operated without an invalidation protocol.
I don't blame the engineers. The web sucks in many ways, and this is one of them.
The basic problem they have is that if I open one web window, where I modify the channel line up, and have a second web window open showing the On Later display, it is not completely trivial to connect these two so that a change in one immediately (or which a delay) triggers a change in what is seen in the other window. It's not impossible, but it does mean that a robust design that was working well (database backend serving up static HTML) has to be modified to also serve up JS.
But an-easy'ish solution to this is the old Windows solution -- add an F5 key to the On Later page. Yes, it seems an admission of defeat to have an F5 key, but it's a lot better than the alternative of simply displaying stale data. Sometimes you admit defeat, admit the UI is not perfect, add a simple workaround, and move on...