Fair points. In that case then, all I would ask from them is a reply to this thread stating a reversal from their previous position saying that this feature was essentially “in the pipe”. Ex.: “After 4 years of further review and user feedback we have found this feature request not feasible for Tablo to offer. Here is a KBA to workarounds some users have found to work…” The transparency would be quite admirable, IMHO.
One of the worst things a company can do is state they are working on a desired feature.
The feature may never see the light of day.
However, customers continually prod the company to state whether or not they are working on the desired feature, pressuring the company to state they are.
Now customers have an expectation, and with it, disappointment when the expectation is not met within the customers’ timeframe, reasonable, or not.
It’s a double-edged sword.
Yeah, I’m not looking to rake them over coals for the reversal if they aren’t going to add the feature but it would be nice to know before I get my entire [extended] family invested in the platform. That way at least I have a better idea of how many IT support hours I might incur
Endless, it’s always endless.
I always find it endless amusing when users think that a small VC company like Nuvyyo has an unlimited supply of programers churning out all of their wants and desires.
And when you poke them a little it’s like watching a youtube video of Dr. Pimple Popper at work.
I don’t have any stats, but I highly doubt typical American consumers are very informed about much of any thing. Saying that, just having a sense of some technical understanding, neither you nor many here fit the demographic of “typical”.
OTA is sometimes marketed almost as newly discovered free TV… and people are like - wow look what I just found. Other than digital signals, there nothing new about over the air broadcast programing. So how many are going to actually research a product beyond amazon.com
Ideally, you are right. People should take some responsibility for themselves.
Off topic (well, the thread is moving off topic), but I remember the early days of Roku where people thought that Roku gave you free recent content (that is major motion pictures currently in theaters, live TV, recent TV). Lots of returns made for a huge refurb (discount) market. Ah… those were the days.
So you want users to stop making suggestions? and they should do away with the Feature Requests sections?
…or it’s just something you find endlessly amusing
So it’s very likely they have a great deal of data about users! There’s already info from registering your device and, most likely, subscribing to guide data info - which also include the option for tablo connect. It already is a subscription service.
As for resale, users are already sharing outside of their household, limited by number of tuners.
Nice info on Amplitude. I saw a reference to “amplitude_id” CUID in the browser cookie which would indicate they have a unique, serialized ID for users already in use. I would agree a lot is already tied to the account and guide subscription so seems like things are mostly in place for the feature if they felt like it was worth rolling out.
Yes, people are streaming outside limited by the number of timers but I’m sure there are some enterprising folks who may buy quite a few tuners, rack ‘em in co-location, and resell account access so I could still see why they may want to use one of the preventative measures I detailed.
I’ve picked up things examining network traffic via browser’s “web developer’s” tools. I generally use firefox, but chrome has options available. You do have to be otherwise board or just inexplicably curious.
Some have suggested a wire shark, but I’ve found it to but way too over kill and cumbersome for just this.
And what types of business is Amplitude in?
“a 360° view of behavior across your customer interaction layer.”
“Utilize behavioral reporting to see how users interact with your product.”
Companies use the product to understand how customers use their UI products. In the tablo survey threads you might see posts indicating they have information about how customers are using their apps. Where do you think this information may have come from. Ho-Hum.
I think they are in BIG DATA business. It’s like a bahazillion dollar industry you hear little about. Giant corporations collecting detailed information from virtually every aspect of our lives. Giving superficial easily understood examples of what they may collect, without disclosing just how detailed it actually is.
Those are just buzz words… trying to make my experience an enjoyable one. Here’s a youtube video This Is a Generic Brand Video, by Dissolve full of images and words to get you to think about stuff and feel good… for no real reason.
Before a company releases a survey, the statics people need to know what a successful survey will look like. Often survey questions are asked in a specific way to get the answer they want. A response ranging from 1 to 5 or 10 (agree or disagree) doesn’t profide an adequate answer.
That’s were I suspect it comes from, convince consumers they need this. Something which will generate the most profit with minimal investment. Hum-Ho.
I was one of those strongly pushing for remote pairing some years ago. My thinking has evolved and subsequent Tablo improvements have sent that feature request to “maybe never” box, AFAIC.
The initial process is exceptionally easy and proven to be fairly stable over long term. True, there’s a very small number of “us” but I’m very grateful for whatever remote access can be maintained over periods spanning weeks/months.
So for anyone who finds this thread when trying to setup a Tablo client device remotely, without syncing in your home for the first time, let me summarize the issue and workaround to enable Tablo Connect without driving the device to your house first:
- Tablo Connect doesn’t work until you connect and sync the device first on your local LAN.
- The Tablo discovery process happens at layer 2 (OSI network model) using broadcast traffic so the client device has to be on the exact same IPV4 subnet as the tuner unit.
- Popular, turnkey OpenVPN setups using ‘tun’ interface will not work as ‘tun’ adapter only passes layer 3 traffic; instead ‘tap’ interface must be used.
- If your client is a Mac or PC then the setup is not difficult, just need to have a router at home running a ‘tap’ or ‘gretap’ (if using IPSEC) tunnel that is bridged to your LAN so that DHCP address assignments are within your subnet then just run your VPN client application of choice to connect via my.tablotv.com.
- Your VPN server setup must have the option for redirecting all IPV4 client traffic over the tunnel so that no broadcast traffic is missed (unless you want to setup specific, static routes then by all means go ahead but that’s a PITA).
- If your client device is not a Mac or PC (i.e. phone, Fire TV, etc.) then you need a endpoint network device to act as your VPN client which can further bridge the connect to your device over WiFi.
- In my case I used a PFSense router/firewall as my OpenVPN server and a GL.iNet MT300A travel router running the vendor’s flavor of OpenWRT as my client.
- A specific quirk with using ‘tap’ or ‘gretap’ on OpenWRT devices is that you must set the protocol type to DHCP client (needs an IP on your subnet to set routes for redirecting all traffic back to your LAN) and, in OpenVPN client configuration file, use the ‘route-delay’ option as it will take a few seconds for the client to pull an IP address from your LAN router over the VPN tunnel. Missing the ‘route-delay’ option initially cost me days of troubleshooting as GL.iNet is mostly setup for ‘tun’ and their OpenVPN scripts that stand up the client end of the tunnel were failing to set routes as they were running before the interface could pull an IP from the LAN router’s DHCP server.
- Once you have a working VPN client endpoint connection over ‘tap’ interface, you must then bridge ‘tap’ to your WiFi interface so that your WiFi device can connect and pull an IP from your LAN’s DHCP subnet.
- At this point you should be able to connect most devices like Android/iPhone via WiFi to your VPN endpoint device, receive an IP on your LAN’s subnet, and then open the Tablo app to discover the tuner and sync.
- Full warning that syncs over VPNs are a lot slower than they are on your LAN (probably another reason why Tablo hasn’t added remote access setup); my sync took 10-20 minutes on a Fire TV stick.
- A specific quirk with the Fire TV devices is that the Tablo app on them doesn’t seem to pickup the necessary broadcast traffic from the tuner on your LAN when your VPN tunnel is connected using UDP (it won’t find any devices) so if you have Fire TV devices you’ll likely need to ensure your tunnel is over TCP.
- For those of you rural folks who use CGNAT’ed cellular providers for your home internet, you will have to first setup your router with a VPN service that allows port forwarding back to your router as you will need a publicly rout-able IPV4 address to run your VPN server over and for Tablo Connect to run on (yes, your can create cascaded tunnels, a.k.a. tunnel inception; it’s just slower than if you had an an ISP which provided your with an already publicly route-able address).
- Once your device is connected to the Tablo and initial sync is complete, you can disconnect it from the VPN endpoint’s WiFi bridge and Tablo Connect will now work (assuming your have already forwarded the necessary ports for it on your router and/or CGNAT VPN workaround solution).
- You really don’t want to stream over your VPN endpoint device since ‘tap’ (especially over a cascaded tunnel solution) will be slow and likely cause you to buffer a lot (remember, the whole point of all this was to complete the initially ‘sync’ so that Tablo Connect will then work without a VPN connection).
- If you don’t want your Tablo publicly accessible you can use a VPN connection back to it from your client devices, just be sure to use a ‘tun’ setup (Android/iPhone, don’t support ‘tap’ anyways).
If the device ever has to resync you’ll have to connect it back up to the ‘tap’ VPN endpoint which is why I would still think that the feature request in the OP would be a much better solution. However, I see from other forum members that Tablo Connect works for weeks/months without needing a re-sync so that’s good to hear. This setup took me a few weeks to get up and running so if you have issues feel free to PM me as I understand it’s complex and not for everyone.
I’d rather just pay your plane ticket.
It looks like you could’ve found a cure for cancer in the time it took you to figure out how to watch last week’s Grey’s Anatomy at Starbucks instead of your house.
LOL! Yeah, and I just brought my own TV and Fire TV Stick to Starbucks to watch it on too… SMDH. You seem to have missed the reason for this VPN setup. No one needs to do this to watch TV at their local coffee shop, once your device has completed the initial sync then Tablo Connect would work fine on something like your cell phone or laptop on public WiFi without jumping through any hoops. This is only for setting up a new device remote from your LAN that’s not reasonable to bring back to your LAN.
Without this setup I would be driving to my grandparents who have a Fire Stick (30+ min. drive away from my house), taking the device, turning around driving home, syncing it, then driving back. And God forbid something happens to the Tablo app or the device where I need to do another initial connect and sync, then I’m driving out there again (I’ve already had to replace one bad device there before). This is why the feature requested by the OP would be great to have, until then, I’ll save my time and my gas with this VPN solution to fall back on and hopefully my posting the details to this thread will save someone else having to “find the cure for cancer” like I did…
So, got my fire stick all setup at my grandpa’s and synced over the VPN yesterday but within a couple of hours of streaming my Tablo tuner unit stopped responding. Figured it was a fluke so pulled the power and it came back but now it’s losing connection consistently even on my LAN via Ethernet. The LED flips out and looks like it’s having a seizure when this happens (I have the LED turned off in settings) so it appears to be a hardware issue (already had the latest firmware and running with a fan underneath it). I’m sure it could be replaced but I’ve sunk too many hours into this project already so it’s being returned. Guess I am fated to run Plex after all.
Appreciate the lively community of these forums and the refund Tablo willingly gave me on the lifetime service, but I will be moving on with an HD Homerun Quatro / NVIDIA Shield combo that I see a handful of other folks with a Plex pass are using successfully.
Sorry to hear of your issues. I’ve contemplated the Quatro / Shield TV combo as well but just as much for others for future reference (not implying you don’t already know this, I’m sure you do), the key difference between the Quatro and Tablo is the hardware encoding the Tablo does so the recorded media is already in a format that can be played back on multiple devices (for me Roku, multiple Android devices, Shield TV) with no further transcoding required (Direct Play in Plex in fact).
Are you planning on using the Shield TV as the Plex Server as well or just for playback? Not as much of an issue if you are only going to be doing playback via the Shield TV (I have one) and the Plex Server is a separate, beefier machine. However, as a Plex Server the Shield TV can only really handle 2 simultaneous 1080P transcodes and with the Quatro recorded media needing to be transcoded for most playback devices you can run into a resource crunch quickly if you have multiple people trying to play back recorded content at the same time.
Of course, the HDHR Extend can be a solution to that issue since it does hardware transcoding just like the Tablo, but it’s also more expensive and is also only available with 2 tuners. Since I have a 4 tuner Tablo the cost to move to a comparable 4 tuner solution with HDHR tuners (2 Extends) has kept me away from researching that solution any further right now.