Add Advanced Options for Connecting to Tablo from Cleint

Feature Requests
1

Please add an advanced option that allows clients to specify the IP address where the Tablo device is located. Please deploy this feature to all Tablo clients (Web-Browser, Roku, Android, iPhone, etc).

The tablo client-applications (on all supported devices) do a good job connecting to the Tablo device if it is located on the same subnet as the client. However, if the tablo is located on a different subnet, the connect/re-scan features will not (and should not) locate it.

For example, let say my tablo is located at 192.168.1.1 and let say my Roku is located on a different subnet at 192.168.2.2. The Tablo app, on the Roku-client will only scan IP addresses from 192.168.1.1 through 192.168.1.254 and it will NOT scan any of the ip address from 192.168.2.1 through 192.168.2.254. This is not Roku specific; it applies to all Tablo client-applications on all supported devices.

I agree that it shouldn’t scan IP addresses on a different subnet, but it should at least allow advanced users to manually specify the IP location of the tablo! This feature needs to be added to all clients (web-browser, roku, andriod, iphone, iTV, fireTV, etc).

Additionally, this feature would be extremely useful for accomplishing “remote access” without the local pairing burden. If a user is savvy enough to put his tablo at a publicly accessible IP address, and even give it a domain name, then there ought to be an option of specifying that public IP address or domain name (ex. tablo.mywebsite.com), instead of scanning the local subnet (where the tablo isn’t).

There is no need to scan, if you know the exact IP! And, there are just too many circumstances where scanning doesn’t and shouldn’t work.

I realize you guys have worked very hard to make the Tablo as simple as possible. I’m a big fan of simple, but not of oversimplification! Please add advanced options near the connect/recan button!

2

Here’s a reply from TabloSupport in another topic covering some of your topics

You think no one has pleaded for such a basic feature?

I surmise, they want to keep it (relatively) simple for typical consumers. They conclude

it’s not part of their business model. You know some idiot user, thinking they know what they are doing will change advance settings and overwhelm tech support along with others who didn’t read the manual.

I feel your pain!

3

When I use the web app http://my.tablotv.com which has a .js to returen https://api.tablotv.com/assocserver/getipinfo/ If you use something that parses JSON you’ll see among the data it returns
"private_ip": "192.168.1.11"
regardless of subset, it’s from the tablo via internet not scanned from the local network in this scenario.

1 Like
4

That makes a lot of sense; use the interent to avoid scanning. This way, the only time the Tablo client would have to do a scan is if the internet connection is down.

If I purchase a brand new Roku, that has no knowledge that there’s a Tablo on a different subnet of my local LAN, I can see how what you’ve indicated could work way better than scanning. The code in the client would have to work like this:

  1. Send Tablotv.com a https post, so that they can detect your client’s public IP address.
  2. Base on the public ip source of the client, Tablotv.com can locate any tablo devices (in their database) that’s “last communication to base” was sourced from the same public IP address as the client.
  3. Since the tablo device probably reports it private IP address to base each time it connects to the internet, TabloTV’s database should be able to return a list of private ip addresses that the Tablo client should try to connect to before attempting a local scan.
  4. So, even if the device located on a different subnet, if the Tablo can route to that subnet, it will successfully make connection.

If that’s how they’re doing it, that’s great.

However, what if the tablo is located at a public IP address at a remote location (where proper port forwarding is enabled on that remote location’s firewall)? The client, in this example, has no awareness of which Tablo on the internet is your Tablo.

Therefore, the client application ought to have a feature that allows you to authenticate with Tablotv.com, so that the client can get the last public ip that your Tablo used, and then attempt connecting to that! Such a feature should also allow you to specify which ports to use at the public IP address to which connection should be attempted (port configuration is necessary in case the administrator has chosen non-standard ports that ultimately map to Tablo’s default ports within the LAN.

I’m sure Tablo’s developers are concerned about security too; they don’t want some hacker watching TV on someone else’s tablo. But this can be handled:

All they have to do, is require the client to authenticate to achieve remote connections. Before the tablo device allows a remote connection, it should contact tablotv.com to see if “a client sourced from that same public IP address as authenticated in the last x minutes”. If it has, then allow the connection. If it hasn’t don’t allow the connection. Sure it is possible that a client shares a public IP with an unknown 3rd party, but what are the odds of those unknown 3rd parties knowing the public IP address of your Tablo (they’d also have to know public ports you’ve chosen that forward to Tablo’s default ports)?

If you want to eliminate the possibility of other people on the same source IP as you connecting to the remote tablo, simply generate a key upon authentication and have both tablo and client knowing that key from tablotv.com via https. This way, the only remote client that can connect to the tablo, is the one that authenticated with tablotv.com

I hope the developers read this post. It is not cool to have to pair a 65 inch TV before taking it to the remote location you desire to serve with your Tablo. And, that local pairing doesn’t last forever either, eventually you have to take that big TV back to base to pair it again. So pairing needs to be possible via TabloTV.com (not just via local networking).

5

It’s my understanding you need a “subscription” to use remote connect. There are users/members here using a VPN successfully, I have not experience. I do know the the example I previously posted in the data returned include the keys : values
"public_ip" and "roku"

I believe this has been complained about brought up before - not a new issue. User name /password would provide some security and, when things do fail and you’re not near your local network.

I don’t think many will disagree with you. It’s not overly complex and, supposedly, easily implemented. It’s just not the path Nuvyyo took with their Tablo OTA DVR product line.

With just a few tweaks so many feel we could do so much more, but for tablo tech, it also opens the gates for issues.
You realize typical consumers have little to no understanding of networking fundamentals (why would/should they). Due to marketing, may believe free HD OTA is a new discovery you just gott’a try - myrid of misunderstandings. Now image if an OTA DVR had configurations just shy of a router…

6

Sure it does.
(Same Public IP address) + (2 TCP Ports) = (Unique Tablo #1)
(Same Public IP address) + (2 different TCP Ports) = (Unique Tablo #2)
That’s the way Tablo Connect (remote access) works now.

1 Like
7

Great, I don’t know if you saw the updates to my post regarding security, but I suspected some of what you’re saying…

Then, it seems, that the only missing feature is the ability for the remote client to authenticate with tablotv.com and have tablotv.com relay that authentication to the tablo devices, so that it will allow pairing to happen remotely, instead of requiring paring to be done on local networks only.

I paired an Amazon fire with my tablo before taking it to a remote location. It worked great for a while, then a tablo update (or a Amazon update) broke the pairing. I had to take the Amazon Fire back to the base LAN to “re-pair” it :slight_smile: .

The only thing missing is the ability to pair remotely. If you have a 65 inch tv to be used on a remote network with bad-rural-antenna-reception, re-pairing is too much trouble to consider. If you could pair via authentication to the tablotv.com website. It would be a killer new feature.

1 Like
8

This is a bit beyond me, I think this is where a VPN come into play?
I’ve seen others post how they remote connect via this method. I have no experience with VPN and only a superficial understanding, so I may be completely mistaken.

9

You can connect your elbow to you a-hole :speak_no_evil: with VPN, but that’s just a kickstand-workaround!

The most elegant way to accomplish remote pairing is via authentication with the tablotv.com website, which securely relays a key to both the client and the tablo device when the client authenticates with tablotv.com.

Upon a remote connection attempt, the tablo device receives this key over https from the client directly and then compares it to the key given to the Tablo device by tablotv.com. If the keys match, the connection is allowed and remote pairing is accomplished (and this process doesn’t have to happen again unless the pairing becomes invalidated by some update that breaks it).

10

sure, and :unicorn: unicorns are jumping :rainbow: over rainbows as :butterfly: butterflies fluttered around :sunflower: pretty flowers

not disagreeing, just putting it in perspective :poop:

1 Like
11

Funny. Come on now, this could be accomplished in one day by Tablo’s developers. Seriously, they’ve produced the best video watching interface I’ve seen. This feature of “remote pairing” is the only thing missing.

12

Maybe one day on the firmware side, a couple of days for EACH client, a week or more for the server side, then a month or more of testing.

What client updates get shelved to do that?

1 Like
13

Dude… this thing has it’s own HTTP server - lighttpd!! Why can’t I directly access it (ok, I can, but it’s not directly)
I can stream shows via my own player or use ffmpeg to concatenate an mp4. (ok, I don’t think that’s actually the process of joining an HLS segments) but I can’t directly find what shows equate to the IDs - now THAT would the the biggest improvement! (I use capto for IDs and wrapto to automate the downloads) Direct access over my local network!

Not having to pay for internet access to watch free OTA recorded content :exclamation::exclamation::exclamation:

14

oh yea, thank for letting me vent/share

15

Take a break from the commercial-skipping beta. “Remote Pairing” will be nice little break from that, while letting your commercial-skipping-beta-final-touches grow in your sub-conscious mind.

Plus, after you accomplish this on one client; the other ones will go quicker (just do Roku first since that’s what I like best) :slight_smile: .

You’ve already accomplished the code for pairing the devices, the missing part is the “tablotv.com login page for each client” and “the ability for Tablotv.com to notify the tablo device about new pairings that have been authenticated”. When a user is pairing a local device, they shouldn’t be prompted for login via the client app. So you can put “remote pairing” under some advanced menu, so that it doesn’t get seen much unless someone is looking for it and you can label it beta at first.

If you can’t put this feature at the top of your to-do-list, please (at least) add it to the list (if it isn’t already).

I love that Tablo. Good programming!

16

Depends on feature criteria.
The current feature requires client/server pairing.

This pairing can be accomplished in 2 ways:

  1. Directly connect to the Tablo local network, which requires physical proximity.
  2. Remotely connect to the Tablo local network via VPN.

Unless an internet rando is physically close enough to connect to the Tablo local wireless network, and can break thru its security, option 1 is very secure.
Option 2, while adding a secure, and encrypted network layer, is more accessible via the internet, and ultimately less secure than option 1.

I think of option 1 this way…
You can only call my home phone, if you previously, physically came over, and were approved to call my home phone.
Security, and flexibility are mutually exclusive.

17

… but I can’t directly find what shows equate to the IDs

Regarding that, I made this video for a friend:

18

Taboo Ripper isn’t directly accessing shows to IDs. If I recall, it only runs on propitary systems :scream: capto works wonderful and allows me to tweak things. Sometimes I just play shows through smplayer (virtually any PC media player will work)

19

Tablo saves recording in HLS format, so yes it pretty much needs a network (vs direct access raw drive) which you can do via http://tablo.lan:18080/pvr/ (of course changer tablo.lan to your network). Although there are other ways I guess.
I’m pretty sure mp4 is a lossey format, video said lossless.
I’m not home to reference the playlist url, but if you monitor you browsers network traffic you can pick out other I don’t have with me. (or search some posts and you ought to find something if it matters)

20

Taboo Ripper isn’t directly accessing shows to IDs.

Look at 1:29 in the video here. As you can see in the video, Tabloo Ripper located my device and showed all recorded show’s names. Then you select the ones you want to convert to MP4. That’s all it does. MP4 is lossy (I knew that but said it wrong in the video). I made that video quickly for a friend (unlisted on you tube, but accessible if you have the direct link).

I remember now, I hooked my tablo’s external hard drive up to my laptop hoping to copy files from it. Then I ran into all those IDs instead show names. That’s why I ultimately used Tablo Ripper to connect to my tablo (over the LAN) to get a few MP4s. I only did that once, but it work for me.

I’m a linux user myself, but as you can see, I have a virtual machine set up for when I come across programs that won’t run on Linux. I’ll check out capto.