Anyone get HD-Photos to work as standalone HME?

[minckster]

The Java Network Launch Protocol (JNLP) file for the HD-Photos app in TiVo Desktop 2.4 is available at Program Files\TiVo\Desktop\Hme\hdphotos.jnlp. Has anyone been able to get this to work as a standalone HME app, particularly on a Mac?

I can copy the .jnlp to my Mac, double click it, and it appears to start working. It downloads JAR files from TiVo, and actually launches an HD Photos app, but that quickly closes. The error messages in my console.log file follow. The app's attempt to contact the TiVo Desktop server doesn't seem promising for getting this app to work with TiVo Desktop 1.9.3 for Mac.2007-04-03 09:22:43.110 java[24497] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (java.ServiceProvider)
Instance ID = 105097f960749b48
hme-host-sample version: tivo_bcse 1.4.0.20061207
LOG: HDPhotos.init()
LOG: HD Photos Version: 1.7a1
added factory
MDNS: http://192.168.1.100:0/hdphotos/
debug: Calypso host = localhost
debug: Calypso blocking ID = null
debug: Calypso URL = http://localhost/TiVoConnect?Command=BlockUntilTerminate
debug: httpStatus code = -1, string = -1
Error contacting TiVo Desktop at http://localhost/TiVoConnect?Command=BlockUntilTerminate
No HTTP headers from server
Could not contact TiVo Desktop. Exiting.
Exiting VM. Exit code = 1
FORCING VM EXIT -- normal exit() did not complete. Exit code = 1
After the JNLP file downloads the numerous JAR files, they're available in /Library/Caches/Java/cache/tmp, so Java developers may be able to do something.

[windracer]

I was able to get the app to run through Galleon (on Linux) by copying the .jar files (ALhme-host-sample.jar, AMhme-host-sample.jar, AThme-host-sample.jar , RMhdphotos.jar, RMhme-host-sample.jar, RThdphotos.jar, and RThme-host-sample.jar) to Galleon's hme folder and then adding "com.tivo.hme.hdphotos.HDPhotos" to launcher.txt.

The app (and icon) appeared on my TiVos and I saw this in the log:
LOG: HDPhotos.init()
LOG: HD Photos Version: 1.7a1

But when I tried to select it I got the standard "Can't Read (0x50006)" error and saw this in the log:
INFO [Acceptor] AppHost - Unexpected error: java.lang.NullPointerException
I'll try messing around a bit more, but I'm guessing your assesment of needing TiVo Desktop is probably correct. How else does it know what folder to use?

[Dennis Wilkinson]

I've got it working on a Mac as a standalone. When I originally looked at this, I thought it would be too painful to do, but I've since found a way to do it without doing much at all.

First off, the HD Photos application doesn't stand alone. You see, the original TiVoConnect photo sharing protocol actually contains all the controls necessary for the server to return HD photos, and if you form your requests appropriately you can get them. All the HD Photos HME application does is call the copy of TiVo Desktop already running on your host and requests photos from it at 720p resolution.

Given that, TiVo apparently wanted to implement things such that if your copy of TiVo Deskop exits it takes the HME application with it, so they added a new command (BlockUntilTerminate) to the TiVoConnect set that blocks and never drops the connection until you exit TiVo Desktop of the caller drops it. That opens up a denial-of-service avenue (people could issue this command until the server could no longer handle new requests), so there's a handshake -- TiVo Desktop sets a blocking ID in the environment for the HME app that it then passes back to the Desktop. Only the updated Windows version of TiVo Desktop supports this command, and the HME app will exit if the command isn't supported.

Originally, I got things working by building a proxy server with PHP on Apache and a little mod_rewrite to handle the URL format. But I've since found a way (OK, "since" being about an hour ago) to just turn off the new command which seems to be working much better, although the app itself has some bugs.

Instructions

So, here's how to make this run on Mac OS X, in a nutshell. This might or might not help with Galleon.

First, you need to get a copy of the HME application itself. I don't want to just post it here, and unfortunately I couldn't convince any of the current Mac archiving tools to unpack the .exe of the prerelease TiVo Desktop 2.4 for Windows. I got mine by installing on a Windows box, then copying just the folder at C:\Program Files\TiVo\Desktop\Hme to my Mac. Let's say I put it on my own Desktop (meaning I now have a folder at ~/Desktop/Hme).

Open ~/Desktop/Hme/hdphotos.jnlp in a text editor (it's just XML). You'll see a set of <resources></resources> tags. Before the closing </resource> tag, insert the following:


<property name="com.tivo.hdphotos.title" value="Your Sharing Name" />
<property name="com.tivo.calypso.host" value="127.0.0.1:8101" />

(Perhaps) obviously, replace "Your Sharing Name" with whatever you want to see this as in Music, Photos, and More.

Then, look for this line, in the <application-desc> block:
<argument>--exitwithcalypso</argument>

and delete it. Save your changes.

Make sure TiVo Desktop is running and sharing photos on your Mac, then open up a Terminal (Applications > Utilities > Terminal) window and type the following:

javaws -Xnosplash ~/Desktop/Hme/hdphotos.jnlp

The first run will pull down all the actual .jar files, and every time you launch you'll be asked whether or not to trust the code, which you'll need to do. Then take a look in Music, Photos, etc. on your Series 3 and browse on in.

Notes and caveats:

This is wholly unsupported by TiVo! It may work for you, it may not, it may cause the world to end (but probably not ;)).
this will mirror all the photos that all the users on the machine are sharing. There's no need to run more than one copy of the HME application.
performance (on the 1GHz G4 I've tested this on) is adequate.
This probably isn't the simplest thing to make start up automagically on login, although i haven't actually tried to do that (I don't even leave it running full-time at the moment)
we've neutered the way the HME app checks to ensure that TiVo Desktop stays running by doing things this way, so if you stop TiVo Desktop, this won't stop with it until you quit it yourself
There appears to be a bug (either with the Mac Desktop or with the HME app, it's not clear) that causes all of your albums to be shown as folders inside every album in the HME app. If you have a lot of albums, this could be irritating. Just page down.
If you're running the Mac firewall, port 7288 will need to be open to TCP traffic in addition to the usual TiVo Desktop ports
I don't have an Intel-based Mac at home, so I have not tried that configuration yet, but I'd expect it to work just fine.
I have on one occasion seen TiVo Desktop exit sometime while I was testing this, although I'm not 100% positive it was triggered by the HME app or if I inadvertently nuked it.
Did I mention this was unsupported?


Getting the actual .jnlp and related files appears to be the hard part (you'd either need to have access to a Windows box or at least a friendly Windows user, barring someone figuring out how to extract things from the installer on a Mac.)

As always, I hope someone finds this useful. I'm going to sit down and watch Lost now.

[minckster]

Thanks Dennis! I found that very useful - and very easy. I can't imagine why TiVo isn't releasing (or leaking) this as a standalone HME app.

The app doesn't scale UP images to fill the TV screen's entire width or height. Does it do that from Windows? If not, I would have preferred if TiVo had built a widescreen rather than a HD photo viewer. (I just resized all of my images on the Mac side of things.)

[Dennis Wilkinson]

Thanks Dennis! I found that very useful - and very easy. I can't imagine why TiVo isn't releasing (or leaking) this as a standalone HME app.

The app doesn't scale UP images to fill the TV screen's entire width or height. Does it do that from Windows? If not, I would have preferred if TiVo had built a widescreen rather than a HD photo viewer. (I just resized all of my images on the Mac side of things.)

Hadn't noticed that -- I suppose all of my photos (well, at least those that I've looked at) are sufficiently large that they need to be scaled down to fit 1280x720 (well, slightly smaller -- TiVo seems to leave a little room for overscan, which for those of us whose HDTVs are CRT-based RPTVs is a good thing but would show up on many/most LCD/plasma sets). For portrait-oriented or squarish images there's some black to the top/bottom or to the sides, but I'd expect that, since filling the screen would crop image data.

[Dennis Wilkinson]

When I originally looked at this, I thought it would be too painful to do, but I've since found a way to do it without doing much at all.

Man, I guess I was tired when I wrote that monstrosity of a sentence... :D

What I meant to say was "My original solution would have been too complicated for most people to set up, but I've since found a way to avoid the issue I had to work around. The new solution is pretty simple to describe."

[windracer]

Galleon doesn't use the jnlp file (at least, not that I can tell). Usually you just dump the .jar files into the /hme subfolder and then update the launcher.txt file with the class.

I'm not sure how to pass those parameters (hdphotos.title and calypso.host) to the class through launcher.txt, but I'll take a stab at it. Of course, this also assumes that it will connect to Galleon's existing photo app in lieu of TiVo Desktop.

[Dennis Wilkinson]

Galleon doesn't use the jnlp file (at least, not that I can tell). Usually you just dump the .jar files into the /hme subfolder and then update the launcher.txt file with the class.

I'm not sure how to pass those parameters (hdphotos.title and calypso.host) to the class through launcher.txt, but I'll take a stab at it. Of course, this also assumes that it will connect to Galleon's existing photo app in lieu of TiVo Desktop.

Those can also be set in the environment. Use CALYPSO_HOST and HDPHOTOS_TITLE for the environment variable names.

IIRC, Galleon's photo app is an HME application and doesn't use the TiVoConnect protocol (and won't work with HD Photos as a consequence.) javaHMO uses the older protocol and may work.

[windracer]

Those can also be set in the environment. Use CALYPSO_HOST and HDPHOTOS_TITLE for the environment variable names.
:up:

IIRC, Galleon's photo app is an HME application and doesn't use the TiVoConnect protocol (and won't work with HD Photos as a consequence.) javaHMO uses the older protocol and may work.
:down:

So what you're saying is that getting this to run under Galleon (or rather, on Linux without TiVo Desktop) is probably a futile effort. :)

[Dennis Wilkinson]

So what you're saying is that getting this to run under Galleon (or rather, on Linux without TiVo Desktop) is probably a futile effort. :)

Not really -- just that in order for it to work, you'll also have to have javaHMO (Leon's pre-Galleon effort that used the original HMO protocol) running on the machine (they should be able to coexist, if memory serves.)

That said, it might be simpler to modify Galleon's photo application to support High Def.

[jtkohl]

I found that with Galleon running, hdphotos gets a Java exception due to port conflicts with mdns. If I start hdphotos first, then start Galleon, both work OK.
Last time I looked at Galleon, it included a back-rev Jmdns run-time, IIRC.

[minckster]

You can select the port that HD Photos uses. The option is at the very end of hdphotos.jnlp and initially set to 7288, which is a little odd to specify because that's the default port anyways.

[jtkohl]

even when selecting the port to be different from Galleon, I get this exception trace if Galleon is already running:


Thread javawsApplicationMain: java.net.BindException: Address already in use
java.net.PlainDatagramSocketImpl.bind0(Native Method)
java.net.PlainDatagramSocketImpl.bind(PlainDatagramSocketImp l.java:82)
java.net.DatagramSocket.bind(DatagramSocket.java:368)
java.net.MulticastSocket.<init>(MulticastSocket.java:147)
java.net.MulticastSocket.<init>(MulticastSocket.java:112)
javax.jmdns.JmDNS.openMulticastSocket(JmDNS.java:267)
javax.jmdns.JmDNS.init(JmDNS.java:235)
javax.jmdns.JmDNS.<init>(JmDNS.java:194)
com.tivo.hme.host.sample.Main.<init>(Main.java:240)
com.tivo.hme.host.sample.Main.<init>(Main.java:90)
com.tivo.hme.host.sample.Main.main(Main.java:670)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
com.sun.javaws.Launcher.executeApplication(Launcher.java:116 1)
com.sun.javaws.Launcher.executeMainClass(Launcher.java:1108)
com.sun.javaws.Launcher.continueLaunch(Launcher.java:951)
com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java: 522)
com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
com.sun.javaws.Launcher.run(Launcher.java:165)
java.lang.Thread.run(Thread.java:613)

[Dennis Wilkinson]

Sounds like the port conflict is for the port that mDNS uses for itself (5353). Not sure how to resolve that, although if that's an issue, I'm not sure how other HME applications would plug into Galleon.

[windracer]

It sounds like he's running it alongside Galleon, not through it.

[Dennis Wilkinson]

That would do it.

[jtkohl]

Yes, running galleon in one java process, hdphotos in another.

I'm pretty sure the problem is the version of javax.jmdns used by galleon.
Galleon 2.3.0 includes a different version of hme-host-sample.jar than the one downloaded by the webstart for hdphotos. Galleon gets an exception when I try to use the same copy of hme-host-sample.jar (from /Users/jtk/Library/Caches/Java/cache/javaws/http/Dcds.tivo.com.edgesuite.net/P80/DMTiVoDesktop/DMhdphotos/RMhme-host-sample.jar)


Exception in thread "JmDNS.SocketListener" java.lang.AbstractMethodError: org.lnicholls.galleon.server.TiVoListener.serviceAdded(Ljava x/jmdns/ServiceEvent;)V
at javax.jmdns.JmDNS.updateRecord(JmDNS.java:909)
at javax.jmdns.JmDNS.handleResponse(JmDNS.java:994)
at javax.jmdns.JmDNS.access$900(JmDNS.java:25)
at javax.jmdns.JmDNS$SocketListener.run(JmDNS.java:1139)
at java.lang.Thread.run(Thread.java:613)



Now the javax.jmdns included in TiVo HME SDK 1.4 is the same as what's in galleon's copy, but it's not the same as JmDNS 1.0 (downloaded from jmdns.sourceforge.net). I don't know for sure what's inside the hdphotos edition of hme-host-sample.jar, but using either the hdphotos copy of hme-host-sample.jar or jmdns.jar from sourceforge yields the same exception.

Time to get galleon updated to current software, I guess.

And TiVo: GET A NEW HME SDK READY, will ya?

[jtkohl]

I pulled down the latest Galleon from sourceforge (the latest version in CVS). It identifies itself as Galleon 2.4.0, and it seems to fix the mdns related problems. Yay!

[windracer]

But you still can't get the HD Photos app to run standalone, can you?

[jtkohl]

But you still can't get the HD Photos app to run standalone, can you?
Yes, I'm doing that just fine now. use --iface xx.xx.xx.xx as a new parameter in the .jnlp file (to select the real ethernet), and start HD photos first, or use the CVS head version of Galleon (which still needs some fixing, though, it has a few warts)

[windracer]

Ok, so I'm confused. I thought we determined that HD Photos needed to "talk" to TiVo Desktop. Are you saying that the Galleon photos app will work for that?

[jtkohl]

I dug further with Galleon this evening, and found that this addition to the run.sh script is what fixes the mDNS port in use problems:
-Djava.net.preferIPv4Stack=true

[FrodoB]

Sorry to resurrect a two-year-old thread, but I tried following the instructions for the HDPhotos app on my wife's iMac and it seems to have used VMWare Fusion's networking port instead of the actual Ethernet connection (or even the Airport's IP; yes, I have both wired and wireless IPs).

Is there any way to force the app to use the proper IP? I tried specifying --iface 192.168.2.8 but it seemed to have no effect.

[FrodoB]

Sorry to resurrect a two-year-old thread, but I tried following the instructions for the HDPhotos app on my wife's iMac and it seems to have used VMWare Fusion's networking port instead of the actual Ethernet connection (or even the Airport's IP; yes, I have both wired and wireless IPs).

Is there any way to force the app to use the proper IP? I tried specifying --iface 192.168.2.8 but it seemed to have no effect.

Apparently the parameter is named --intf; good thing I know how to read Java. :) I managed to get it to show up on the TiVo, but none of our iPhoto albums showed up properly. Oh well! We have a PS3 for a reason, I guess.... If anyone knows of a way to get iPhoto albums to work in the HD Photos app, feel free to let me know. :)

[wmcbrine]

You need an HMO server as the back end (and you need to point the app at it). For example, I've used it under Linux, with pyTivo as the HMO server. You have to configure the HMO server as usual, and make sure its photo shares appear (in SD) via the TiVo's native viewer, before you set up the HD Photos app.

BTW, re the comments above about not scaling up: That's a limitation of TiVo Desktop, not the HD Photos app. pyTivo will scale up.

[jtkohl]

If anyone knows of a way to get iPhoto albums to work in the HD Photos app, feel free to let me know. :)

Not in the HD photos app, but the Galleon photos App knows about iPhoto albums. Just used it today to look at vacation photos from the beach!