Still, the underlying issue is whether your switch will create out of sequence packets and whether Tablo broke something that would have a problem with that.
Who knows about the former question. I’ve done hardware design work on ethernet switches and I know that it would be pretty unlikely that the switches I designed would have much potential to generate out of sequence packets, but we were designing switches for the telcom world that were designed to be low latency. I have no idea what the average consumer grade or entry level enterprise switch would do. Certainly most routers can generate out of sequence traffic under the right conditions.
Basically I was just going over in my mind the symptoms that people are reporting, and I have seen applications that had issues with oos packets fixed (usually temporarily) by rebooting a router. Just thought I’d throw that out there. If some of you are using routers with QoS capabilities and are having LPW problems that go away with a reboot only to return later you might try going into your QoS settings and turning on QoS management and setting the priority of video packets like first or second (I personally would set then priority for video to second). Just something to try and if it gave positive results it might give someone a clue to the root cause.
Add me to the list of users who have experienced a Roku 4 reboot after a fast forward event in a Tablo recording.
And I just installed a new Netgear D6200 DSL modem/router in hopes of mitigating Roku/Tablo errors.
Tablo and Roku hard-wired. Recording quality 1080 8mb.
Switched to Amazon Fire TV stick to finish watching my program. No errors using the Fire Stick, but could not enable closed captions. Will bring that up on a separate post.
FWIW, rebooting the router has not temporarily or otherwise reduced my Roku reboot frequency nor has substitution of 2 other router brands. I have not considered QoS / arrival order as a potential root cause but I can see the possibility of cause and effect you envision. Along somewhat similar thinking when analyzing the FFReboot problem and out of sequence packets, I have imagined a race problem with probabalistic occurence explaining the “heisenbug”, arising from some stochastic Tablo box latency, perhaps due to disk I/O, event queueing delays, or other occasional latency. The resulting outcome could create oos packets.
Imagine the typical FIFO broadcast stream sent from a typical streaming Roku channel source versus an interrupted content stream from Tablo due to user selection of remote control FF,FF,FF, then Play button sequence. Add the internal Tablo stochastic latencies to these Tablo-generated payload packets.
Then add the play trigger going from Roku to Tablo signalling user button depression to resume playback, this packet or packets sent with its own delay.
The potential for a race hazard arises from the “content / payload” packets possibly becoming out of sequence with the “resume play” packet(s) at the Roku should Tablo OR SOME NETWORK ELEMENT fail to ensure proper order.
Not knowing how Tablo or Roku does its queues, multitasking, etc. this theory is loaded with conjecture, but is plausible if the boxes are designed with conventional OS methods and limitations.
Uninterrupted serialized streams (obviously) avoid / eliminate this hazard altogether.
Network components are a bit confusing. Partly because what is commonly called a router is usually a router, switch, and modem all in one box.
A modem is something that converts DSL, fiber, or cable signals to Ethernet.
A router sends network traffic between different networks. For example, between your wired LAN and Wifi, or between your LAN and the internet.
A switch sends network traffic only to its intended recipient. That is why they are used a lot. If two devices are connected to a switch, all their communication is transmitted only to themselves. The communication only leaves the switch if they need to talk to something that is not on it (like a WiFi device, something connected to the WiFi router, or the internet)
A hub looks like a switch, but is simpler in that it broadcasts the network traffic to all devices connected to it rather than just the intended target. For this reason they are only suitable for small networks.
So what is commonly called a WiFi Router may or may not have a modem in it. It has a router that directs traffic between the LAN, WAN, and WiFi. And it usually has a switch or hub in it for the wired ports. It also usually has a firewall, DNS, DHCP, and QoS built into it. All of which could be done by separate devices.
I apologize if my description is not 100%. I am attempting to simplify for anyone reading that is not overly technical.
Welcome to the Tablo forum. As others have already pointed out to you, replies in this forum which do not contain an explicit quote / citation / link, such as your earlier post regarding spelling / etc. are assumed to reply not to the very first starter original post in the thread but instead to the most recent post, in this case my post months later.
This forum looks and behaves differently so your initial confusion is understandable. It took me a while to get used to it also.
I know there are a few conversations happening around this issue, but I’m trying to come up with a workaround until a resolution is found. I’m not saying I have it, but it’s seemingly stable so far.
I know a few people have had luck switching from wired to wireless. I tried that again this morning, putting it on my 5GHz network. Within 30 seconds of a recorded show, I received the all too familiar “LPW” message.
Putzing around in the different Roku settings, there is one for “Display Type”. I changed it from 1080p to 720p, the screen flickered and eventually came up with a “Can you see this correctly” message. Confirmed.
I started the show over to where it had previously had issues and it skated right passed it. I watched a little bit longer and no issues. Is it fixed? Maybe? Again, I don’t see this as a fix. If it works, it’d be a decent workaround until a resolution is found.
I am recording at 1080p/8Mbps. I’m going to switch back to a wired connection, but wanted to post this up before heading out to work.
I did watch about 15 minutes of TV after my last post with a wired connection and didn’t see another occurrence of LPW. My wife has been watching recordings on her laptop because of this issue, so today I asked her to use Roku/Tablo and let me know how it goes. So far I haven’t heard from her, but I don’t know how much time she’s actually had - pesky self-employment
O.K. so I have also been experiencing this. I have 100 mbps connection ( which I speed test ) with several wireless booster/repeaters through the house so wireless speeds are not an issue. I have seen the posts suggesting it is an issue with the Roku streaming but I have had a Roku 3 for almost a year and all the other streaming apps I use, Netflix, Amazon, Sling, Google Play work without an issue so I don’t buy this response. I think it is an issue with the streaming within the Tablo app that they have to figure out. Don’t get me wrong, I LOVE my Tablo but this should become a non-issue quickly. If the Tablo team is serious about getting market adoption, they have to fix this fast. If you can’t watch TV without constant reloads then it’s all a mute value proposition. Please fix this Tablo…
Sling works on Roku (any of them) without issue? Sling tv is rock solid for me on an Nvidia Shield tv and fire tv but the Roku could not be more opposite. Freezing and buffering issues have been all over the Roku forums.
Well it sounds like you have a great internet connection for streaming from the WAN, but Tablo comes over the LAN a completely different animal. In fact you can disconnect your internet and Tablo will work just fine over your router. I would suggest that you test your LAN with something like NETSPOT and see what your coverage looks like and also check the specs on your speeds on the LAN.
I tried this awhile ago and had no success. Tablo and my Rokus needed to “call home” to Nuyyou with an initialization process via the Internet and possibly other WAN traffic as well. This was many monthes and many revisions ago, so my experience may be OBE.
