Why is sync so slow?

General Discussion
21
There should be some way to fix this, maybe I've missed it.

Also, wild guess… If the TaboTV interface relies on Javascript… and you’ve disabled that in any of the browsers… that would cause some issues. Though, I’d be surprised anything works if JS is disabled (and it uses it at all).

22
Some things to try:
Try closing and reopening your browser (instead of rebooting).

Tried this many times, no effect.
Try a different browser (firefox instead of chrome - or the other way around).

Try a different browser (firefox instead of chrome - or the other way around).

I’ve never been able to get Tablo to run in Firefox (my preferred browser, really don’t like Chrome)

Try clearing all your browser’s caches.
No effect.

Try an incognito tab in your browser (disables the browser cache for that tab).
Don;t know anything about that or how to do it.

I didn’t mention, and not sure if it matters, I have a 4 tuner Tablo.
23

You also didn’t mention whether the Tablo itself is wireless or hard wired. Hard wire it if it’s not already so.

24

@Doobe What happens on the PC’s having issues? Do they just ‘hang’ on connecting or syncing?

It sounds like this is easy to reproduce for you, so next time hit happens hit F12 and select the ‘console’ tab while the browser is hung. Copy and paste the logs and send them to me and we can take a look at what your browser is reporting.
25

The Tablo is hard wired to the router. On the PC’s, the Tablo shows up as having synced, everything operates just fine, only the new recordings don’t show up in the list of recorded shows unless I reboot the PC. This only happens on the PC’s that are connected wirelessly, the PC that is hard-wired into the router updates the recordings just fine.

26

I have to agree the biggest show stopper with this device is the constant syncing ( it seems that every single time I want to watch remotely it needs to sync) and boy it takes a long time! then you have the crazy slow time to delete something, switching channels while on live TV needs to be speed up too, agonizingly slow right now.

1 Like
27
@Eli

Sycning on my iPad Air and iPhone 5 both running iOS 8 using Tablo Connect (aka connecting remotely) takes about 30-60 seconds if I open up the apps daily. If it is a few days between sycning then maybe 3 minutes. Is that too long for you?
28

@Eli We implemented some optimizations for syncing in the last firmware update, but it can still take some time depending on the size of your Tablo’s database. I know this doesn’t exactly help, but the syncing is really dependant on two things (neither of which we can do too much about): 


- The ‘size’ of your Tablo’s database (think in MB’s here)
- The speed of your LAN (or Internet if you’re remote). All that’s really happening is a file transfer from device A to device B. Just depends on how quickly it can get there.


29
neither of which we can do too much about

What is fundamentally different about how the Roku can display entries quickly but the app and web need long sync times? You mention LAN in the above post, so that must not be it.

30

@cedarrapidsboy

This slow sync time you speak of is not universal to everyone using the web app, so I wouldn't say it's fundamentally different. But there are a multitude of other factors at play other than the speed of someone's LAN - client device, browser version, Android OS or iOS version, etc.

31

This slow sync time you speak of is not universal to everyone using the web app, so I wouldn't say it's fundamentally different. But there are a multitude of other factors at play other than the speed of someone's LAN - client device, browser version, Android OS or iOS version, etc.

The fundamental difference is that Roku does not front-load with a synchronization. It seems to load things as-needed.


The web app and Android app has a variable-length-depending-on-multiple-factors sync process before it lets you into the interface.
32

@cedarapidsboy The Roku doesn’t sync - at all. There isn’t persistent storage large enough, there’s no SQL database libraries and there’s no support for WebSockets.


The rest of the clients request and build all of the information and updating it all at once so you can browse through it all quickly. Once you’re sync’d, the information is in the ‘back pocket’.

The Roku will just request one thing at a time as you look for them. That’s what the ‘retrieving’ spinner is for anytime you switch from one tab to the other. As you can imagine, the larger the Tablo’s database (or the larger that part of it you’re trying to access) the longer it’s going to take to populate that information. 

Hope this helps!
33
Hope this helps!

That does. Thank you.


As feedback… I find the experience on the Roku (with the wait time distributed across the operations vs. front-loaded) more appealing than the web experience.

I do not use the web interface every day. It comes out on the weekends… so I always have a week or so of data to sync. Also, I’ll use one of three devices - so depending on my choice I may have more than one week between syncs.
34

I’d tend to agree with @cedarrapidsboy that the distributed wait time makes for a more “consistent” experience.


I’ve spent some time with my Roku in dev mode to look at the API for that platform, and over at AVSforums there is a bloke who has reverse engineered the websockets API.  They are two very different operating paradigms.  The websockets API leaves all of the heavy lifting to the client, whereas the Roku API is much more “chatty”, as you’d expect, but doesn’t deliver as “holistic” a view as the websockets API (e.g. no detailed list of what’s showing and what’s coming up).

Based on the hints that have been dropped, I’d expect the Roku API to become a bit richer in terms of what can be delivered.  
35

I would actually like to see client side sync complete removed … and like the Roku, things served up to (any) end client as needed… one of the single most frustrating things about the tablo (if I had to pick one) is if you haven’t synced in a while the wait just to play something you know is there can be very frustrating … granted they have done a better job in recent releases speeding up sync… but I honestly have a hard time (and I am a CS graduate myself with a specialization in relational databases so I do know what I am talking about) understanding why all of that can’t just be served “on demand as needed dynamically” to the client from the Tablo itself and why you have to sync or even keep anything on the client side at all other than some minimal operational data for the current session…

36

Taking a wild guess.  Some of the data is not from Tablo, but from their guide provider and maybe having doing on demand pulls is not a good idea (?).  With the data cached, less pulls from the guide provider.  Again, I’m just taking a wild guess.


37

@TabloSupport


I would also like to respectfully suggest that performance of the Tablo web client sync process is more dependent on Tablo’s implementation rather than network performance.

Meteor Javascript Framework

I am a web developer, and I have looked at the console logs and Javascript resources on my Tablo’s web client page via Chrome’s developer tools (by pressing F12).

I see is that Tablo is using the Meteor Javascript framework. I haven’t used Meteor personally, but I know that Meteor is designed to simplify development of web/mobile client applications that automatically stay in sync with a server. I have also read that Meteor-based applications must be carefully designed when performance is important.Please see references to Meteor and Meteor performance at the end of my post, below. Please feel free to share the performance tips with the development team. :slight_smile:

My comments below are focused on the performance of loading thumbnails. I realize that what appear to be simple JPEG images on screen are more complex than that due to the Meteor framework.

Sync Performance

The next thing I observed in Chrome’s console log is that you can watch as a log statement is displayed for each thumbnail as they are slowly syncing. Each log statement includes the exact URL of the thumbnail on your Tablo device. So I copied a few URLs and pasted them in new incognito tabs (hence no browser cache).

What I found was that each thumbnail is taking roughly 205 to 210 milliseconds to load for me. The most interesting thing is that about 92% of the response time for loading each thumbnail is spent waiting for the Tablo device. The actual network transfer time is only about 6% of the response time.

To see this, go to the Chrome developer window. Click the Network tab, and hover over the colored timeline for loading a thumbnail URL. The important time is the TTFB (Time To First Byte). See this for a description of TTFB 

To me, this shows that the performance bottleneck is the Tablo device and/or the web client code, not my network. This would correlate with the fact that I can load pages of similarly-sized thumbnail images from just about any internet site extremely quickly.

Thumbnail Size

Each thumbnail appears to be around 15-20 kilobytes. In my case, I have 194 thumbnails in the Prime Time view. This totals about 3 to 4 megabytes. Assuming the Tablo has at least a 10 megabit/second network interface (approx 1 megabyte/second), the entire payload of thumbnails should load in about 3 to 4 seconds.

Design Changes

I agree with the other posters that changes should be made to the Web client design, giving performance a high priority. Here are a few ideas:

- Use smaller thumbnail images
- Show placeholders for each thumbnail with text underneath, and allow the page to show (with loading spinners) BEFORE all thumbnails are completely loaded
- Paginate the thumbnail pages, showing a small number at a time (would require page forward/back controls)
- Return an array of thumbnails in one call, rather than one thumbnail per call (to reduce the number of calls to the Tablo)
- Consider using standard AJAX calls vs. Meteor syncing for thumbnails. Such calls might even take advantage of HTML 5’s Web Workers to run Javascript code in the background.

These are just a few thoughts based on what I can see. I look forward to hearing your reply.

Regards,
John

Meteor Framework

Meteor Performance

38
@TabloSupport

I would also like to respectfully suggest that performance of the Tablo web client sync process is more dependent on Tablo's implementation rather than network performance.


I forgot to mention, here are my Tablo version numbers:

Tablo Device:     2.1.24
HTML Application: 1.0.15-471

39

We’re not using Meteor in a typical way. We use blaze/spacebars and tracker, along with their build tools – effectively only using Meteor for its client-side tech. If we were using Meteor on the server (I.e. on the Tablo hardware), we wouldn’t have to go through a sync copy process, but we’d need a far more powerful cpu to run nodejs… The images also aren’t being synced. What’s coming over the wire during the sync is basically your database, and subsequent syncs are patches to keep the database in sync with the database on the tablo. That database will contain a url to the thumbnails, not the thumbnail image data itself. In the webapp, the image is fetched like any other web site, via img src, and doesn’t block the ui rendering. The tablo has a tiny web server that is capable of serving those images, among other things.

Being able to fetch exact sized thumbnails is something I really want as well – we are exploring ways of doing this without too much burden on the tablo hardware.

Btw when you are seeing images during sync, this is literally just for show… It’s not actually syncing images. It’s syncing an entire database. I simply happen to look at the data flying by and if I see a particular type of image url, I use it to show the image animation, just to help make the sync feel less boring.

Hope that helps clear some things up

40

Connecting time 30 minutes to 1 hour, syncing once connected a couple minutes. Not happy with product.