A Message from the CEO of Nuvyyo

Thank you for the response. I have been having those issues, and I’m glad the company is acknowledging them. What went from a pleasure to use has become a struggle, and it’s been frustrating. Thanks for your attention to this–I really want to see the product and the company succeed.

A quick update on my earlier post… We have identified a few issues that we believe explain the majority of symptoms that some customers are experiencing. The root cause seems to be a change in 2.2.2 that moved the sync operation to the background for most apps.

An error in the code caused user databases to grow over time for apps that infrequently connected to the Tablo. The increased database size created several side effects that slowed operation of the Tablo. This error was not uncovered in testing as it took several months to grow the database to a size where symptoms were noticeable. Our test processes have been changed to ensure this does not happen again.

We have also identified a race condition that we believe explains the apparent infrequent loss of recordings.

We have also found a way to significantly speed up the retrieval of recordings on the Roku.

These fixes will be included a beta release we will begin testing today. Please note that a component of the fix is run during the nightly maintenance window and therefore you may not notice full performance improvements until the day following your upgrade.

We also investigated the playback issues reported on the new Roku 4. They included delays in starting playback, delay in resuming playback after FF/REW and pauses with the “Loading” message during playback. The investigation has so far revealed an issue that is causing packet loss which reduces the speed that the video is received by the Roku 4. If the speed drops below the rate of the video stream, then delays and buffering will occur.

On the Roku 4, we traced this to a specific sequence of events. If the Roku is connected to the network with WiFi and is then switched to a wired Ethernet connection without a subsequent power cycle, the Ethernet interface appears to be initialized in a bad state which causes the packet loss. The solution is to power cycle the Roku 4 once it has been connected and set up to run using the wired Ethernet connection. This corrected the problem with the Roku 4 we have available for testing but we would like other users with this hardware to attempt this fix and report back on their results.

We have been unable to reproduce this same ‘bad state’ and packet loss on earlier Roku platforms like Roku 3 and 2. We will continue to work to identify other potential sources of ‘loading please wait’ problems unrelated to poor home network performance.

6 Likes

Good to see some bugs identified and fixed.

The Roku 4 scenario seems like it would never happen. How many people would ever connect the Roku 4 wirelessly and then plug an Ethernet cable in without it being rebooted? I could see people moving it around the house, but that would require unplugging it. I just hope it helps lead to solving other Roku issues.

Keep up the good work!

2 Likes

I wouldn’t ordinarily switch to wireless and then back to wired on my ROKU4, but I read in these forums that the LPW went away using wireless… so I did the switch and back again !.. will reboot the ROKU4

Chas

Posted this a few hours ago in a different thread. Does it in any way sound familiar?

“The database maintaining the recordings list is on the Tablo itself.”

Which I believe will show to be hitch in the giddyup when this all gets sorted out. Since the database is spread out on both the Tablo itself and the HD, I can see timing issues that must be dealt with in real time. Calls made through the drive interface must co-exist with data-streaming, which must have almost unbridled access into and out of the network and perhaps to some degree the internet. Latency issues have to disrupt the clean flow of this data which will force throttling of the data stream being processed for content when they are sever enough. If this happens with greater frequency then has been allowed for in tablo’s code, dropped or misplaced data will result. Tablo will use whatever algorithms assigned to handle this, but is it even possible to do this effectively with so many variables to deal with in real time? If all the tablo has to do is deal with issues within the tablo device itself, it’s tuners and the incoming OTA signals, and user interface, it think it should be quite manageable. But when it has to interface with with outside devices, the network and even the internet, then so much is dependent on conflict clean communications and minimal timing issues, it is hard to imagine how it is able to juggle all of it well enough to not make mistakes. If those mistakes are only dealing with real time playback, that’s one thing, but if they effect the database content in anyway, there has to be lasting repercussions, ones that are not being dealt with effectively. It’s the build-up of these repercussions over time that is killing tablo’s ability to perform properly in so many diverse areas. A corrupted database is the worse thing that can happen always, as anything can go wrong, and usually will.

-Rodger

Which may be why I haven’t seen any problems in three months. There is no contention between recording and viewing on my Tablo since I don’t use it ever for viewing shows. I also offload everything that’s been recorded from the Tablo every 24 hours. So there is no buildup of data since every file is transient. My Tablo is dedicated so to speak to simply recording so its resource usage is minimal. Its queuing and multitasking functions are cut in half in my system. In fact whenever I look at the drive attached to it, I seldom see the LED flashing to signal activity.

Hmmm…sign me up as a stress tester….

The LPW started with the FW before 2.2.2 and went on in 2.2.2 for me.

I returned it before 2.2.6 but I bet it would still happen today if I still had a Roku.

@jayeffgee - Yes, and I don’t believe you were alone. Some of the LPW instances were related to the addition of 60 FPS recordings on the 1080 recording quality but I believe some users also experienced this when they reduced recording quality to one of the 720 options.

Thanks for the update and good work - most of us appreciate how difficult this must be over the number clients you support. This will make a lot of people happier. Cheers

@snowcat I’m not sure how the Roku 4 works, but I can envision this scenario because Roku does not automatically change the Network connectivity when the Ethernet port is used. I’ve moved my Roku to a location where I needed to use WiFi. When returning to my “wired” location, the Roku stayed on WiFi until I went to settings and reset to Ethernet. I imagine this must be the scenario that would require an additional reboot. The AppleTV automatically recognizes this change, but I’ve found that my Roku does not.

TabloCEO said they could not reproduce the ‘bad state’ and packet loss in Roku 3 & 2. Does it mean that you guys haven’t seen LPW on the Roku 3 (2015) in your lab, even with 60FPS?

@kamy2015 - We have not but we’re trying…

What you describe for the Roku4 sounds much like whats going on with my Roku3 (as others have stated) for what its worth i am using an all hardwired network (utilizing Powerline adaptors).

Great news guys!

I think I saw an instruction on how to get beta firmware, but I can’t remember what thread it is in. Can anyone point me at it?

I believe they have to push it to you… I put a request in within the past few hours to get the beta load, and an “Update Tablo Device” button just showed up on my settings page.

Debating whether to do it, as I just did a factory reset, and I seem to be able to record normally now, tho the first attempt after the reset didn’t show up in the Recordings page. But after setting up a quick schedule to capture 7 programs, they all seemed to record normally. I’m hoping my other problem goes away as well… I’d find Tablo locked up in the morning, and it hadn’t downloaded the guide data. I’d have to do a reset, followed by manually initiating download of the guide.

Going to be monitoring closely to see if everything is working now, and if it is, may hold off on the beta. First sign of trouble and I’ll install it.

I was on the beta list last time but I haven’t received any update notice this time. Do I need to request the beta specifically each time?

This time, yes.
Follow instructions from here:
https://community.tablotv.com/t/please-reconfirm-your-interest-in-beta-testing/4513

Thanks, but it says “You don’t have access to that topic”. Can some one please help?

Same problem - “You don’t have access to that topic”.

TabloTV11h
In order to make sure we have users who are committed to being an ongoing member of the beta testing team, we are re-evaluating our current beta testing lists.

If you would like to continue to receive beta firmware loads please follow the following steps:
Use the support ticketing system (http://bit.ly/1w8BrBw) to send a note to Tablo Support with the subject line “FIRMWARE BETA”
Make sure to include your MAC address in the place provided by the form
Also include your forum username within the ticket (so we can make sure you maintain access to the beta area of the forum)
We will add you to our next firmware beta as soon as we receive your confirmation.

Thanks everyone who has participated thus far. We appreciate your assistance!