Hi @Thumbs, thanks for the list. Just to clarify: a user-initiated resync should never be necessary, and is currently being used as a stop-gap until we get to the bottom of this issue.
Traditionally, web apps let the server do most of the heavy lifting, i.e. querying against the database on the server to determine what should be shown on the current screen. In the case of the Tablo, the role of heavy lifting was intentionally put on the client as the Tablo device needs all the CPU resources it can get. What all this implies is that the Tablo and client have an non-traditional relationship in that the entire database is sent to the client (that’s the “Sync” screen you see) and diffs are sent on an ongoing basis (in the background, except when playing video) in bunches of “add”, “update” and “remove” commands.
The trouble is if any of those packets are mishandled at all, the client database goes bonkers. And that’s where I believe we stand with the issues you’ve been having. Whereas traditionally with the server doing the heavy lifting, there’s no need to worry – there’s only one point of failure (the server) and the client is dumb in that it just displays whatever the server tells it to. This is just generally easier and safer to deal with. Anyway, that’s not your problem! But just giving some background on where I think the issue lies.
1) Based on your comment, I now disable the button while it’s “spinning”. Although curiously the spinner has always been there, but recently was switched to an SVG icon… so I’m not sure how you saw a REC button without a spinner.
2) I’m going to play with this scenario. QA has done extensive testing in that regard, but perhaps a bit of extra abuse of rescanning might recreate something
3) Those updates wouldn’t mess with the local database. If the numbers are incorrect, it means there’s data missing in the database, i.e. a sync operation fell through. If a resync fixes it, that means the database on the Tablo itself is just fine, and the local database is corrupt. Clear indication of a buggy sync.
4) Shouldn’t be a problem. If you were using Firefox or IE10+, I’d be concerned as they use an entirely different database tech (IndexedDB instead of WebSQL) and that carries a whole other set of queries & additional logic that is still not stable.
5) Well it’s not a traditional web app in that it doesn’t follow RESTful principles – in fact it’s got a socket open for bidi communication (websockets). When you leave the browser, that websocket connect is often closed (as you experience on your smartphone). We don’t have a choice but to re-establish the connection and go through the whole rigmarole of connect & auth. I think the best option here is to make the reconnect seem more transparent, i.e. hide the reconnect process if we can determine that we are restoring the connection.
As for the “dog ear” show count being slow to update – that count is “live” and queries the local database. Again, if it returns an incorrect number, it means the local database is out of sync. If it eventually does return a correct number after a short pause, then it’s working as intended. The server pushes updates to the database (the diffs I mentioned) at its own pace, and as soon as I receive them, then the UI updates taking into account the updated data. But on the other hand, if it gives a false number indefinitely, then we’ve got a client database corruption issue.
Finally, for the “startup section” feature – that gets wiped because it’s an experimental feature that only the web UI has, so the Tablo doesn’t persist that value in its server database. It only gets persisted in the web local database. I expect that since this feature has proven to be popular, it will eventually be applied to all other client apps, but that will necessitate a change on the Tablo device (firmware update of course) to be able to persist that setting on the Tablo itself instead of in the local database.
Thanks
@Thumbs for the insight, I’ll be messing around trying to break the database today
