NEW Firmware Release - 2.1.18

As I posted in another thread … I think above all else getting the right antenna size (yes there is such thing as too big) (and you can over amplify as well) and the location/orientation of the properly sized antenna is perhaps the most vital thing in getting the best performance out of your tablo … more so (if like me) you live a good distance away from the broadcast towers… even in “good” reception areas if you do not have your antenna mounted correctly or located in a place thats subject to external interference  (i.e. reflection of moving objects/people/etc, or you are too close to another stations transmitter) … you can significantly degrade your reception and suffer problems… DTV unlike analog is “either it works or it doesnt” … there is no “snowy picture” … you either get a great picture or it just out dies or you suffer blocking and other problems.

@BraveUpNorth Thanks for the feedback! 

@7up The difference here is that other DVR’s (Tivo/Cable/Satellite) don’t transcode the Mpeg2 to H.264 – so they can’t run into the same issue. They record in native and play back in native Mpeg2.   

We use H.264 to stream to mobile and internet devices like Roku, Apple TV & Chromecast that do not support Mpeg2. The same can be said for Windows MCE devices; they record and play back in Mpeg 2, but can't mobile or 'internet' devices. Basically, if we want to send it to your other devices, and not your TV, it has to be transcoded.

I’m not trying to debate with you but some of your statements are incorrect.   Satellite doesn’t record or playback in mpeg2 as the feeds have already been transcoded to h.264 or some variant before uplinking.    You somewhat acknowledged this with your comments about 2-pass encoding above.  I haven’t looked at local cable TV recordings in a long time so I don’t know how they are currently encoding their feeds.    Your statement that transcoding is necessary for wireless clients, ie tablets, phones, Roku, and even FireTV, is correct which emphasizes the need for sufficient video processing.   


As we agree its necessary for Tablo has to transcode to h.264, I would respectfully suggest the processor chosen for the task is insufficient which is the cause for the long lag times, an image with artifacts during motion and why you still recommend 720p.  

Its just a thought but why not release Tablo as software for the PC/Mac which have significantly greater processing power for transcoding or work with SiliconDust using their existing h.264 tuner.     I’m not suggesting discontinuing developing and selling hardware but you would expand your potential customer pool.

@TabloSupport. First off thanks for the phenomenal write up, as that provides a lot of info related to the inner workings of the Tablo. I have been with your company since the start ( pre-sale ) of the 4 tuner. We couldn’t be happier with the product and my wife factor has said she doesn’t even miss cable! To achieve the best setup for our whole home DVR I tested wifi at first with Tablo and Rokus and did not like the latency that brought to our viewing experience. So I hard wired everything to provide as near of a experience we have been used to. Tablo is hard wired via Powerline adapter sustaining 250Mbps or more. Roku 3 connects to TV is hard wired directly to gigabit Cisco router. Living room Roku 3 is hard wired with Powerline adapter also sustaining 250Mbps or more. We have never had an issue with buffering with this setup on Live TV and recorded episodes. After the beta 2.1.1.17 and also public release 2.1.1.18 we have experienced buffering on only Live TV. This can happen right away, or after watching LiveTV after three hours straight. I should have reported it right away after I noticed it in the Beta release, but got busy and I apologize as that is what us beta testers are for. I thought if it was my network, I would experience buffering while streaming from my plex server or from the Internet or even from the recorded Tablo episodes. Hopefully the next release comes out soon so I can test reverting back to the old way how Live TV is handled and report back if buffering is gone. Thanks again for an awesome product!!! I hope Tablo does not take our user experience reports via the forum negatively as we all want Tablo to stay for a long time, just get better over time as with all technology!

Ok after playing around with just live tv and the roku+tablo I can confirm I too got the buffering a few times … even well after a program was in progress… that said… following supports suggestion, pausing the playback for a couple mins totally removed the buffering completely (I used 2 mins as I stepped away to get a cup of coffee) … I suspect pausing it only a minute would probably be sufficent to remove the buffering issue.

@TabloSupport Don’t want to open another can of uncontrollable variables, but is there a preferred router(s)? Thanks, in the market for a new one and figure I’ll get what works best for the Tablo > Chromecast.


I am becoming concerned the the hardware design of the Tablo is underpowered for the task of encoding in real time if the silicon or algorithm in Tablo has difficulty processing/de-interlace 1080i video content -> 1080p without artifacts during motion, particularly during sports.    This is not an issue with nearly any other DVR including Tivo/cable/satellite which do not have 12-15 seconds of lag time for streaming to clients.   Even Windows MCE which re-encoded everything didn’t have issues with such a long lag time or issues with 1080i video content.     Perhaps Tablo version 2  can have better hardware.   

The hardware is more then capable even though the SOC their using is four years old.  The quad unit uses the Vixs 5190 SOC which has hardware based transcoding.  I would assume the functions for transcoding have configurable options.   This may be something that needs to tweaked.  Artifacts during transcoding are normally caused by frame rate reduction and/or  compression.

@TabloTV and @TabloSupport - Good update! Important resume feature (hasn't happened to me yet, but glad you thought of it, and a bit speedier, for sure!

iOS downloadable web app has worked seamlessly. I am now all systems go!

@thebellenir - Glad to hear it!  :-bd

I am becoming concerned the the hardware design of the Tablo is underpowered for the task of encoding in real time if the silicon or algorithm in Tablo has difficulty processing/de-interlace 1080i video content -> 1080p without artifacts during motion, particularly during sports.    This is not an issue with nearly any other DVR including Tivo/cable/satellite which do not have 12-15 seconds of lag time for streaming to clients.   Even Windows MCE which re-encoded everything didn't have issues with such a long lag time or issues with 1080i video content.     Perhaps Tablo version 2  can have better hardware.   

The hardware is more then capable even though the SOC their using is four years old.  The quad unit uses the Vixs 5190 SOC which has hardware based transcoding.  I would assume the functions for transcoding have configurable options.   This may be something that needs to tweaked.  Artifacts during transcoding are normally caused by frame rate reduction and/or  compression.

I’m familiar with Vixs as a company but not specifically their product line.  Most silicon designs undergo significant improvements over the 4 years since this chip was introduced.   If the hardware is more than capable may I ask why,

 
-  there is a ~15 second lag time, the overwhelming majority of which is transcoding?
-  Tablo has difficulty processing 1080i video content with motion -> 1080p without artifacts (macroblocking)?
-  How much control over the level of compression is possible with the hardware based encoding of the 5190?  

It would nice if Tablo allowed some user configurable transcoding profiles similar to what is/was possible with SD HDTC-2US.   I would be curious to hear how the Tablo’s trancoding compares to HDTC-US “heavy profile” in terms of lag time and picture quality.

I’m familiar with Vixs as a company but not specifically their product line.  Most silicon designs undergo significant improvements over the 4 years since this chip was introduced.   If the hardware is more than capable may I ask why,

 
-  there is a ~15 second lag time, the overwhelming majority of which is transcoding?
-  Tablo has difficulty processing 1080i video content with motion -> 1080p without artifacts (macroblocking).   How much control over the level of compression is possible with the hardware based encoding of the 5190?   

As what was previously stated its not just the transcoding that is
leading to the delay.   There are many other operations that occur
before, during and after transcoding.   You also have to remember that
the de-interlacing and transcoding is happening real-time.  Its far easier to convert 1080i to 720p algorithmically.  I personally would like to the option of having 1080i streams converted 720p.

All hardware based algorithms provide some level of parameter tweaking.  As to which parameters are available on the Vixs I have no clue.   But I do know Vixs chips are used in everything from Samsung TV’s to Tivo.   They dominate the PVR market and have quite a few patents around Marcoblocking. 

Thanks superhac.   Wish I had your coding skills.

The other thing too is even hardware transcoding still needs to “load the pipeline” (even if its a few frames of video) to have something to analyze the differences between in order to figure out the compression for a given frame since these “mpeg” type video compression systems require at least a few frames to know how to process the stream. So there is some inherent lag with that as well.

I’ve had both the macro blocking and buffering issues.  And then tonight two new issues - I tried to connect through Chrome to update some recordings (I stream using a Roku 3) and all I got was the “Connecting” message and a continual countdown cycle from 5 to 1.  I waited perhaps 15 minutes and still nothing.  I rebooted the unit and it connect immediately - but now I have  no live tv data.  I tried updating the guide but that didn’t do it.

Quite honestly I have wasted more time “fiddling” with this unit and the various hard drives than I have spent using it to watch TV.

i think a lot of chrome users have had issues… I don’t have a chromecast so I cant really say either way.

@TabloSupport I have 50mbps IS and have the Tablo wired direct from the modem and your telling me I have improve my IS to make the buffering go away??? Sounds like Apple telling the customer “Your doing it wrong”.


That is ridiculous. I think you need to do more than consider offering a way to change it back in the next update. I think you need to do it tomorrow.

Thanks to Tablo Support for drafting up that extensive response. I really do appreciate it. A couple of thoughts from me…


1. While manually pausing for a few seconds will clear any buffering issues…that simply cannot be considered a true solution. It simply pains me to make the comparison…but that is exactly how I had to use the simple.tv v1 when I had it. I hated it. I had to manually pause the stream for a few seconds to ensure the stream remained stable. I wasn’t “watching TV” at that point…I was “running TV”. This is an appliance that should be transparent…and it was up until the recent update. Please don’t let this become simple.tv all over again.

2. I’ve been watching Tablo on one of my Roku3’s as I type this and within the first couple of minutes after initial tuning, I had 3 buffering instances and a macro-blocking immediately following the third buffering. It’s been stable for a few minutes since then. This would seem to indicate that it is connected to the change in segment length. This is my Ethernet connected roku. It’s simply Tablo->Gigabit Switch->Roku. For trouble-shooting purposes, I temporarily modified my network to swap out the switch with the ethernet ports on my R7000 AC router…the issue remained. I see literally no way in which I could “improve my network”. 

It seems clear to me that this update had some unintended effects, primarily I suspect to do the changes in the segment sizes. Please make addressing these issues as quickly as possible the highest priority.

Unless there is some magical suprise from Tablo Dev Team  I don’t see them significantly reducing the 12-15 second lag for tuning to a live channel.  This current update resulted in many users experiencing issues with buffering on Live TV which did not exist previously and that includes Roku3s with hardwire connnection.    Using the Tablo as a DVR and viewing recorded programs it works well but for Live TV or any desire for channel changing, bypassing the Tablo  using the TV tuner is a much better option.    


Given the above, does it really make a lot of sense to develop a full blown EPG for Roku, Fire TV etc when you can’t effectively channel surf?   Don’t get me wrong, I would like an EPG and can’t imagine a DVR not having one but perhaps that thinking is old school?   There are so many basic DVR features which we are missing that really need to be addressed and scheduling recordings, managing recordings and Tablo settings really don’t require an EPG.

Having pushed back video while viewing and EPG as a grid doesn’t seem like an unreasonable feature 7up.  So at least you can continue to view the channel while you search for something else.  Oh, and if we’re paying $4.99 a month for EPG data then of course I’m going to want a usable EPG that doesn’t look like it’s got a UI from the 1990’s that can show more than what’s currently on.


Reducing fragment sizes for the first couple of m3u8 calls could significantly reduce the 12-15 second delay. The Tablo could then revert to longer fragments for better optimized GOPs if needed.  Having an initial m3u8 with a total of 6 seconds worth of content takes less than 6 seconds to transcode, from my own experiences the Roku only needs a marginal amount of time to fire up a local network sourced HLS stream… so I think there’s room for improvement there.  Just getting metadata off of the Tablo for the list of live channels or recordings is really slow given that everything (at least on my setup) is on a local wired gig-e network.

Just so there is no misunderstanding, as I stated above I’m not opposed to an EPG.   I only considered its practical utility given the long delay in changing channels with live TV.   By using the TV tuner for live TV and Tablo app for recorded content, playback of Tablo recordings is no different than playing back content from Netflix, Amazon or any other app on Roku which was the basis of my comments.   Scheduling of recordings is pretty simple with a smart phone, tablet or computer where an EPG does exist.  If the lag time can be reduced, it would absolutely be my preference to have and use an EPG I’m just not overly optimistic the lag time can be reduced based upon comments and progress to date.

I still think a channel guide for ROKU would be very useful.  there have been times when I want to see whats coming up (say if its 10 mins to the hour) …