I forgot to mention, you have to enter

http://www.mlb.com/enterworkflow.do?...mediaId=636860

first, and then enter

https://secure.mlb.com/authenticate....sword=PASSWORD

Now that you are logged in you can switch the game as much as you want. I don't know why you have to enter the game url first, but thats how it works.

Since I don't know much about python, i just set it up to run a long loop. I log in at the beginning, and then every time I want to switch the game I enter the game url.

It is kind of sloppy now, because I don't know much programming. But I just have my python script running on a server. I ssh into that server, send a command for a game I want. The python program makes an .asx file and posts it to the webserver. Then I click on the link on my phone.

It would be nice to get this all done with php, and not have to worry about ssh.

Well, that's basically what the script does now, though perhaps in a slightly more indirect fashion. If we just used the second url, we could probably get rid of clientform, which would be cool. But it would be putting your password out there in open network traffic.

This still doesn't get rid of the problem of multiple logins, though. The second url will still require some sort of logout, which is what daftcat was discussing. The other thing is that this approach, at the moment, logs in every time, regardless of whether you're already logged in. At the moment, the script checks whether the first url above returns a login page or a game page, and proceeds accordingly.

So the essential issues -- which I think daftcat said he was going to try work on this weekend -- would still remain. But (and thank you for this) this might give us a way to get rid of another dependency. No need to parse the login form every time, since it will always be giving us exactly the same output.

(Really, whatever it is that urllib2 sends from clientform could be completely canned, since it's going to be exactly the same login info every time... right?)

My thought is to hit the login page directly first instead of the workflow page first. Login first and then hit the workflow page. Testing in firefox, this takes us directly to the page with the stream id's. Once we get the game url, immediately logout before connecting to the stream. I know this will work because I used to firebug on one machine and play the stream from another.

The other thought I had is to improve the code I put into mlbviewer-dbg to parse the web page returned when url() fails and add an informative error message to an error_str member variable of Gamestream. That way if the interface module try:'s and fails, it can retrieve the error_str from the Gamestream object and create a meaningful interface error (instead of the beta message.)

Sounds good. I guess it's still just a question, though, of how to make the server believe the logout method, wherever it occurs.

As for the error message, one of my next to-dos is to write a meaningful URLError exception class, that gives the meaningful info of the page it go instead of the page with the mms on it. The dbg version does this, but it gives the whole wrong page. The more it could parse it down to the meaningful bits, the better.

Oh, and daftcat, check your email.

jkr

Oh so very close now! :-)

I downloaded HTTP Analyzer (it's a trial version so we have to figure this out in 15 days ;-) and I've been logging in via Firefox using the Login link at the top. I then enter the workflow url with the game ID from the listings page. I've been looking over the POST requests in HTTP Analyzer. Very cool tool!

Here's what I have now:

1. Visit the login/registration wizard page. This page sets a session cookie. Mmmm! Cookies!
2. Make a POST request to authenticate.do with that cookie, email, pass, plus a couple of hidden fields.
3. Visit the workflow page with the game ID and get the mms:// url.
4. Logout using the same session cookie.

This is all done without ClientForm. :-)

Some other things I do is I make sure I set the User-Agent (Firefox on Windows :-) and Referer headers in my requests.

It seems to be working very well right now. I'm also saving the cookie to disk. I doubt this makes any difference but it might be useful for debugging at some point.

So far, this is all in a single flat file apart from the mlbviewer source.

I'm going to go do a happy dance, take a shower, and get out of the house for a few hours. When I come back, I'll work on merging the new code. I'm going to merge it into mlbviewer.py first since that's what everyone is using right now. We can let people give it a whirl for awhile and if we don't hear of any more problems, we can merge it into the new code base.

Sounds good?

P.S. Since I do have a Windows machine, I can at some point do a HTTP Analyzer on how the normal work flow looks with Firefox and Flash. If it's any different, I can modify our code. My goal is to have mlbviewer.py look no different from the normal methods from a network standpoint. That way we can either fly under their radar and/or not ruffle any feathers.

Sounds f'in awesome, is how it sounds. I think I can safely say thanks from everyone here.

And yeah, I agree making it indistinguishable from a Windows login would be great.

Once you get it merged into the old code, getting it merged into the new codebase will be a snap, since GameStream is exactly the same, just in a different place. In fact, if you want, I'll take care of merging it in, if you send me a diff on the old mlbviewer.

As for testing -- I think the old concurrent problem would lock you out after either three or four live games in a row. So I guess that's what we have to do. Lots of bits and pieces of games. Have you all been wondering about who the Twins number 4 starter is? Curious about how the Giants will blow another strong starting performance with a 9th-inning meltdown? Now's your chance.

Thanks again, man.

This is very frustrating!

My single file script which takes a gameid as the argument works every single time!

Merging the same code into mlbviewer is giving me the concurrent login error.

It's the same machine! :-(

It's the same code. Grrr!

I did something really ugly too. I combined login, getInfo, and logout into a single (very long) getInfo method. I have no idea how handlers and cookies and all that work across method calls so I decided to keep it simple for now and get it working in the monolithic routine.

Unfortunately, there are no live games left today so I can't do any more testing until tomorrow.

Good news is that login, session cookies, logout, it all looks okay. I implemented a log file, a cookie file, and some rudimentary debug support. I also implemented the error reporting that I mentioned earlier where GameStream can detect what kind of error it's receiving and set the member variable, error_str. When the "gui" receives an error in g.url(), it can relay that to the user by writing g.error_str to the screen. However, because I've combined everything now, I don't have a separate logout() function anymore. Ideally, we shouldn't need a separate logout function if the monolith works correctly. When the monolith is working correctly, I can experiment with moving it back to separate methods. I have comments to show where the method breaks would occur.

Anyway, I can print the gameid in the log file and we can release the gameid script as a debug tool (and a workaround since it never runs into the concurrency issue.) That way if I don't figure out why gameid script works yet the merged code doesn't always work, folks can still watch their live games using the gameid script. It would be an extra step to check the log for the gameid but it's better than waiting for the ban to be lifted or the game to archive.

To look more like Windows, we should probably set the Referrer when we hit the workflow page. This might also be the root of our concurrent login problems (though my mlblogin script doesn't have any problems so that's probably not the issue.) We can get all the info we need to set the Referrer from the TV listing.

Here's a TV listing:

And here's a sample Referrer URL for the workflow page using regular Firefox method:

http://mlb.mlb.com/media/player/mp_t...00&cid=mlb&v=3

I don't really understand the json code so I'm not going to mess with that. cid is the only one that doesn't appear in the listing but it's set to 'mlb' so that's probably what it's always set to.

Sounds like it's headed in the right direction. If you hit a wall, send me a copy of the mlblogin script and your hacked mlbviewer, and I'll see if a fresh pair of eyes can figure out what's going on differently there. I should be able to get a chance to look at it some time this evening.

Ultimately, we should aim to re-separate the monolithic function, once it's working, because that will allow the libraries to be as general as possible, as opposed to being wed to this one task. But getting it working does seem to be the first priority.

Hey guys,

First of all, just wanted to give huge props to everybody on this thread, especially jkr and daftcat for the great python script. Messing around with umpteen layers of bloated MLB flash to get to the product I paid for has bugged the heck out of me for years now. I'm almost glad that this year they screwed it up so badly that smart guys like you had to find a workaround. Now, with mlbplayer.py and mplayer, I'm watching the Cubs on my OLPC XO!

An observation that may or may not help: I can watch archived games, even though I've only paid for Gameday audio. I guess MLB figures it's a teaser to buy the TV package for live games. I assume MLB just takes care of that in their permissions db, so I don't imagine it'll affect you guys' trouble with the authentication. Still though, interesting, and it means that anybody who only bought audio should be able to use your script.

Also, I just wanted to cast my vote for a development plan: I would love the script (or even a different one) to work for audio. I think you guys are definitely on the right track getting the engine solid before worrying about extra features, even though we can all imagine a zillion great ones -- I for one would much rather have a dead simple interface to a working audio and video feed than any splash screens, guis, etc.

Thanks again, and keep up the great work! In the unlikely event that I see anything you guys have done that I might improve, I'll be sure to send in a patch.

I'm going let jkr develop the audio feature--at least initially. ;-)

Here's what needs to change for audio:

1. We need to parse all four audio feed listings.

2. We need to a way to select which listing since they are all speed=12. This fact might be useful to differentiate audio from video, though.

3. We need to change the workflow url slightly from catCode=mlb_lg to catCode=mlb_ga

4. We need to make "gui" modifications to support audio.

For listings, I'm thinking we should make a listings object available to GameStream so that we can easily build the correct Referrer header for the workflow url. Perhaps the "gui" can pass a partial game dictionary that includes just the entries for the stream to be selected. I'll let jkr come up with a working model for how this can work. I'll provide input once I see it.

I tried something awhile back for audio but I don't remember how far I got. Basically, I don't understand the json (listings) code very well so I'd rather stay out of it for now.

I'm off to yoga to undo all the sitting and coding my body has endured.... :-)

But as a teaser, I haven't run into concurrency issues yet today (but the day is still young.)

I wanted to really exercise the code so I started up several instances and created my own Mosaic without any problems (except the screen capture had a problem grabbing one screen and there wasn't enough live games at the time so #2 is an archived game.)

http://www.eds.org/~straycat/mlbviewer-mosaic.jpg

Yeah, this is on windows under cygwin but I haven't figured out how to get Linux to share the screen with more than one instance. That's okay. It's not really practical for my particular setup.

Quick question (I can Google it when I get back):

Tcl has a parray procedure that prints the elements and values of an array. Is there an equivalent function for python to print the structure and values of a dictionary?

This would greatly increase my understanding of the listings code.

Looking good. My sense is that, simultaneous or not, if you can open and close more than 3 live games in a row in rapid succession (watch a pitch and then move on to the next) then we have this thing licked.

Chances are that yesterday's errors might have had something to do with whatever testing you'd been doing earlier in the day.

We can take care of breaking down the monolithic method into smaller ones when it's merged into the new code, but that will require testing of its own.

I am curious about the cookie, though: do you erase the lwp cookie jar file at the end of a session? If so, what do you do in the result of an unclean exit?

Unfortunately I don't know Tcl, so I don't know exactly what this does. In python, though, it's quite easy to examine a data structure using the interactive console (I recommend ipython since it has tab completion). Maybe I'm not understanding your question properly. But if you open up a python console, import mlbviewer, and initialize an MLBSchedule object, you can then just print it, print individual elements, and drill down into it to your heart's content.

But am I misunderstanding your question?

These are all trivial except for #4. I'll be putting them into the new code in svn sometime in the next day or so. The issue will still be what to do with the data (how to present it) once it's in trim list, though.