I believe I have it narrowed down this issue. Periodically, my Tablo unit will stop responding to any client, including network pings, thus necessitating a power bounce (pulling the plug, waiting 60 seconds, then power back on). Although at first glance it appeared to be random, now it looks like it is tied to ISP IP address changes. Note: I cannot get a static IP address with my setup, so ISP IP address changes will occur periodically. However, the Tablo device is the only HW that is affected by this - not my security cameras, nor the HDHomeRun Extend units.
Also to note - I am not aware when an ISP IP address change occurs, as it is seamless to my router and network - Asus RT87U running asuswrt-merlin 380.61.
Yes, this has been seen by many on this form. Solution is as above - set up DHCP reservations for all devices on your LAN. I have about 30 devices on my LAN and all these problems went away after setting DHCP reservations for all.
Hello - thanks for the thought - however, a) yes, I have a static IP address assigned to the Tablo unit, b) this occurs only when there is an ISP related IP address change (not an internal IP Address change) - say from their 100.x.x.x pool, or even changing ISP from Verizon to Frontier. In either case, the external IP address changes, and that is what appears to be affecting the Tablo HW.
You guys are solving the wrong problem. @Hotrod_Hemi states his ISP IP address, a.k.a. Public IP address, changes, and believes that is causing his Tablo to freeze.
DHCP IP reservations on his LAN, a.k.a. Private IP addresses, are a good idea, but have nothing to do with the Public IP address change.
@Radojevic - yes, correct - an even simpler summary is this - “Tablo stops responding with a WAN IP Address change” - requiring a power bounce to get it working again - until the next WAN IP address change - rinse and repeat.
It’s hard to see how a WAN IP change would impact what’s happening on your LAN insofar as affecting the ability of LAN devices to interconnect. The WAN IP change might imply that the Tablo and its remote servers temporarily lost the ability to talk to one another until the servers reestablish contact with Tablo, but I don’t think that breaks LAN connectivity (I’ve never tried this, so I can’t say for certain). A way to prove/disprove that, however, would be to disconnect your WAN and see if any of your clients can reach the Tablo.
I don’t know how often your WAN IP changes, or if you’ve managed to correlate the Tablo LAN connection breaking every time the WAN IP changes, but my initial thought is that it’s a coincidence.
At any rate, it might be appropriate to contact Tablo support at this point. They should be able to get a handle on this rather quickly.
I found it difficult to correlate the two issues, until I replicated it - I can replicate that exact scenario. It appears that when the WAN link is dropped/subnet changes, the link to ‘phone home’ is lost and does not automatically reconnect (although the WAN link is fully functional), resulting in the local subnet clients losing the ability to talk to the Tablo device, as those clients also require the ability to ‘phone home’ in order to talk to the local Tablo device.
Tablo Support will be next - just checking with the user base first to inquire on any existing or similar experiences.
I just disconnected my WAN to see what would happen… Initially, I could connect with my Roku and even play live TV, until I reset it, then lost the ability to connect at all. On my browser (pointed to my.tablotv.com) I couldn’t connect, though when I pointed my browser to the numeric IP of the Tablo, I got the Nuvyyo server message only. My android Asus Nexus Player could not connect at all. Didn’t try my Android cell phone, but I suspect the results would not be different.
So my test shows that the Tablo is still reachable on the LAN, it just doesn’t function. That implies that our LAN peripherals don’t communicate directly with Tablo, instead, requiring that we access it via the Tablo servers in order to work.
It’s odd that we totally lose the ability to watch live or recorded TV if the link to the server breaks for any reason. Might be nice if they could fix that.
Anyway, back to your problem, it’s possible that you’re one of the few people who experiences frequent WAN IP changes (I don’t think mine has ever changed, or maybe rarely even tho I have a dynamic IP) so your situation may not be all that common, and it possibly points to a bug in the Tablo’s code, where maybe it needs to “phone home” more frequently so the servers know where it is.
Yes, the Roku can work without an internet connection, but not after it’s been reset according to my testing.
I don’t know when or how often the Tablo checks in with the servers, but I suspect that it can be forced without having to cycle power, either via a pushbutton reboot, or perhaps by temporarily disabling the LAN connection (unplugging the Ethernet cable if hard wired into the router).
From the problem description, maybe the Tablo checks into the servers only during the initial boot, or very infrequently?
I didn’t try the reset button, I just went straight to a power cycle. When it happened I didn’t understand why it happened. In reading the forums I saw the external IP address changing causing the symptom I saw for some people. I have a VPN server on my network and no name server setup, so I’m very aware of whenever the external IP address changes. I had used the vpn server in the last couple of days, so it was on the old IP address, and I haven’t rebooted my cable modem. I checked today after reading the forum and the address had changed. If it ever happens again I’ll try to remember to use the button. Hopefully the problem will be fixed before then.
FWIW - I have not tested the reset button vs power cycle - [may be helpful for Tablo related to troubleshooting], however, the net effect is the same, regardless of which method is used to reset/re-establish a ‘clean’ WAN connection.
I will confirm based on my scenario - when the WAN link connection was lost (due to the IP address change), the recordings did not occur - those recordings were missed - which, at the core here, is the real issue/concern.