It seems to work well, many thanks.

On a completely different point (and from the "feature enhancement" point of view), I wonder if there is any way of reusing cookies for login? The login lockout seems similarly aggressive to last year but I remember from earlier times, I think from the year before, that there was a cookie involved in this which reduced the frequency of lockout when switching games.

It's a little more complicated than it sounds like it should be.

In a nutshell, each time you select a media stream, a new GameStream object gets created. The workflow in the GameStream object performs login to get the cookie and then the media location requests using that cookie, and finally a logout. Even though I do write the cookie and the session key to a file, I don't remember exactly the hindrance of re-using those files. Assuming I can't re-use those files, once your stream is over the GameStream object that has your cookie information is destroyed. Each new media selection is a new GameStream object.

In order to have some permanence to that cookie information, the login code must occur outside of the GameStream object (or allocate only one GameStream object for the life of the program which could be equally difficult.) Assume I create a Session class that handles login and logout (presumably only necessary when either the cookie expires or maybe when mlbviewer is exited.) Now the GUI (which currently is not a class of its own but maybe it should be) would have to manage the Session object and pass that object as an argument to the GameStream object each time media selection occurs. Sounds straightforward until you look at the rat's nest I've made of the code.

Short story too long...

In normal use of mlbviewer, the Sign-on Restriction Error should not be an issue. Presumably you are only performing one (maybe two) login/logout every three hours or so. It's only when things aren't working correctly that you are jumping from stream to stream more often than that. In other words, until the next time something breaks, you should be reasonably well-protected from encountering that error again just by the length of a broadcast.

From that perspective, I rate the priority of this enhancement rather low.

You do a great job in deducing the MLB.TV protocols and producing the program, so that is entirely your call.

Last season, it bit me perhaps once every two or so weeks, usually when I decided to change games once too often or if I had to change speeds by hand because the internet pipe to North America was slowing down, and occasionally when the stream dropped out more than once or twice a game and/or a combination of all three. It was an annoyance but no more than that.

The flash plugin seems to be able to reuse the cookie even between browser restarts (and so probably between boots, although I have not tested that), so it doesn't appear that MLB.TV is deliberately generating un-cachable data, say by encrypting it with different keys between logins, to further lock down usage. The trick is to figure out how to reuse the cookie, which as you say mlbviewer does still save to file. How mlbviewer organizes its code into classes, and how the lifetime of objects of those classes within the program is structured, doesn't seem too relevant to the principle of the thing (as opposed to the accomplishment thereof), since the file system is there to save any serialized data that needs to be saved. I say this with reservations because although I am an accomplished C++ and and competent javascript programmer, I know only basic python and I have tried but failed to understand mlbviewer's code.

Doesn't surprise me. It's a mess because MLB.TV changes every year. There's a lot of old crap in that code. I decided last season that I'm not interested in supporting previous seasons. So maybe this season, I'll spend some time cleaning up the code.

I'm also more of a hacker (or a hack of a hacker) than a programmer. I think I have taken maybe two programming classes in total. Everything else is just RTFM and Google. ;-)

I've noticed lately that they aren't using "HD" in the broadcast call letters as much as before so the HD indicator doesn't get lit. I guess people have come to expect broadcasts in HD that they don't have to say "Fox-HD" anymore. Let's see what happens when the season opens and normal broadcasting takes over.

If this is the case, what would you like to see in place of the "HD" indicator? Call letters? Inning e.g. T9 for top of the 9th (or "Top 9"/"Bot 9")? Have a look over the information available in the grid.xml file parsed for the listings and see if there's something you'd like added to the status bar at the bottom. I'm open to suggestions if the HD indicator is either being obsoleted or not all that useful anymore (now that supposedly every game will be broadcast in HD.)


Today's grid:
http://gdx.mlb.com/components/game/m...ay_20/grid.xml

I think it is mainly that MLB.TV is a complicated protocol. If you feel the urge to do some clean up later, a small amount of documentation on the protocols might be helpful (but not if you think it is going to cause mlb.com to take an undue interest in the program).

A couple of 2012 matters:

1. The basic MLB.TV package for 2012 now includes HD. Is that going to be available on mlbviewer when the regular season starts? (That is more of a question that a request, as I don't expect to have the bandwidth to use HD that frequently.) Having said that, from what I can tell the thing that MLB.TV calls HD on its flash plugin on pre-season games seems to be 2400K, which is a speed that you can get with mlbviewer, but presumably that might change when the regular season starts.

2. I see that REQUIREMENTS-2012.txt still says that premium users (I am not) require autobahn.jar. Is that really the case now? In any event, from my tests autobahn.jar doesn't seem to work any more. If you want to try nexdef without mlbhls, you need the nexdef.jar (the successor to autobahn.jar) which you can extract from the nexdef package for Mac OS X (it comes as a mountable hfsplus image).

I don't feel a strong urge to document how MLB.TV works because that's exactly when they decide to change it. I will answer any questions you might have about the workflow, though.

I have also done some code cleanup in the last few SVN revisions.

To your questions/concerns:

1. For basic service this year, I don't get to see what stream speeds are available until after you have decided which one you want. In prior years, all the speeds were listed in the same page as the listings (grid.xml.) This year, it's either HTTP_CLOUD_WIRED (nexdef) or FMS_CLOUD (basic) and then the response from those has the stream speeds. It would be wasteful to place the requests just to figure out what speeds are offered. That said, as long as they don't add or remove stream speeds, I should already have those speeds in the speed selector ('p' key.) If they are calling 2400 "HD", then you already have support for that. If there's going to be a new speed for basic HD, then I'll have to parse a FMS_CLOUD response after the season gets going to see what that new speed is. That's a trivial investigation/edit though.

2. This is why I don't like documenting MLB.TV. I can't just re-use a README/REQUIREMENTS-20xx.txt from one year to the next. You are correct. Use mlbhls. I will probably make that automatic rather than an option (use_mlbhd=1 currently) and deprecate the old autobahn.jar method. Generally the README and REQUIREMENTS files are the last to get updated each season. I'm also not convinced that Opening Day won't bring more changes. Right now, so far so good. I'm in a holding pattern until May waiting to see that the bulk of development (both on MLB's side and my own) has been completed. That's when I update the documentation and make sure Sourceforge download link gets a tarball that doesn't need to be actively updated via SVN.

On a related note, I also need to update the test directory tools and get mlbplay working again. mlbplay is meant to be a reference design tool showing how to use the MLBviewer procedures without having to get caught up in how the curses gui of mlbviewer.py works.

Anyone still using autobahn.jar? I don't think it works. I haven't tested it in ages. mlbhls is a superior solution. I'd like to remove all the code surrounding the former nexdef implementation known as autobahn.jar.

If this breaks something for someone, speak up and I'll restore it from a prior SVN revision.

As of this revision, I have removed all procedures related to autobahn.jar. So for premium users wishing to have "nexdef" functionality, you need to download mlbhls:

If you have already done this, you should update to the latest mlbhls revision to gain start timecode support.

Why would you want this?

Because with the ability to start from a particular timecode, mlbviewer can now jump to an inning using the 'i' screen for nexdef.

Basic service users: you already had this functionality. If you didn't know that, now you do.

So for right now, if you're tired of waiting for archived nexdef games to start because they sit on that "Please wait" MLB.TV screen for too long, you can now use the inning screen to jump to the top of the 1st (press 'i' in the main listings, then 't1' when asked which half inning to jump to.)

I don't want to make this automatic when you select a stream because sometimes you want to see the few minutes of pre-game (or at least I do.) So when my Sign-On Restriction wears off (grr!), I will look into how to find the pre-game timecode.

I did a lot of code cleanup in the last few revisions including removing procedures and variables I no longer use. Please update to this revision even if you're just a basic service subscriber and verify that I didn't break anything with my code cleanup.

Also mlbplay should be working again but I don't have the same smart stream selection in mlbplay that I do in mlbviewer. But anyone wanting to see how to use the MLBviewer API's, you can now refer to mlbplay knowing that, at least for broadcasts that are available, that code works, it is commented, and it doesn't have curses ugliness to read through.

Perhaps there could be a default start of, say, 8 minutes before first pitch on an archived game?

When starting mlbhls (but not when starting the standard stream), mlbviewer fails with:

"Traceback (most recent call last):
File "./mlbviewer.py", line 1619, in <module>
curses.wrapper(mainloop, mycfg.data)
File "/usr/lib/python2.6/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
File "./mlbviewer.py", line 1437, in mainloop
if g.current_encoding is not None:
AttributeError: GameStream instance has no attribute 'current_encoding'"

However, mlbhls still starts OK, and works well if I use fixed bit rate (the new automatically adjusting bit rate doesn't seem to work for me).

On another minor matter, line 1564 of mlbviewer.py sets a default max_bps of 800000, and so does the __init__ method of GameStream in mlbtv.py. These probably ought to be a default of 1200000 now, as 800000 no longer exists it appears.

1. I have code written but unfortunately cannot test remotely from work other than to say that it doesn't explode. For archived games, not using the inning selection screen, I will store the start_time from the grid.xml (listings) before converting it to local time for display in mlbviewer. Selecting an mlbhls archived game through Enter (rather than innings) will use this timecode. You may miss some pre-game but it's better than what we've got now. I can experiment with rounding down to the nearest half hour to see if that gets all the pre-game. When I get home tonight, I'll test out the new code watching the actual streams and not just verifying mlbhls was started with the right timecode. I should have that checked in to SVN later tonight.

2. Yep. That's an artifact of the old autobahn.jar code. Guess I didn't catch it all. Back in the day, we could poll the autobahn.jar which acted as a http proxy for the stream for information about the stream being played as well as other streams available, and even dynamically select a new stream speed. Fixed and will come with tonight's check in.

3. Part of the code cleanup is removing all traces of autobahn.jar and moving all mlbhls related stuff to a single procedure (prepareHlsCmd.) Good catch. That is a default but you can override it with the config file option of the same name. I will fix this with tonight's check in.

4. I will do some experimentation with the new bitrate features in mlbhls and figure out how best to support them through config file and prepareHlsCmd. It was working well in the last mlbhls svn but it wasn't working last night with inning selection. I did not test for very long. Not sure if this will go in tonight or this weekend. Depends on how many tests I get in before they decide to sign-on restrict me.

5. I will be looking into moving the login/cookie/session key code out of disposable objects like GameStream. I think they are indeed more aggressive this year than in prior years.

There are two ways I can determine the start timecode for an archived nexdef game:

1. Take the start_time from the event listing from the grid.xml file that builds the listings.

2. Take the start_time from the innings.xml file (even if you don't select the innings screen.)

To limit the number of requests I make, I chose the first approach. I can tweak this later and experiment with the second approach.

And hey, the first condensed game was available yesterday along with top plays. Mlbviewer handled both without having to change any code.

This weekend I will add the lock bitrate support for mlbhls through a config file option. I kinda like the variable bitrate support because it seems to keep the game playing even when it might stall out at the higher rate. But I'll put the option in for those who really want to lock down a bit rate. I'll also add min_bps support so if you are going to let it dynamically adjust, you can say, "please don't give me the 100K stream."

"current_encoding" bug fixed. More unnecessary code removed.

Given the two approaches to find the start timecode for an archived nexdef game, I have decided to try fetching it first from the innings.xml file. Even if you are not selecting the game from the innings screen, there is a start_time that is different from both listing time and top of the 1st. If that request should fail, mlbviewer will fallback to using the start_time from the listings.

Been busy this afternoon...

I added min_bps config file option to specify the minimum bps stream to use for mlbhls. (Default: 500000)

I reused strict_stream config file option from seasons' past to disable adaptive bitrate in mlbhls.

I have made these mutually exclusive.

If you specify strict_stream=1 in your config file, mlbhls is started with -L -s <max_bps> (start at the max and don't adjust.)

Otherwise, it is started with -m <min_bps> -b <max_bps> (adjust as necessary between min and max values.)

Those of you who have been using mlbviewer for a few years might want to check your config file and see if strict_stream and max_bps have been there since the old autobahn.jar days. I believe the new streams go as low as 100000 (100K) and as high as 4500000 (4500K).

Once again, I'm under sign-on restriction lockdown but I'm reasonably certain these edits do what they should. Perhaps the lockdown will be lifted when I get home in a few hours. Which leaves my high priority task for the weekend: single sign-on to avoid future lockdowns.

Test away and report back to me.