July 17th, 2012, 08:38 AM
Found non HDCP display workaround.
Personally I couldn't believe that this actually worked, it's a very rudimentary workaround, but it should work for anyone who is desperate and has a HDMI>DVI adapters and monitor that works with the boxee, and of course is willing to either keep the monitor nearby or just leave the boxee box on 24/7.
I've recently bought a Boxee Box, and I found out the hard way that it did not work with my old LG Plasma which does not have a HDMI port. I've been using a Female HDMI>Male DVI adapter for quite some time for an Xbox 360 in the past and presently a Playstation 3, this how ever did not work with the Boxee Box and I was greeted with a "No Signal" message after the initial loading screen using an adapter, I was extremely disappointed. I tried all sorts of crap but eventually ended up reading that this is likely something to do with the initial HDCP handshake which happens after the loading screen, so I gave up and ordered a cheap HDCP capable HDMI>VGA adapter from China, I'm still waiting for it.
I do however have a computer monitor that has a HDMI port, and without a hitch the boxee box works when using the monitor, it even works when using an adapter (Female DVI>Male HDMI, though. The DVI port in my screen couldn't fit the Female HDMI>Male DVI adapter.)
So I started to think, I wonder, if by any chance, after the handshaking process, if I unplugged the DVI cable from the monitor and plugged it into the TV, would it continue to display an image? Remarkably, it did. I even went as far as to push my luck by swapping the cable to the Female HDMI>Male DVI adapter in the tv and a HDMI cord into the boxee box, and it still worked.
Let me explain and also attempt to illustrate for anyone interested.
Firstly, I plugged the Boxee box into my monitor like so.
Boxee----Male HDMI to Female DVI----DVI Cable----Monitor. (Although, I'm sure this will work with just a straight through HDMI cable to the monitor.)
Let the Boxee boot up to the home screen. Unplug the boxee from the monitor, make sure to leave it powered on. Have the television turned off (I unplugged it for 10 seconds before hand, just to be on the safe side), plug the DVI cable into the television. Turn the television on, and the picture should display.
It's literally just a simple dumb swap.
I hope this helps someone out. And my apologies if this has already been mentioned/discovered, it wouldn't take a genius to figure it out.
July 17th, 2012, 08:44 AM
That sounds like a nice little bug in your favor, because re-pluging a DVI connection should trigger a hot-plug event which would (should) handshake again.
If Boxee requires an HDCP connection however, then I also consider that an issue. Only specific content on Boxee requires that protection, so Boxee should only require that kind of connection from the customer when playing that protected content. In other words, it should be dynamic, like it is on other platforms, including Macs. When you try to play protected content, it checks your display connection and if you don't have an HDCP link a message will pop up telling you it can't initiate playback and why. Everything else, including most local content and web-based video should play through.
Last edited by twistybox; July 17th, 2012 at 10:12 AM.
July 17th, 2012, 08:51 AM
Well if it isn't HDCP related, then I wonder why it doesn't "just work" using these adapters. It's obviously not a display limitation. I've found this to be a common problem among these older displays, so I sorta figured HDCP was what was likely missing and that was the reason as to why it doesn't work, and many other came to that conclusion.
Although, if it really is HDCP handshaking after the initial loading screen, could I open a request/support case with D-Link to request removal of the initial HDCP handshake in the next update? Can't really see why it's required, unless somebody can shed some light on that. I imagine it would help many boxee users.
July 17th, 2012, 10:12 AM
I'm not saying, nor even suggesting it's not HDCP. There's no reason to believe all the observations in the first post aren't 100% accurate. I'm just suggesting that there's at least one or more issues. Bugs if you'd like to call them that, but likely just design/implementation decisions that perhaps should have gone a different way.