Delving deeper into the Roku "Loading..Please Wait" issue

xxxx cccc xx cc

At risk of stating the obvious but yet unvoiced question:

Why are things which worked properly now broken? The Roku has not suddenly tightened its h.264 playback requirements causing “Loading please wait” nor did received signal quality needed to make uninterrupted playback suddenly require changing antenna signal attenuation.

An obvious answer is programming mistakes introduced in the Tablo 2.2.6. firmware.

Things which worked fine before the update should NOT send users off to re-examine their antennas, routers, etc.

The programmers should be asked to carefully look at what was changed, and why, and how… And their changes should be critically reviewed by OTHER people whose fresh eyes and ego-less reviews find and eliminate bugs.

Far too many wasted hours of user grief, endless typing, and amateur speculations created by new firmware bugs which are the root cause of these problems.

If 5% of the firmware is new code, this is where the corrective action needs to be focused and applied.

All the other effort to explain why previously working code no longer works is, IMHO, a big waste of time.

The loading issue and the inability to connect remotely issue suddenly appeared in 2.2.6., and the Fast Forward reboot started in April right when Tablo
and Roku coincidentally updated their respective firmware. How about either providing a method to downgrade / revert or, better yet, assign people to really concentrate exclusively on fixing these bugs?

As much as I appreciate the value of users trying to find workarounds, I am really hoping that root causes will be revealed by looking at the obvious - what has CHANGED WITHIN THE UPDATE which previously worked properly.

2 Likes

xxxx cccc xx cc

Roku released an update last night - b8792

I watched a little bit of TV this morning and didn’t get any LPW messages. I can’t say it’s fixed for sure as I hadn’t been experiencing the issue as much as others, but it seemed better.

Fixed DD+ issues
Improved remote headphone audio quality and fewer drop outs on 2. GHz
Improved 2.4GHz WiFi Bandwidth
Additional bug fixes

http://forums.roku.com/viewtopic.php?f=28&t=90355

Thanks for the heads up and please keep us posted if you ever see the LPW message again. BTW, was your recording quality set to 1080p 10M?

Received b8792 and had LPW on the second or third show I watched, and then again on the next show. One instance per show, but still too many. This issue simply didn’t exist until the Tablo Firmware re-write from 2.2.2 forward. 1080p 10M setting, Roku 4 and Tablo hardwired directly to GigE router’s built-in switch.

I’m at 1080p/8. I can change it to 1080/10 and see what happens.

FYI All, I just experienced several “Loading…Please Wait” events while watching the Watch ESPN Network app on my Roku 4. So it is possible to see this message separate from the Tablo app.

It seemed to me the streaming quality had dropped down during those episodes. (My wife was uploading some pictures using her cell phone and consuming some of my limited DSL bandwidth).

This observation tells me the Tablo app cannot be the only component that can cause a Roku to display the LPW message, and perhaps should not be overly condemned when they are randomly observed in random Tablo recordings.

It is possible had I been watching the same program using the Watch ESPN app on my Amazon Fire stick I might not have seen that message, but I was not running an “A:B” comparison at the time.

So, can any else verify ever seeing an LPW message from their Roku on any app other than the Tablo app?

For what it’s worth …

Funny you should ask…I saw this several times yesterday on the Roku 4 Showtime app when watching episodes of “Episodes”…
The one thing different that stands out in my mind, is that the Showtime app is truly streaming from the interwebs - and is subject to the vagaries of best effort QoS…whereas Tablo is streaming locally on a robust and overbuilt (for this purpose) local network.
P.S. - I’m also in the Raleigh-Durham area and attended State…

I just learned of the roku secret wifi settings.
I disabled network ping and set wifi power to high. These changes have solved my video loading and FF problem. I was waiting 30+ seconds. It now takes <10 seconds to get to any random part of the stream. Not sure of the benefit of enabled network pings.

I too have seen the LPW message on other apps, specifically on Livestream.

However, I NEVER SAW THEM in the 11 months of using Tablo, but SUDDENLY BEGAN SEEING THEM with the 2.2.6. Update to Tablo.

The logic of dismissing Tablo prograaming errors / mistakes because something occurs on some other Roku app totally escapes me, and makes no engineering sense.

Much like fast forward Roku reboots, the fact that they occur (heavily) on Tablo and (supposedly) on other Roku channels can easily be explained by 2 programmers making the same mistake in each of their channel apps. It most certainly does NOT implicate Roku.

If anything, the fact that over 2500 Roku channels exist and so very few other channels rarely demonstrate the LPW / FFReboot problem makes a very compelling argument that Roku is NOT at fault.

Roku IS at fault. The fact that it is happening on other channels as well is evidence enough for most folks I believe.

The entirely obvious correlation of 2.2.6. Tablo firmware release occuring at the very same time as the LPW bug arriving should make it very clear that there is a new programming mistake now in the Tablo programming that did not exist before. The Roku did not change when 2.2.6. was released, yet my Tablo playback performance changed profoundly.

I know we have had this very same discussion together before when the FFReboot bug suddenly arrived, essentially ruining my home TV playback. At that time you made the technically erroneous observation that the Roku was a “closed system” whose sandbox design would not and could not permit channel apps to make the Roku freeze. You ultimately backed away from this totally specious and incorrect claim, instead saying if only Roku HAD BUILT their box to be fault tolerant in that manner, then the problem could not have happened, and thus Roku was at fault for building a box which allows channel apps to crash it. To you, this proved that Tablo could not be responsible for the problem.

The Roku is not a “closed system” to use your term, and as nice as it would be if platforms like Roku could prevent channel app bugs from showing up, this is not how the real world works. Apple iPhones, with their very restrictive and controlled APIs, as well as their heavily curated and supervised process of screening each app before allowing it to be released, still has plenty of bugs remaining and plenty of updates and fixes needed for their apps. Their sandbox is way more secure than Roku given the very confidential data which a smartphone contains, and their engineering in software is totally state of the art and mature, yet their platform is, like Roku, very susceptible to app bugs made by developers. Your fictional closed Roku being the culprit again makes no sense, and the coincidence of 2.2.6. release along with LPW arriving is undeniable and as plain as can be without needing to figure out whose firmware changed as was the case with FFReboots. I would further offer the observation that the latest Tablo 2.2.6. release has made a noticerable improvement in the frequency of FFReboots for me, and this too correlates that bug with Tablo code changes rather than incriminate the Roku.

The latest LPW bug is most certainly provoked by Tablo’s new code, and I do not believe that “most folks” would agree that this is Roku’s fault.

Well, the roku took an update tonight (at the least the Halloween screen changed) and the tablo took an update with guide data. I had relief for 2 hours last night. Back to same lag on load and FF.

One of the things I’ve learned in life is not to rely on one thing. In designing a reliable antenna system (or farm) for myself, I came to see that in my difficult reception situation, reliance on one antenna gave me problems. Given the variability of RF signal propagation, creating a stack of antennas gave me reliability and backup.

I took the same approach early in the life of DVRs ten years ago. I had a backup for my Tivo. It was a PC with a tuner card. Shows my wife and I absolutely needed to record were scheduled on both the Tivo and the PC at different times. If both failed, we resorted to Bit Torrent to retrieve a show.

I regard my Tablo the same way. I bought one because it is an easier device to program for my wife than a PC based tuner. However there are some shows such as Downton Abbey that we absolutely need to record. Using multiple devices at different times ensures there can’t be a total failure. And now that PBS carries Downton on its website for Internet streaming gives us a second backup.

Reliance on one sole device leads to the anger and frustration of unrequited love when that device fails…

That isn’t even true. I SAID Roku built a device with a sandbox for developers to work in. IF, working in that sandbox caused the device to reboot, then Roku needed to fix the sandbox. That is what I said then, and it is what I say now.

To be honest I haven’t even read the rest of your post. It pretty much starts right off with this falsehood, which is about what I would expect, so I will just stand by everything I have said.

The LPW occurred for me all through the 2.2.6 beta with no correlation to Roku updates. I’m even getting it now in the 5Mbps setting. Tablo support says the logs indicate network issues. Odd so many people had their network go bad at the same time as a firmware update. :smile:

Maybe we’re on the same network. lol

If it were network issues, shouldn’t there be problems on every client? My Chrome browser plays back flawlessly (including Fox Football which is a true 60fps broadcast - with Tablo set to 1080 10Mbps 60fps), and FireTV seems immune to theses issues as well.

Not if the client’s network hardware/software is the problem.