Trying to simplify things, breaking it down. A network connection is a network connection weather it’s over your local home lan or the internet (mostly and as far as this discussion goes).
You tablo has/is an HTTP web server, to stream HLS video to a player, be it in a browser or embed in an app or straight up media player… virtually the same as if you were streaming the show from an online service. (well there are other protocols and methods than HLS).
So once the streams leaves the tablo, or any server, it has no control what the player does with it. I suspect there may be some “communication” the as part of the protocol.
In our tablo example, the stream is a playlist. http://tabloIP:18080/pvr/xxxx/pl/playlist.m3u8 You can substitue the xxx for the ID of an actual number and many media players can play the streams directly.
For those who aren’t network engineers, here’s a quick bit of info that might be helpful:
Unicast = 1 source of data flowing to 1 destination. Kinda like if you call someone and leave them a voicemail. You’re the source, the voicemail box is the destination, and no other sources or destinations are involved.
Broadcast = 1 source to all destinations. Kinda like a tornado siren. Everyone in the area receives the alert signal whether they want to or not.
Multicast = some sources to some destinations. Sorta like going to a movie theater and choosing a movie. If there are 10 screens and 50 people watching each screen, that means 500 people are consuming content, but the content is only being played 10 times. Each person gets to choose which content (movie) they watch, or they can choose to watch no movie at all. But if they do choose a movie, they watch the same content at the same time as the others on the screen they chose to watch.
Now to put this in more network-ey terms. Think about cable TV providers and their digital cable services. Probably not many in this particular forum subscribe to cable TV, but for the sake of explaining, when everyone is watching the Superbowl, there aren’t 100 million individual unicast streams going to everyone’s TVs over cable companies’ networks. It’s multicasted. So the subscribers that want to watch set their cable box to a certain channel (like choosing a movie in a movie theater) and they watch the content that’s being multicasted at the same time to everyone else who’s watching. The analogy breaks down a bit when you introduce DVRs that can record and let you “pause live TV.” When you do that, you’re then watching a recording of the multicasted content until you “catch up.” Then you go back to watching the same content.
Multicast support is obviously something Tablo should have. It’s how Sonos speakers keep music in sync between their devices. And it’s the only way to have a college football game on three TVs around the house without a noticeable lag. I just tried watching a football game using a combination of the Tablo app on a Samsung smart TV and two Apple TVs each running the Tablo app. So three destinations. It was so comically bad I timed it with my phone and there was a 16.7 second delay between the living room and the back porch. People would cheer inside and those of us on the back porch would say “Well, I guess we’ll score on this one.”
Please, Tablo, be a dear and implement multicast to fix this.
non-network engineer looking for clarification/understanding…
an analogy associated with tablo, stations broadcasting over the air television frequencies? Commonly referred to as OTA [Digital] TV
Back to the tablo, like it’s HTTP server streaming HLS video to 6 different devices? Each choosing what to watch, even if it’s the same.
stick with straight up network terms for bit yet –
Simply, I’ll be watch a recording virtually like any other recording on the drive, except maybe it’s not stored as a recording in the DB. It’s .ts segments accumulate and playlist is updated just the same and a conventional recording.
OR, when I watch any recording I’m - “watching a recording of the multicasted content”, isn’t this just semantics? or is the the network-ey part?
Doesn’t this involve a video distribution system setup most likely using IPTV or other methodologies?
Tablo is a consumer device, although it might nice… it’s probably not a “typical consumer” thing. You probably did look silly trying to make something work beyond it’s ability… just to prove to everyone you’re the tech guy.
I suspect this kind of thing would make a difference to some but not all. I bet many users would benefit from time to time, though. And in my part of the country–tornado alley–it’s not uncommon to have all of the TVs on at the same time just to watch the weather at certain times of year.
I offered the analogies and illustrations to be helpful. I could have just referenced the RFCs or puffed my chest out and mentioned the fact that I managed a network of 1600 retail stores with satellite connectivity where we multicasted out music and video. But I didn’t want to come across as an asshat like you seem unhelpful or pretentious.
I did want to know, for someone with a background, if analogies relating to tablo and it’s functions were valid. For some, it helps to illustrate the specifics we wish to understand. I guess mine were too simplistic, as you didn’t bother.
I don’t know it’s regional. As with your story about the football game - sports is typical American pastime. I don’t follow sports, but I often have a couple TV on, particularly when I’m getting ready to leave. I’m throughout the house - from one end to the other. Currently I have to lowest cost, turn the TVs on to the same channel set-up… that’s all I could afford.
Your perspective of my pretension inquiring about alternative comparison maybe a reflection of your own pretentious, see if there’s an RFC for that.
I wouldn’t call that a solution though. When someone pauses one of the TVs, they can’t then easily rejoin the other two where they are. If each TV was receiving content via multicast, are is just one instance of the content instead of three. If someone pauses one, they would be behind, but then they should be able to push a “Live TV” button to again start receiving the multicast content the other two are getting.
Due to tablo’s transcoding it doesn’t play TV in realtime. That’s why you get a delay changing channels.
I don’t have an RFC, it varies by device, network connection and other network-ey stuff.
Tablo uses HLS and streams them via an HTTP server - just like any internet server, I think, I asked about things.
If you could “live stream” something via the internet across several devices without delay… then you could with your tablo. I haven’t tried this, with your background, you can prove tablo isn’t working or multicasting via an RFC like other servers and I bet they’ll look into more seriously.
There have been several others making similar misunderstood comments. I’m not sure where “video distribution” is used to describe any tablo device or a vague reference to IPTV.
What else can take OTA TV and let me watch it via apps for Apple TV and Samsung smart TVs? The only other thing I found that comes close is HDHomeRun which has an Apple TV app but won’t work natively on Samsung TVs.
The delay the results from the transcoding process doesn’t bother me. What I’m asking for is, once the transcoding is complete and the content is put into IP frames and sent out the network interface of the Tablo, it’s multicasted instead of unicasted. In the case where two or more TVs are watching the same content, this conceivably help the Tablo because it would have to do less transcoding. If, over the weekend, it was taking the same channel and transcoding it three separate times and then unicasting that content to my three TVs individually, it was doing 3X the amount of work it should have been doing and it explains the 16.7-second lag. That just isn’t good design.
It’s a perfectly good design when you’re designing for the 95+% use case. The UI complexities, plus the underlying additions to the network stack, required for a multi-cast solution are unwarranted for the small use case you present.
Also, just to clarify something, the Tablo does not do a “unicast” of the stream. The clients request HTS segments as needed. Which is a very different thing. And it’s only one transcode no matter how many times the content is played on the local LAN. Remote connects are a different beast.
I think you’re making this too “networking-ey”. I do know tablo runs lighttpd - a web server, to stream HLS multimedia. The IP frames and TCP protocol and uni/mulit-cast are networking overhead, you’ve overlooking the methodology. I’m sure I’m mixing things up a bit, but hope you can see through it.
If/when you and several of your friends access a web server via the internet - or your tablo it’s HTTP traffic (which could be a variety of things) but you each get your own stream… of the same thing, each in it’s own time. Your tablo is a web server .
It’s designed for transcoding, presumably engineered for 4 in with 6 out with out hesitation.
If you didn’t think of it as a multicast device it’s not so bad. I do have my issues with it, have found work-arounds, but for what it’s designed to do, when used as designed, it does a very reasonably good job.
(I’ve already often made comments I’m not entirely satisfied with it)
Others have made similar comment to yours. This just isn’t a video distribution system, for a couple hundred bucks!?! Make the investment and set up a whole house IPTV system so everyone can cheer all at once, and watch for tornadoes.
Curious, where does your “95+%” number come from? Telemetry you collect? Or just a made-up number to support your take on this and discredit mine? As for UI complexities, I can’t think of any UI changes that would be necessary. If two users are watching the same thing, it would just work better. They wouldn’t need to click a button or toggle a setting or something.
Perhaps I’m an edge case. Wouldn’t be the first time. But I didn’t create this thread, someone else did asking for the same thing. And without telemetry, you have no way of knowing if I’m an edge case or not. And to be clear: if the delay had been half a second, or even a full second, I probably wouldn’t have even bothered looking for a solution.
Here’s what I was seeing. The audio you hear is from a TV in an adjacent room. It’s laughable toward the end…there’s a 15-second commercial for Jimmy Kimmel and the lag is so bad, the TV is two commercials ahead of the audio at that point.
So that I’m not accused of being too “network-ey” again, what I want is for Tablo to not do that.
Here’s the thing, though. My TiVo setup (one Bolt and one Mini) was roughly twice as expensive as this Tablo. I sold it to someone else and got this Tablo because I was tired of having to reboot the Bolt once a week to get it to play nice with the Mini, and of TiVo’s goofy remotes, and of paying $150/year for a guide subscription. (Not that I mind paying subscription fees when I think they are reasonable and worth it–I’ve paid one for the Tablo guide thing.) But the TiVo never had this problem. I really liked the idea of being able to add my third Samsung TV without having to add another set-top box (TiVo Mini) with it.
At the end of the day, you’re right. This thing was cheap and maybe I just expected too much out of it.
Personal observation, both of my usage and what others say on these forums. Yes, it’s a niche case.
If you don’t want it to do that, then use the pause button to get them in as close a sync as you want.
There’s no unicast “stream”, even though everyone uses that term. Each client is requesting each segment via the built in web server. It’s dishing out HTS files, which are video segments. The server can’t force them into synchronization, since it’s a pull model, not a push model.
To do synchronized streams, that has to be totally redesigned. And yes, that requires UI work. What if one of the clients doesn’t want the synchronized stream? What if it wants to Pause/RW/FF independently?
Then it would work just like a cable company DVR or TiVo. The viewer doing the pausing or rewinding or fast-forwarding would knowingly separate themselves and be different until they caught up.
Maybe the right way to conceptualize is around tolerances as opposed to streams. If the viewer at TV #1 wants to watch the local news, they select the channel and get the news. If a new viewer at TV #2 wants to watch the same news, the app requests that content and Tablo should provide it with whatever content is appropriate to make it roughly match what TV #1 is seeing. You guys control the apps on the devices, so you could work in some way of dealing with this. If you know Samsung TVs are a lot slower than Apple TVs, then that could be taken into account when the Tablo unit decides which HTS files to hand back to the requeter.
And like I said earlier, it doesn’t need to be near perfect like Sonos is. Just close enough so as to be not distracting.
I haven’t seen you post any evidence that my number is grossly incorrect. Neither of us has any real evidence. I have almost 4 years experience with the device and with the content on these forums. How much do you have?
My last comment on this subject - The original post was a request for a feature. That’s fine. There were some inaccuracies in his assumptions about how the device actually works, some of which were pointed out. After that, the thread started getting into more and more technical discussion about what IS done or COULD be done, and many of them were also based on incorrect (or unsubstantiated) assumptions.
Doing push synchronized content would, as best I can tell looking at the API used by many of the ripping apps, require a complete redesign of the API between the server and the clients. I just don’t see that happening, and if I were a product manager at Nuyyvo, it would be so far down the product plan as to be invisible. Not because it’s a bad idea, but because it would take way to much work for the benefit.
