WTF is... IEEE 1905.1? It sounds like a solution looking for a problem. A technology that allows networked devices in the home connected by different network media to operate as if they were connected across a single medium. Surely TCP/IP already allows you to do that, routing packets from, say, network attached storage linked to a router over an …
This post has been deleted by its author
Depending on your tv etc etc. What exactly do you want to do?
If you have a relatively recent smart tv then it probably has some sort of network awareness and some sort of DLNA mode. You then set up your pc upstairs as a DLNA server (minidlna, mediatomb, ps3mediaserver, windows media player?) and your tv should be able to see it and play media from it.
If your TV has a 'dumb renderer' capability you can control this all from your mobile phone, there are various apps like 'skifta' and 'allshare' that allow you to browse your server's media selection and push it to the telly. How well integrated it is depends on the specific tv. My 2010 plasma has a sort of receiver-mode you have to put it into first, whereas a friend's newer (2012) model is in receiver mode constantly and anything you send will interrupt what's on now. You can even (with quite some difficulty and a package called python-coherence) set up a linux box as a dumb audio or video renderer in this way.
Of course this only works for media files, if that's not what you meant and you need a more generic streaming mechanism you might need another solution.
Thanks for your input on this. I didn't really explain myself very well though. I'm really looking at 'wire up the telly via this protocol and be able to use it as a screen for any device on the network' type scenario.
i.e. PC upstairs with a monitor, on home plug. Add TV downstairs to homeplug and tell pc 'hey use this tv instead of the monitor'.
I know this will also be dependant on the graphics adapter, but surely this sort of thing should be doable by now. We have even had video over wireless by nvidia (albeit rubbish) but with the bandwidth available these days on home networks, this technology still being absent is demoralising.
I think that would be difficult. The nearest you're really going to get is using a small thin-client box attached to the telly that can run something like rdesktop/vnc client. Doing it this way you get a local keyboard and mouse too. I don't think you'll be getting 3D acceleration going very easily that way though.
I wasted money and a lot of time trying to get a DNLA solution working to display videos from my computer on my living room TV. It failed because DNLA is a spec not an end-to-end solution. Multiple devices supporting the standard don't actually mean that something useful is going to happen. That device A will be able to successfully display output on device B is in no way guaranteed or likely.
This sounds exactly the same. There is a standard for a network, but only a suggestion that something useful could happen with it. There is so much more to define on top of a network before something useful can happen. For instance the fact that there is a WiFi connection on my TV, games console and phone doesn't mean that I can play videos from my phone on my TV. There has to be something on the phone that knows how to work with a different something connected to the TV. The network doesn't matter that much.
Because I agree it was a failure for quite some years, but recently I've been quite impressed.
Only quite impressed, not fully. There's some bug (protocol related AFAICT) that means my phone will only play one song at a time on the various audio renderers we have in the house, but it does mostly work now.
How did I solve it? It being the 'only plays one song at a time' problem? I haven't yet. AFAICT (and this is all AFAICT, most of the controller software is closed-source and the renderer firmware is not something I've looked into) it comes down to that consistent DLNA bug-bear, which is that not everything implements the same subset. In particular it seems that the DLNA controller (phone) sends the renderer (tv, squeezebox etc) some sort of URL type thing (address of the media file@the chosen server), so the controller is not feeding the data to the renderer directly. It then expects the renderer to send a message back to the controller when it's finished playing the song/video/whatever so the controller can send the next URL in the playlist.
This message never arrives, or it gets sent but the controller drops it, or something, and then what happens depends on the renderer. Most of them just go quiet, some of them repeat the same track forever until stopped. One of the potential solutions is to ditch DLNA entirely and use logitechs squeezebox software and solution, which works very nicely, but they've just discontinued all the hardware, so the only thing you can do now is run softsqueeze.
>I have a Smart TV that did this. It decided it was going to use the WiFi and ignore my nice fast wired network.
Why on earth did you configure the WiFi as well unless it was perhaps just to see what happens?
Assuming your WiFi is bridged to the same IP subnet as your GbE then it is only the metric for the two resulting default routes that will determine the path that packets take. Again I am assuming that your TV firmware can support multiple default routes - perhaps it can't and the WiFi coming up second overwrites the default route that the GbE interface wrote.
It is very unlikely that the OS it runs can reach for the ip and iptables commands or pfctl (I'm not too familiar with *BSD) or similar along with a route connectivity monitoring daemon to maintain load balancing over two links.
A telly is not usually quite as fully featured in the IP stack department as a desktop OS and should be treated as such. Just because it's called "smart" doesn't mean you should treat it as such.
Did you report the bug to their support? Whinging on the Reg isn't going to get this fixed.
Just noticed your post's penguin tag: please hand in your geek card on the way out 8)
Cheers
Jon
Why not, I got a mac pro with both Ethernet and WiFi connected.
And it has some usable side effects. E.g. I can have a public ip, instead of having to do port forwarding to the computer and still be in the same network as all the other devices.
So why should a gadget with both options be any worse at handling both connections?
IEEE 1905.1 may well be searching for a problem to solve, and it may, some observers argue, amount to little more than a standard designed to encourage consumers to buy more kit, but it has some big-name brands behind it and it’s coming to domestic networking hardware soon.
s/b
IEEE 1905.1 may well be searching for a problem to solve, and it may, some observers argue, amount to little more than a standard designed to encourage consumers to buy more kit, and that argument is borne out by the facts that it has some big-name brands behind it and it’s coming to domestic networking hardware soon.
This seems to offer potential for use to enable much easier channel bonding, for example, for ISP <> CPE situations where aggregating several slower DSL links is required - especially where VDSL is not available or can't achieve high speeds (anyone 1km from the cabinet, for example!). Currently, getting an ISP to channel bond is a challenge in futility and cost.
ISP equipment supporting 1905.1 would make the process easy and transparent and not require any IP-level configuration with round-robin or other techniques in the CPE.
Bring up multiple PPPoE connections on the same account, and provided the ISP account enables it, you've got multi-DSL channel bonding sorted.
Lack of standards isn't the reason your ISP doesn't offer that service, it's because you are using an ISP for low bandwidth users. If you select an ISP that caters for heavy users then you'll find most of them offer line bonding options of some kind (some will even bond VDSL lines), of course they also expect you to use the extra bandwidth so it's not going to be as cheap as an ISP offering you a "check your facebooks" connection.
Funny you should mention PPP, as that's the most obvious (although not only) way to do it - PPP has built in support for multiple connections creating a single logical pipe, works with bog standard PPP equipment that is already deployed and doesn't require any new standards or new devices. Used to be quite popular for bonding dialup connections together.
There's a diagram showing 802.11 talking to 802.3.... Isn't that what an AP already does without this new "technology"? Won't we still need that anyway?
I didn't pay much attention to the other entries in that diagram - but I am assuming none of the rest can simply plug in at a physical layer with this new thing either.
Also, who seriously connects a TV with both cable and wireless? Surely if you've cabled it up, you don't go to the added effort of entering the WiFi details....
At least DNLA understood that you need to specify conformance tests if it's going to work in the wild. Which is a rather important detail which is stangely missing from most IEEE specifications. As a result they tend to flounder in the market until an external body like the Wi-Fi Alliance comes along, takes them over and adds the missing bits.
So I'd conclude that it does look like DNLA, but without any interoperability or testing. Perhaps it would be wise not to ask Santa for any 1905.1 stuff for the next few decades.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
