Wwb UI cache management... why am I managing it?

May I request a stable web UI, one a revision or more behind the current. I really don’t enjoy having to delete and readd my Tablo just to get the web UI to speed up and behave. I would be completely willing to use a different URL to stay on a stable version that doesn’t require the “cache” to be synched again and again.

All I really know is that I had to resynch my android chrome browser on May 24th due to unrelated issues with remote access… And here it is May 28th and the episode lists for my shows where not populating after 60 seconds (tested with 4 shows… Some falsely stated 0 episodes others just didn’t fully load any data) so I’ve had to delete and readd my Tablo today… Which resolved that issue and general web UI performance issues… But why is it necessary for me to have to think of doing this? It should do it on its own, or better yet… Not require this step at all! Get me off your active development platform. I like boring old stability. Dang-nab-it, you make me feel so darn old!!

@Thumbs firmware updates often carry a requirement for clients (web UI, iPad, Android etc) to resync. This is happening often enough because there are many changes on the server end (the Tablo device) that require the clients to grab all the data fresh.

Tablo isn’t quite at that point where everything has stabilized and is generally feature-complete. We are always improving and adding new/planned features, and unfortunately also fixing bugs.

What you’re experiencing shouldn’t be happening and is definitely a bug. As you’ve put it, you shouldn’t have to go through the step of deleting/re-adding just to get things working properly.

Is this happening on a desktop or on the Android you mentioned? What it sounds like is data corruption. That’s a hard one to track down, but I suspect it has to do with the background sync process getting interrupted when the device is turned off/asleep.

If there’s anything at all that you’ve noticed as a trigger, please let me know. I really want to get to the bottom of this issue. Make sure to “@” mention me in this forum so I get pinged by email.

Thanks for the insights @matb33 I can understand post firmware resynchs… but would prefer the clients self initiate the process (after every firmware update maybe) rather than having to experience an issue and then initiate a resynch to resolve the issue… Which is a much worse user experience than a mandatory post firmware resynch.

I’ve had to resynch three devices, one (android tablet) which hadn’t been used since May 9th (my last firmware update) the others were the web UI on android phone and windows 8… These are the ones in contention. Both are actively used and presented issues listing episodes just within the last few days… Which a resynch remedied. They both regularly worked fine prior and had been resynched post May 9th.

Possible recent triggers:

  1. earlier this week I managed conflicts (several dozen) I did it again today to quickly test if this is the trigger… And see the web UI has smarter “rec” buttons now, with a whirly-wig/indicator that it’s doing my command… Until today, I recall pushing the “rec” twice (most times) unsure if I had hit the button on my small screen device… Doing that dozens of times seems to be a possible corruption trigger… Maybe.
  2. earlier this week I switched physical antennas, initiated a channel rescan, which added 5 or so channels.
  3. not me, you. Seems the web UI improves regularly with UI updates and new functionality (the “dog ears” added to shows). Can these updates mess with my Tablo/browser cache?
  4. full disclosure… I’m running chrome browser beta on both android phone and windows 8.
  5. multitasking and session persistence… It’s called a phone because it’s primary purpose is communications and I’m often interrupted with a text or phone call as I’m interacting with the Tablo web UI… When I come back to the Tablo web UI it always authenticates and reconnects, suggesting the lack of session persistence. Hopefully my Tablo has the burden of the background synch process because my phone (running chrome) seems to be a poor device for that. Maybe an android phone app will be better?

I’ll stay alert for a “clear” possible trigger the next time I’m driven to a resynch and let you know. I pity your need to track possible data corruption and hope this was insightful.

Lastly, my current issues are that the “dog ear” show count is too slow to update to be helpful (seems to list a cached value and then eventually update to the current show count… Which completely losses my trust in the feature) also the new “startup section” value seems to reset back to “prime time” after a resynch (seen it happen twice so far… Must be the resynchs). Related? Probably not but good to get off my chest.

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 :slight_smile:

I pushed out an update to the webapp today. I did some fine-tuning to the sync process, and am now able to interrupt the sync process and have it recover gracefully every time (disconnect network or refresh page mid-sync). I’m hoping that might be it, but we’ll see.

You’ll be pleased (not!) that the web app will force you to resync today – apologies. There are some database changes in preparation for the roll-out of manual scheduling that I had no choice but to dump the local database and force a resync. When the firmware update lands, a resync will be forced again.

@matb33 good stuff and thanks for adding the black bar to small screen devices, too.

I just to have to say kudos to the dev team. 
So many small UI updates are really leading to major user experience improvements.
Don’t apologize for throwing down some big effort on the small details. 
The effort brings (just me alone) hundreds of micro-second moments of joy. 
That really adds up.

I trust “dog ears” again because I see the grey flash when they update. It takes longer on my smartphone (slower proc) for the update to occur, so this UI feedback is nice.
I also like seeing the grey flash update after episode deletes, too.
My delete button double-clicks are a thing of the past. Great implementation and very responsive, even on my smartphone.

So please continue to keep the low-end procs in mind. I can attribute a lot of my early web UI issues with the amount of client-side proc load going on due to UI interactions and all the back ground stuff crunching away. Doesn’t seem to be the issue it once was. Kudos.

Thanks @Thumbs! I’ve got some nice features coming up. I revamped the player, and implemented Chromecast. Should be coming soon. My favorite part by far is the skip 30, rewind 20 (via keyboard or buttons), but not because of the 30/20, but because you can skip super fast (i.e. it doesn’t wait for buffering to finish before letting you click skip again). If I know the show I’m watching has around 8 commercials, I hit the right arrow key 8 times really fast and I’m usually back at the show or very close.

Awesome! when is all that rolling out and where is the chromecast implemented from? webui? or all currently supported clients?

@matb33 can’t wait for a revamped player! I’m really looking forward to viewing TV on my phone, as that will be such a value-add to the Tablo experience.

Ultimately, I would love to see a thumbs first approach for fast forward/rewind… As I only have one setup with a keyboard but every setup (except Roku) has a touchscreen. My dream would be to touch the right side of the video to advance it and the left side to rewind. Buttons good enough for thumbs could be nearly as nice.

Regardless, any improvement that delivers speed is first rate. Looking forward to it all.

@Thumbs without a native app for mobile devices, we’re stuck with the default native player. So on iOS, it’s the most basic of players – no skipping whatsoever. Android is even worse as their built-in player is unstable when it comes to HLS. Perhaps one day mobile OS’s will extend their native players so web apps can customize them, but AFAIK that’s not happening any time soon…

@matb33 ya, that figures. I’m eager for a native phone app for the reasons around session persistence anyway. Thanks for managing expectations.

I’m just as eager for player improvements on win8. That currently seems to be a YouTube player (circa 2007) prior to the smart touchscreen era. It currently brings me no joy trying to skip commercials via touch… Any change will be an improvement.

It seems to go without saying, a smart Chromecast implementation would just rock our world! Oh my, just the thought of a persistent Chromecast session across episodes is getting me wide eyed and very interested. Could I even dream of a current Netflix/rdio style implementation in which the player can be pushed down to a bottom control bar while the rest of the UI is interacted with. Ahhh, just the thought of it is enough for me now… Don’t even tell me… Just surprise us.