Help Shape the Tablo Roadmap

Having used the Tablo for just over a week now, I feel compelled to offer up my suggestions for the road map (some of which have been stated already, but I’m saying them again since they’re important).  When picking priorities, I like to think about what would prevent me from recommending the Tablo to someone – and let’s be honest, I’d certainly have reservations right now since it’s little rough around the edges.  The hardware seems great and the concept is very appealing to the cord cutter, so I think there’s a lot of potential, but the software definitely needs more refinement to get to that appliance-like “it just works” level.

I live in the Google ecosystem for the most part – Nexus 5, Nexus 7, and Chromecast, so I can only speak to the setup I’ve been using.  I also have a Surface Pro 3 and another Windows machine, which I use the web app from.

Here we go…


  • Stability.  That’s #1.  I’ve seen freezing on the Chromecast with 1080p recording enabled.  Sounds like you guys are onto that already.  When I first got my Tablo, it wouldn’t give me the update to the newest firmware or download any guide data.  After a reset, it did prompt me to update and then downloaded guide data correctly.  It’s been fine since, but it didn’t make for a good first impression.

  • Buffering and load times are too long, detracting heavily from the user experience.  The process of getting live TV on the screen and changing channels just has to be faster.  Some of the syncing and initialization can undoubtedly be either sped up or performed in background.

    Probably more critical is the buffering when switching to a channel.  I’ve used the network-connected HDHomeRun with Windows Media Center in the past and changing channels on that takes a couple seconds.  It’s not exactly apples to apples, but this needs to be a whole lot faster, even if it risks introducing minor skips on sub-par networks.

  • When watching live TV, progress should be shown relative to the length of the program you’re watching (or otherwise based around time slots).  It’s very difficult to navigate forward and backward when the bar is constantly moving on you – and it just looks weird.

  • Follow Google Cast guidelines (for Chromecast).  The icon isn’t positioned correctly, which is confusing, and some aspects of the experience are off.  Via the web app, switching channels shouldn’t require you to hit the cast button again (after waiting for it to buffer) – it’s very tedious (and not the way other apps work).

  • Phone apps.  Adapting the tablet apps to work on phones shouldn’t be very difficult (certainly not on Android) and would be a huge again in overall experience.  If I grab my tablet, I can go to the app.  If I grab my phone – oh wait – there’s no app, let me go to the web page.  And then there’s no ongoing notification for a Chromecast session like there is with the app.  It just makes things a little disjointed.

  • Add vertical mode in Android app.  People usually hold their Nexus 7 vertically, so it’s weird to open it and be forced horizontal.  Forcing horizontal is fine during video playback (I think Netflix does that), but it should work in any direction during general navigation.

  • Improve general UX.  There’s a lot of polishing that needs to be done.

    On the web app, the way the arrows work when using the guide and switching between live TV channels is not intuitive.  The channel numbers/times scroll semi-independently from the programming.  Really, t
    he visual appearance of the grid and text could use some improvement.  The text also adjusts laggedly when getting clipped, which looks funny.

    You have to click on the channel number itself to start watching – there’s no option from within the program block other than record, which is confusing and left even this tech geek scratching his head at first trying to figure out how to watch live TV.  To a non-techie, it’s also not clear what the red flashing channel numbers mean when you never explicitly started recording anything.

    And don’t show “Establishing Web Socket Connection” and any techno-babble during startup.  Just tell the user it’s connecting to the Tablo (with indeterminate progress).  Don’t segregate into steps.

    It’s all about the little things.

  • Fix jarring experience when web app connection is lost.  If I have the web app up and my computer or phone goes to sleep, if I take it out of sleep, it will pop me out of the guide or whatever I was doing – I’m guessing only when the web socket is disconnected – to show that it’s re-establishing the connection.  Ideally, this should happen in background without changing the page.  And more importantly, it shouldn’t kill the Chromecast session if in use.  Had that happen several times and it’s really frustrating.

  • Record end padding time.  This is very important to sports fans.  Needs to prompt on sporting event to add time, but by default 30 mins extra.

  • Support AC3.  This one’s very important to me, though honestly, I doubt it’s something that matters to the majority of people.

  • Support multiple web browsers.  Windows phone and tablet users are SOL without IE support.  Plenty of people I’m sure are forced to use Chrome when they don’t for anything else, though I’m not one of them.  I imagine the effort required to do this isn’t that high versus the return though.  I’d still rank stability and UX improvements above this.
As a software developer, I know how hard it is to get all this stuff working right on multiple platforms/configurations – especially with limited resources and all.  I think you’ve got a great start and I’m excited to see how much better Tablo gets going forward.

It may just be my personal preference, but I would like a PDF User Guide to download instead of (or in addition to) viewing chapters online.

@blaster5K - Thanks for your thorough feedback. We’re working on many of your recommendations already but your comments will be shared with the dev team. 



@Grandy - Good to know! We’ll add this to our to-do list. 

Just finished reading ten pages of roadmap discussion, good stuff!


This thread started as gathering suggestions for an April team meeting but has morphed into the single “feature requests go here” thread.  I expect I’ll have more to add in the coming weeks, would you prefer that we keep building this thread for feature requests or that we start new topics in the “feature request” category of the forum?

@pnear - This thread gets turned into a massive/evolving document from which the dev team develops the road map. 


It’s fine to continue this thread or if you feel your request is big or might start a bigger back and forth discussion, then by all means start a new thread.

This is your forum, we just live/work here. :) 

Looking at recordings that my Tablo has I see the season across the top and the episodes that are recorded as well. What I also see is the number of the show. For example, The 100. My wife and I missed the first few shows and I have set up to record all shows in order to obtain the missing ones. Once we have show #1 and one we will start to watch the show. However when I look at the recordings on my Roku I do not see the episode, just the date. Maybe I am missing where to look but I would love to see the episode number listed.

Out of curiosity, why do we have to choose between 720P and 1080P for recordings?  Why isn’t there a “native” setting that records 1080i as 1080P deinterlaced and everything else as 720P?  I prefer not to lose the resolution on 1080 stations, but then it wastes space saving all the 480i/720P content as 1080P.

@Belgiangenius - We don’t upconvert so broadcasts that were natively 720 will still be 720 if your setting is 1080.

@TabloTv, but the broadcasts that are natively 720P will take up more space on the hard drive if recorded at 1080P, won't they?

If they don't, then that is a great feature.

@snowcat isn’t that what @TabloTV is saying?


Record at 720p = 720p stored as-is, 1080i downconverted to 720p
Record at  1080p = 720p stored as-is, 1080i de-interlaced to 1080p

That’s my interpretation, anyway.

That’s what I think they are saying, but I want them to clarify.   But that may explain why my hard drive isn’t as filled up as I thought it would be by now recording in 1080p.

Yes Snowcat - 


Recording Quality set at 720p = 720p broadcast stored as 720p, 1080i broadcast downconverted to 720p.
Recording Quality set at 1080p = 720p broadcast stored as 720p, 1080i broadcast de-interlaced to 1080p.

Thanks!  I would definitely put that in the documentation.  Chapter 5 of the user manual discusses these settings, and there is no mention that 720p recordings are going to be the same whether recorded at 720p or 1080p.


I also assume that SD channels will only be recorded at 480p and use just 0.8 GB/hr of hard drive space at either quality setting.


You’re right. We’ll add this! 

My suggestions:

User Experience:
- Standardize on a feature set and get it stable on all devices.
- Same thing when adding new features. Support all devices at release. Don’t pull a Pebble and get it working on one platform and then six months later on another.

Nothing turns a potential customer off faster than seeing that their preferred platform is playing second fiddle to some other platform.

Hardware:
- Gig Ethernet. I’m surprised this wasn’t already in the box.
- 802.11ac. Better yet, let us disable the internal wireless and use one of the USB ports with an aftermarket WiFi device.
- USB 3. The faster you get data to the disk the better.
- Low profile power adapter. Everyone hates wall warts but accept them as a necessary evil. Ship one that only takes up one socket space on the power strip.

I don't remember this one being mentioned but if the Tablo resets or if there is a power outage while recording a show, have it to start recording again once back up and running.  My wife had a show stop recording while in the middle a couple weeks ago and it didn't restart.

There is no need to overkill the hardware.


Gigabyte Ethernet - it can only use 10 Mbps for any one device, and you can only stream to 6.  That is still plenty for 100 Mbps Ethernet.

802.11ac - sure it would be nice, but it is a luxury feature right now for a device that is trying to keep costs reasonable.

USB3 - Completely unnecessary for the transfer speeds needed for the Tablo.

USB3 - Completely unnecessary for the transfer speeds needed for the Tablo.



Have a look at the USB 3 spec. It’s more than a speed improvement. It’s improved power management capabilities would likely mean some issues with drives would not exist on a USB 3 capable Tablo.



As for 802.11ac, there is at least anecdotal evidence that Tablo performs better wired.



WRT gigabit ethernet, if the device had USB 3, a fast drive and gigabit ethernet, perhaps it could support more than six streams.



In the past, Tablo has mentioned improved specs would have to be in a premium model. I don’t know if the market would support that, but I would (as long as it also supported AC3).

If we’re talking improving hardware, could anything to be done to decrease the time it takes before streaming occurs?   Is the lag time entirely a function of re-encoding the stream and if so would a fast CPU be the solution?    Great feedback and suggestion in this thread but the lag time from pushing the button is the biggest complain in this house.  

Another comment about the web app taking up that extra space at the top of the screen. When you watch a race that also includes space at the top of the screen you sure lose a lot of viewing area. Can you please get rid of that area unless I mouse over or touch the screen on browsers?