Fixed a few issues with unicode characters in some of the menus. Also updated the stream quality selector; it used to only let you choose from 3 levels but there are actually (at least) 6 in use: H264 Medium, 650K, and 400K, and Flash High, Medium and Low. H264 Medium is a 1Mbit stream and is the highest quality they offer now. They don't encode in Flash High any more (700kbit VP6) but there are still some old shows on their site that use it. Generally on new shows now I only see the 3 H264 streams and Flash Medium. It's been a long time since I've seen a stream using Flash Low.

Looks like I'll be setting up a new github repo or something for this soon.

I tried to make this usable on Xbox and current XBMC builds in general. I delegated calls to Crypto libs to an Ubuntu machine using Pyro and used the RTMP proxy described in http://forum.xbmc.org/showthread.php?tid=71532 to get the streams displayed.
This almost works, but somehow it seems XBMC is not keeping the HTTP connection open so the proxy kills the connection. Anyhow I packed this up in a zip for everybody to try and maybe improve.

To get it running on Ubuntu 9.10:

1. Unzip the archive. Put "Hulu" into your video plugin folder. Edit line 220 in stream_hulu.py to point to the server running the RTMP proxy.

2. Install the packaged Pyro: sudo aptitude install pyro

3. Run the Pyro nameserver: pyro-ns -n [your_ip] -p 9090

4. Go to "Hulu_Pyro_Client" and run it: python hulu_pyro_client.py

5. Run the rtmp proxy: perl rtmp_proxy.pl

6. Run XBMC and select a stream through the plugin.

With a bit of luck you should see the first pictures appear. Then XBMC somehow seems to drop the HTTP connection causing the proxy to terminate the streaming fork. Maybe somebody has an idea why this happens and how to work around it.

well not really. I can stream from rtmpgw with vlc, xbmc runs into a timeout when trying to stream via http, though. I would need to investigate how the timeout for http connections can be increased.
All the hard work was done by highlandsun though and he has proposed patches to the rtmp part of xbmc. Once those land in the real build it should work and if the patch is ported to xbox it might even work there.

BrokenCodes Wrote:There is a problem with hulu streams skipping forward and back randomly by 30 seconds. It appears, that they made a few changes when they went to the new CDN.

Hm, I've seen that happening too. Have you noticed it on any other RTMP streams? My suspicion was that it's a bug in XBMC's stream cache but I haven't dug too deep into it yet. Pretty sure it's not in librtmp since rtmpdump still saves the streams properly. (Which also implies it's not anything that hulu is doing on their end.)

Hm, pretty sure those two patches are not related to this. I just saw a skip happen using ffplay too. The skip didn't happen at the commercial break, it was sometime later. But this kinda implies that the problem is in librtmp after all. I'm doing another test with mplayer -dumpstream now to see if it saves a corrupted file or not.

edit: mplayer -dumpstream also loses a packet after ~51MB have gone by. But it only loses it when librtmp is built with GnuTLS. With OpenSSL the file is not corrupted. So apparently there's a bug in GnuTLS's RC4 cipher.

finally I have something that works on XBox (using a January t3ch build). I use rtmpdump to write to the harddisk and play from Samba. The timeout settings didn't help sadly. I really don't like current approach too much, but it works for me.

You need a linux machine with rtmpdump in "/usr/bin". I use Ubuntu 9.10.

1. Unzip the archive. Edit line 239 in stream_hulu.py to point to the smb share holding the output file. Put "xbmc-hulu" into your video plugin folder on Xbox.

5. Go to "Hulu_Pyro_Client". Edit line 91 to point the output path to a folder shared through smb. Edit line 94 with your Linux machine's IP address so the pyro client will not bind to localhost. Then run it: python hulu_pyro_client.py

6. Run XBMC and select a stream through the plugin. It takes some time to launch a stream as I let rtmpdump build up a buffer before opening the file.

Currently I only have luck with the RSS feeds. Haven't checked for a new version by highlandsun lately.

highlandsun Wrote:Hm, pretty sure those two patches are not related to this. I just saw a skip happen using ffplay too. The skip didn't happen at the commercial break, it was sometime later. But this kinda implies that the problem is in librtmp after all. I'm doing another test with mplayer -dumpstream now to see if it saves a corrupted file or not.

edit: mplayer -dumpstream also loses a packet after ~51MB have gone by. But it only loses it when librtmp is built with GnuTLS. With OpenSSL the file is not corrupted. So apparently there's a bug in GnuTLS's RC4 cipher.

I don't get the same results.
I am however able to get good results, if I use the rtmpsuck.