is this normal? I usually just open autobahn via right-click and "open with java 6". Is there a difference between your way and mine?

Yeah, I've boon keeping any eye on that too. I'm not sure what I can do to help things along, though. The last thing I want to do is "bump" it, lol.

That error is probably caused by the fact that you are already running it "invisibly" through the desktop right-click method. autobahn opens a local port and I'm pretty sure you're getting that error because the port is already opened by another instance of java. Do 'killall java' and try it again.

I like the sounds of this.

Is it possible to simply use mlblistings.py as a prerequisite for an XBMC plugin? I know most XBMC plugins are "standalone" and I have no idea how they're written, but I was thinking that since mlbviewer is already in python, it might be possible to "piggyback" on it, and have a working installation of mlbviewer as a prereq for the XBMC plugin.

You need to copy the MediaService.wsdl and MediaService.xsd files to your ~/.mlb directory.

and restart mlbviewer.

You basically need the following pieces of information for requesting a game:

1. authentication, both in form of cookies and actually providing username and password - we do this both through the old authentication page and through SOAP

2. event-id which identifies a game and is the number like 14-23456-2009-05-05

3. content-id, a six digit number that identifies a particular media feed such as home audio, away audio, home video, and away video

4. playback-scenario, a string that says what kind of media stream you want like MLB_FLASH_800K_STREAM (highest quality non-NexDef) or MLB_FLASH_SWARMCLOUD (NexDef)

You have to take all these pieces of information and generate a SOAP request to their application servers to get the media URL.

For non-NexDef users, the media URL will be an RTMP URL which needs to be parsed to build the correct ActionScript messsages (play/createStream/FCSubscribe, etc.)

For NexDef users, you'll get a media URL which is a base64 encoded URL that is passed to the NexDef plugin (autobahn.jar) in a content description request. This URL has content-id, event-id, and a session-key encoded into the query-string of the URL. The autobahn.jar makes a request to that URL to get Swarmcast information about streams available. In the actual content request, you can either give NexDef a max_bps parameter and let it choose the best stream available (recommended) or you can make a request for a specific stream (which may or may not work if either the stream is not available or your system/network can't handle it.) The result of this request is the media stream.

At a minimum, even for non-NexDef use, you will need:

XML - no way around this - for parsing the Media Grid to get the event-id's and content-id's

SOAP - I suppose you could try to build your own SOAP requests using just XML but that would be very painful when Suds makes it so easy

If you are using non-NexDef, you'll need flexible support for the RTMP parameters like playPath but you'll also need a patch to specify an FCSubscribe Invoke message for live streams. This patch exists for rtmpdump but the developer still isn't certain how he wants to take the patch or if he wants to figure out his own way to support flexible Invoke messages, of which FCSubcribe would be one.

If you are using NexDef, you would need the autobahn.jar file, java 1.4.1 or higher, and the XML and SOAP would be enough (though the amount of messaging and additional GUI screens you may want to develop could increase depending on how much NexDef functionality you want to support.)

Probably by month's end, I'll have a non-NexDef stream downloader using rtmpdump and flexible command-line support.

I want it to go something like:

And the result would be like a smarter version of the test scripts that actually use the MLBviewer library. This could then either be a reference script for developers like yourself to figure out how to build MLBviewer (the python library) applications or you could wrap your own code around get_mlb_basic to call it directly.

Trust me, if there was a way to reduce the minimum requirements... I would not have purposely designed something this complex if I had a choice to go a simpler route.

To answer your question more succinctly, everything I know that they expose can be found in mostly XML (with the occasional JSON file) in a directory built out of the date like:


http://gdx.mlb.com/components/game/mlb/year_2009/month_04/day_30/


I use grid.xml to create the listings and to find event-id, content-id, and coverage information (home vs. away and call letters.)

There isn't a simple url to request with a media ID as a query string like last year.**

**Except if you only want to support NexDef video (but not non-Premium video and not Gameday Audio), there is a way to build the NexDef URL's with only the information contained within the grid.xml and a couple of web requests (authentication and a page to get a session-key.) You might be able to search this thread for posts from CubsFanUK for more information on how to build these URL's. But you are really only saving yourself one SOAP request so it's a lot of bother for such a little payoff.

Two reasons why I am checking in this code:

1. I want to have a checkpoint to revert to when I start layering on top of the nexdef_control() action code. In prior revisions, I only supported an action of 'ping'. Now for stream switching, I support an action of 'select'. For the upcoming jump to innings interface, I'll support an action of 'jump'. I want to have defined points of "this revision worked" before bungling the code up.

2. I wanted an easy way to grab my stream switching code to test at work where I don't have rtmpdump but I can probably get away with listening to a 164K NexDef stream.

So you are possibly getting immature code if you update to 194. On the other hand, what would mlbviewer be without its testers? So, if you want to try selecting specific streams, here you go.

On the current stream screen, I give you a number menu to select alternate streams using the number keys. Some stream transitions are smoother than others. For example, going between 1200 and 2200 works fairly reliably for me. 3000K rarely works for me but then when I finally got a 3000K stream, I realized it's a bit too much for my system. To jump to lower streams (e.g. sneak an audio stream into work without messing with rtmpdump or getting the IT guys up in arms about bandwidth consumption), switching down to 164K first and then using that as a springboard for 400 or 600 seems to work better than going directly to 400 or 600. Of course, this is all just my testing and your results may vary. That's what I'm counting on.

If you test this, let me know how well it works for you and which transitions work better than others if you have any problems switching between streams.

Cool! I found and fixed a blind spot bug already.

By the way, the streams available screen is filtered based on your max_bps parameter. If you say (like I do at work) that your max_bps is 800000 (800K), then only the streams up to and including 800K will show in your selection screen. If you want access to all streams, set your max_bps to 3000000 (3 million) and then choose the stream you like best from the stream selection menu.

I now have a mlb.tv premium account. I also followed all the instructions for upgrading mplayer.
Audio is working fine and it's nice being able to toggle home and away and "q" works; thanks!!!
When I hit enter on a game after having starting autobahn.jar, I get:
Exception: Could not parse NexDef stream list.
Try alternate coverage.

There is of course more to this message but i'm not surehow to put it on the forum because I'm running mlbviewer in a console and using Orca and gnome on the forum site because it doesn't work so well in lynx in console and I haven't figured out a way to paste these errors in for you. I saw some similar ones but I think the person with those errors was trying to record rather than play. If anybody has an idea what might be wrong just from this part of the message, please reply; otherwise I'll try to find a way to put the rest into my post and send it later.

Thanks to you and Theophile for you suggestions.

I tried -really-quiet, but that just made "reading from stdin go away", still no audio.

My current config is

I was surprised that the counter in the terminal still stopped at 64k.

It used to work, in spring training, with

I also tried it today without the -playlist and without -xterm -e.

Anyway, I'm at wits end; the flash streams won't stay up and I just want to chill out and listen, or even, gasp, watch, and not have to babysit the computer.

Are you using the sourceforge release or an SVN revision?

If you are using svn, can you tell me which SVN revision you are using with the 'svn info' command?

From the code, if I had to venture a guess, I'd say one of two possibilities:

1) The game just isn't available (like a rained out game)
2) MLB.com hasn't yet upgraded your account on their swarmcast servers to reflect your new status.

Try a couple of things:

If you newly upgraded to Premium, you may be using old cookies/sessionkeys from before your service upgrade.

Normally, I'd ask you to also try the nexdef.py tool in the test directory but that might drive you crazy with Orca. There's an enormous amount of output in that script but it would tell me a lot.

If you want to give it a shot, try it with the following event-id:

That's the CWS-KC game that I'm currently watching so I know it's good.

If you are trying to watch the Yankees Boston game, it sounds like there are problems with the NexDef streams as reported on the Official MLB.com support forum.

xterm -e won't work anymore for audio because I stream rtmpdump output directly into mplayer input.

Oooh! I see your error. Remove -playlist.

That worked with spring training and that worked last year but it's not going to work this year. In fact, consider spring training an extension of last year's code. There was a huge overhaul done in April to get mlbviewer to work with all the changes they made to their service. If you haven't patched rtmpdump with the Patch.sh in rtmpdump-patches and rtmpdump version 1.5 (not tested with any other version), you won't be able to listen to live games.

At some point when this year's code is nice and stable and I've finished adding in the features I have planned, I'll go back and write some compatibility code to make sure it works with last year too (including automatically stripping -playlist from your audio command.)

But for now, removing -playlist SHOULD do the trick.

As for the counter, the rtmpdump counter, that's the counter you are watching, will freeze momentarily after it fills mplayer's buffer. When mplayer begins playback, it will begin to empty its buffer. When this happens, mplayer will "train" rtmpdump to go much slower than it would prefer. But, this is a good thing. Apparently, asking rtmpdump to pull the stream at human speeds allows rtmpdump to download a stream in its entirety. Whereas letting rtmpdump download full-blast (e.g. not limited by mplayer's playback buffers) results in partial downloads and timeouts. So yes, you'll see the counter freeze momentarily and then begin again in spurts until it finally reaches a happy speed where it is downloading as fast as mplayer is playing.

Stream switching works like a champ on Windows with Applian FLV Player and mlbviewer under cygwin. I can't wait to test this at home where I don't have to self-impose bandwidth limits.

I've added another fix or two and a cosmetic improvement so r196 should be used to test stream switching for NexDef users.

It is so nice to be able to watch theses games now on my 47 inch HD monitor without needing flash player and all the freezing and jumping that comes with it. If MLB were smart, they'd hire a couple of you guys in order to present their product to us. Their loss and our gain.

Thanks for what you've done and for putting up with me so patiently, all of you.

I told you most Linux people are sophisticated, didn't I?