I agree - I wish I could schedule things 30 days at a time, but that’s me.
Out of curiosity, how many channels are you guys syncing? I’m in a dual market so I’m at about 55. I really need to weed it down as I will never watch some of them. Just feel like since I can be getitng them I should 
@TabloSupport understandable .. we are merely bickering amongst ourselves .. :-) You guys just keep up the good work and enjoy CES.. We know you guys are doing great things! I trust you guys.@Jestep -- I think you are missing what I am suggesting .. like a "web page" you dont need to download the entire website server contents just to browse a few pages .. think of it like that.. Do you really want to download all of Amazon.com's product database just to browse a few items? .. I'm suggesting they just dump the entire concept of a "sync" completely.Do you think they do a sync for the Roku? I am thinking no.
IS there a thumbs-up icon around here anywhere? That’s my point. Run a web server in the Tablo, access it directly and show only what’s requested at that particular time. I have built and maintained web servers, I have designed sites and currently maintain a large auto-related forum and there’s gigs of data, the SQL database has several gig, the web structure itself, all the ASP files and pages take up a few meg - but the browser displays only what it takes to build that page and content you are interested in. That is OVER THE INTERNET as Internet speeds. We’re talking local network speeds where it’s always fast with almost zero latency compared to what for ping times to your favorite web server? If you can stream from a web server in Europe to the states then you can load a little content from a Tablo over a local LAN in blazing speeds. You’d think you were flying through space at ludicrous speed.
I can use my computer or phone to access the exact same program diplay and same type and amount of content from a web server half-way around the globe, there’s no syncing, so why sync or have to cache content from a local device with no hops between, no latency at all? The Tablo itself is all but a local drive or device to your computer or tablet so why would sync be needed?
You have NAS on home networks, right? Is that content cached or synced to your computer or do you reach across your local LAN to get it as needed? Tablo is like a NAS on your network to your computer, same speeds! Why sync?
@ericgus, so how would you schedule a show that is playing on Saturday? You would need that data locally.You have to have the data for 14 days in order to schedule something that far out.I understand the way you are looking at it, but I want to be able to schedule things other than the next 12 or 24 hours.Sounds like a personal preference to me.
No, you do not need that data locally! Web sites that you order things from - same exact concept! The info is on the Tablo, clicking is like clicking a button and sends a command TO Tablo. The computer isn’t recording, TABLO is, so why does content need to be on the device? the content needs to be on Tablo, the phone, tablet or computer is just an interface, it’s just a set of buttons.
If you click a button to post a message here, the web site and database is not on your computer, it’s on the server. You tell your browser to “send this text to… and do this with it”. Same could be done with Tablo.
Will Tablo still record if you take your iPad or tablet or phone away or turn it off? Yes, it will - so why does that need to be on the iPad or tablet or phone? the phone doesn’t trigger Tablo to record, it tells Tablo to record by configuring code or software that’s on the Tablo.
If syncing was required then anything you did would have to be downloaded to your computer or phone and you’d never be able to turn it off or leave with it. The device is an interface to program Tablo, the device isn’t waiting for 2 days and then sending a comment to Tablo hey you better start recording now. If that’s how it worked, if your tablet or phone crashed, Tablo couldn’t record as it would not know what or when.
Since Tablo is all but the same as local to the programming device with the software interface, syncing isn’t needed or necessary. It’s not a matter of personal preference, it’s simply not needed if the proper information and software ran on TABLO itself. It’s as if they are off-loading part of Tablo’s program to your device instead of running it internally, locally. No need to do that and it would mean a whole lot more flexibility if Tablo had all the code internally, including a WEB server internally. Then ANY device could interface, ANY. and syncing wouldn’t be needed.
I interface with dozens of devices far far far more complex than even a Tablo quad and none of them require that you wait for the device to offload to your computer before you can configure it.
I have even helped write the interfaces that access and configure some devices.
I have even helped write the interfaces that access and configure some devices.
The issue with that though is you are turning the appliance nature of the tablo into a more computeresk type of server. More to maintain, more to go wrong, more hp needed, more ram needed, etc. Its not a terrible solution, but it would probably require some significant updates to the hardware inside of the tablo itself. My understanding is that almost ALL of the horsepower at this point it being utilized by the on the fly encoding going on which makes the content available across many devices. encoding is an expensive operation and really takes some beef to do it on the fly.
That being said though, what may be a more resonable solution is:
- Create a closed API which allows another standalone server to communicate with the internal db.
- Create a standalone Tablo webserver/service (cross platform) All requests from clients would then be off loaded to the webserver and the only connection to the tablo device at all would be from the webserver to make changes (update the tablo internal db with any new changes) and then of course to actually stream the data from the tablo directly to any client making the request…
IDK maybe thats more trouble than its worth, but it certainly adds a lot of flexibility.
Yes, some good points there. The encoding, the decision making when it streams outside of your network to devices on the web, all of that takes some trickery and power.
We’ll let them decide - suggest and they can take or not as they see as reasonable.
@ShadowsPapa – yes you are seeing my point exactly! … thank you … I wanted others to chime in and not just have this a discussion between two people… thanks!
@PIX64 … While you do raise some good points, I would surmise that 99% of the “hardware” needed is already in the tablo … and we know the data is there… and you are at best serving “pages” to maybe 5 devices and not likely all concurrently … You don’t need a complex web server … and there are tons of low scale ones … heck even ones that run from old 8bit computers and python scripts! … so I don’t think the requirement is as high as you think.
I have suggested some things over the past year and hope they will implement some. For example lazy loading content. If the authentication method was changed slightly to use standard login and pass, they could simply lazy load content on the page you are viewing. Even requesting that minimal amount of data everytime would be lightning fast. we are talkin KB here not including the images (thats where the lazy load comes in).
If this was implemented there would be no stale cached DB that needs to be synced, and the responsiveness of the ui I think would be significantly better. Once the stream is requested, then lazy load some additional content in the background…
All that being said though TabloTV has some super smart guys/gals working there, so I am sure they have already thought about that suggestion and have a valid reason for using this type of local db cashing/authentication method.
I would love to see a detailed right up though from an engineer as to why they chose this method and what the benefits are.
@ShadowsPapa -- yes you are seeing my point exactly! .. thank you .. I wanted others to chime in and not just have this a discussion between two people.. thanks!@PIX64 .. While you do raise some good points, I would surmise that 99% of the "hardware" needed is already in the tablo .. and we know the data is there.. and you are at best serving "pages" to maybe 5 devices and not likely all concurrently .. You don't need a complex web server .. and there are tons of low scale ones .. heck even ones that run from old 8bit computers and python scripts! .. so I don't think the requirement is as high as you think.
Fair enough. there are def. solution out there for small footprint and low cost (hardware taxing cost i mean) webservers, but when you start combining functions like that you run into even more use cases where things can go drastically wrong. for example what happens if the webserver running on the recording hardware hangs and stops serving up pages. only recovery is reboot… and then what happens if you are watching 4 streams, and recording 2 shows for example… all of the sudden this small footprint low cost webserver running on the tablo device becomes a major Achilles heel.
The footprint of the data locally on my chrome browser is like 20mb. Not a lot and lends itself to what @ericgus is wanting, but I am sure they have had these same conversations in Canada 
I have suggested some things over the past year and hope they will implement some. ...........All that being said though TabloTV has some super smart guys/gals working there, so I am sure they have already thought about that suggestion and have a valid reason for using this type of local db cashing/authentication method.I would love to see a detailed right up though from an engineer as to why they chose this method and what the benefits are.
Yes, I agree. They must have some really super smart folks who think differently than mainstream and that’s what is so great about 'em.
And that’s my thing - if I receive a logical and/or technical explanation I’m more than just happy but I’ve never had an ability to accept the consumer level “because we said so” ;-) no offense guys.
The footprint of the data locally on my chrome browser is like 20mb. Not a lot and lends itself to what @ericgus is wanting, but I am sure they have had these same conversations in Canada ;)
Which brings up 2 questions:
If that’s all that it is taking, then why does sync take so long? It should be operating like at NAS speeds on a local net with zero hops, is that correct?
and
If that’s all that it is, a local web server - local to the guts of the Tablo itself, would hardly be taxed at all, it would be loafing serving up that little amount of content - most business web pages serve up that much and MORE
MAYBE there’s another reason they don’t want to tell us about for a national security reason…
I have suggested some things over the past year and hope they will implement some. ...........All that being said though TabloTV has some super smart guys/gals working there, so I am sure they have already thought about that suggestion and have a valid reason for using this type of local db cashing/authentication method.I would love to see a detailed right up though from an engineer as to why they chose this method and what the benefits are.Yes, I agree. They must have some really super smart folks who think differently than mainstream and that’s what is so great about 'em.
And that’s my thing - if I receive a logical and/or technical explanation I’m more than just happy but I’ve never had an ability to accept the consumer level “because we said so” ;-) no offense guys.
Yes they do have some pretty bright people there…
I too would love to hear their rationale for it … I would really enjoy reading that myself …
I can’t imagine the volume of data it would have to serve up for guide/content web-ish stuff comes anywhere near the firehose volume that a single video stream spews out.
I can't imagine the volume of data it would have to serve up for guide/content web-ish stuff comes anywhere near the firehose volume that a single video stream spews out.
I love your graphic comparison. Nails it. I think I’ll try to get an idea of the amount of volume that crosses the ether during simple program streaming. Might be fun to see what’s involved for example getting the stream from the Tablo to a computer then to the device sitting in the hole in the side of the TV. Think of it, really - Tablo to device (in my case a notebook) then back out of the notebook again to the TV. That’s some hefty throughput expected of that notebook NIC.
@ericgus @Jestep @ShadowsPaPa @PiX64 @theuser86
There have been quite a few questions here! We thought it best to take this to the developers for an answer a little more in-depth. At least, to give you some insight as far as the how and the why goes. Details below:
1. Syncing is designed to happen in the background whenever possible, and to only transfer changed objects.
2. The "Syncing Screen" is designed to only be displayed when the data on the user's device and the data on the Tablo have diverged sufficiently as to render the app's local data too inconsistent to be reliable.
3. Tablo is designed specifically for video transcoding, not necessarily general computing functions which is why database access on the Tablo can sometimes be slower than we’d like compared to other devices like computers and smartphones that were designed for these types of actions.
4. Browser-based SQL databases, and browser caches aren’t ideally designed for long term data storage. This is why the web app may trigger syncs more frequently than other apps because it relies on the browser's cache for local database storage If the cache gets wiped, so does all the sync’d data.
If we were to send data to all clients using an "on-demand" style request, the Tablo would not be able to handle multiple simultaneous clients, and each client would be subject to reduced performance depending on the activity of other clients.
By performing a sync, we are effectively offloading the majority of database operations to the client's processor. This allows client applications to remain responsive by operating with their own local copy of the database, instead of waiting on the Tablo to access its own database (which could take quite a while depending on the Tablo's current tasks; recording, scheduling, downloading guide, etc).
The best possible user experience is dependent on the syncing mechanism. The problem lies with web clients which require a full re-sync too often. We’ll be taking steps in the future to smooth out this experience.
@TabloSupport thanks for that… Did you catch my request to push sync to recordings before the other stuff? Right now it seems that is the last thing that occurs or at least that is how it seems when it syncs for me.
@TabloSupport thanks for that... Did you catch my request to push sync to recordings before the other stuff? Right now it seems that is the last thing that occurs or at least that is how it seems when it syncs for me.
+1 That’s a very useful idea (at least to me).