Okay, the version of MLBSchedule in svn now pulls down audio as well. How to deal with it is its own question, but here's a sample entry in trimList().

Two other things. Note that the time is now a datetime object. It's still not timzone aware, but this is the first step to being able to give times based on the user's computer (or explicit preferences).

Also note also that this method has been renamed trimList() from trimTVList(), since it no longer is just tv. All of these changes take place inside the class, though, so they don't matter to the actual interface.

FOLLOW-UP: I've written (though not yet committed) a proof-of-concept version that plays video in mplayer if you press return, home audio (chosen arbitrarily) in xmms if you press a. Unfortunately, I'm waiting for the latest concurrent ban to wear off before I can properly test it.

Daftcat, the sooner you can merge your new code in, the better.

Oh -- and one more thought on the interface to audio. I would strongly recommend not overloading the interface with options. Here's my suggestion, which I think offers the right balance of simplicity and flexibility:

1. In general, have the preferred audio stream be like video speed, in the configuration. Always home, or always alternate_away or whatever.

2. Have an optional list of teams that it follows. That is, I could have:

That would tell it that if the Giants or the A's are at home, it should play the home stream, and if they are on the road, it should play the away stream.

This could be finessed a bit, and it would keep the interface more user-friendly.

Here's an example of parray:

Basically, if I knew the name of the array (these are dictionaries in python), but not the elements (e.g. blue, green, red), I would have a hard time looking up a value. Except there's two routines to help me out. One is array names which gives me the element names. The other is parray which just prints it all out for me. It seems that dictionaries can be multi-dimensional so drilling down might not be quite so intuitive unless I knew the element names, or could find out how many names there are. Heck, I don't even know the command to find how many elements there are in a dictionary to do a for loop. I'm a little more than a week old with python. ;-)

(Doesn't that make you feel more comfortable with the code I'm contributing? ;-)

My thought is to have a play audio and maybe 'f' to toggle which feed to choose from which would be displayed in the statusline. Why don't you get initial code to support the always and follow options and I'll leverage that to add in toggles and statusline support.

Ah, I see.

If you're dealing with a dictionary d:

d.keys()

will give you a list of the keys.

So, in your example, colors.keys() = ['blue', 'red', 'green']

And colors.values() = ['sky', 'apple', 'money']

If you want to know how many, just len(colors).

Also, iterations on the dictionary will treat it like a list of its keys.

So:
will give you

blue SKY
green MONEY
red APPLE

This also works for comprehensions, which are just a sort of optimized iterations:

outputs

['sky', 'apple']

Edit: that all being said, explicitly iterating over colors.keys() (which to the best of my knowledge has the exact same effect) will make it easier for someone reading your code to remember what they're dealing with. But it seems to often be left out, and I'm certainly guilty of that as well.

As for cookie support, I'm thinking about creating a new cookie jar each time gamestream is instantiated, but I'll load cookies from the cookie files. There are several cookies that don't contain the discard flag but the session one does.

The concurrency issue seems to be a different session key between authentication and workflow. I don't know how that happens. I'm wondering if I can save each session key in different jars so that if I get the error, I can try a logout with both session keys.

Incidentally, I think the error message might be a rouge. Well, I mean, it has to be since 1) it's not separate machines, and 2) one piece of code works flawlessly while the other doesn't. I'm going spend a little more time cleaning up the code and look at ways to handle the cookies and also see if I can't split it back up into separate functions again. I'll send the code to you later tonight or tomorrow morning. I'll also send you the gameid script so that if it's not licked, we have a workaround.

One more python tip:

Generally, iterating over the number of elements in something is considered "un-pythonic", as the clumsy syntax suggests:

Preferred is:

Now, sometimes you will have to do the first version, when you need to deal with list indexes, say if you only want to print every 3rd element in a list or something. But since dictionaries aren't ordered, there would almost never be a reason to iterate over the number of their elements.

So the jsp listing is nested which would suggest dictionaries within dictionaries. Is that how it is in the listings? If I wanted wid: from the 400k stream would it be dict['mlbtv']['400']['wid'] ? I guess I can walk it later. I'm finishing up my lunch so I'm about to dive back into my code with renewed vigor.

I'll be adding debug keybindings later such as 'd' enables/disables them and then 'c' would show the cookies, 'l' might trigger a login for testing purposes. These come later. I'll get the network code as solid as I can so we can get back to one code base again. One of the things I like about OOP is the persistence of state and data which makes it easy to peer into the objects with the right member functions. But I want to keep debugging "hidden" by default so it doesn't get in the way.

Yep, exactly. Note that what it pulls down is weird, sometimes there are lists with only one element and so on. So you'll have to do

dict['mlbtv']['something'][0]['somethingelse']

I decided not to clean up the JSP itself in getListings(), because that could make problems harder to find. So making it into an easy-to-use format all takes place in the trimList (nee trimTVList) part.

Well, I'm out of live games for the day. I'll just be putting some spit and polish on it later tonight. I implemented a help screen and separated the monolith back out to functions. For the cookies, I write whatever gooey morsels that stick (e.g. discard is not set) to the disk. Everything else I clear each time we log out. Each time login is called, we use a new jar and load in the other cookie bits from the disk file. I was actually getting the concurrency issue a lot last night by trying to pull the next day's games. The gameid script by contrast would just return a null url from the workflow page. You asked what happens to cookies when workflow is unsuccessful? Well, because the page access is never unsuccessful, e.g., I'm always able to login, hit the workflow page, and logout, it's really the parsing of the url from workflow() (I renamed gameInfo()). So we'll always do login, workflow, logout. It's only the parsing of the page returned by workflow that can generate an error. In url, I have several exception handlers for null url (game not available yet), concurrency error, and blackout. Even if the user doesn't set blackout or sets it wrong (like I forgot to include oak), or it's a national blackout like the Sox v. Yankees tonight, url() can detect the blackout message returned from the workflow.

I'll send you an email tonight with the link to my copies of mlbviewer and gameid. I want to run some more tests tonight on tomorrow's games to see if I can get the two scripts behaving the same way. I also just re-enabled the try:/except: in the "gui" code and other than "blackout" I'm not having any errors so I can't test the other exceptions anymore.

Don't do a happy dance until I've tested tonight.

Cheers!

Happy all the same though.

On the nifty candy front, I figured out where mlb.com keeps their probables, in a very similar js-ish format. I'm going to add a few methods to MLBSchedule to optionally pull those down and parse and integrate them. People with slow connections won't have to download them, since it's a separate connection (though if their connections are that slow, they probably wouldn't want to watch streaming video either).

We could either use a separate curses screen for them or we could do "mouseOver" at curses.LINES-2 if the pitchers flag is enabled.

At some later point we can have mlbviewer classic which is the slim model we have now, and a fancier version which opens a second screen when a game is selected that has goodies like probables, scores, top plays, and links for all feeds and streams.

Once again, sounds like you guys have made great progress; and once again, I'll just chime in with my whiny no-code opinion... :}

A toggle for home/away audio sounds okay, but I like the audio_follow suggestion best. How many people frequently listen to more than one or two teams? (I don't know actually, but I sure don't. I guess if tons of other people speak up, then it would be a reason to go with a toggle.)

The only other downside I can think of with audio_follow is that the config file might start to get intimidating for some users. If it wouldn't bloat the code too much, maybe it would be best to do both -- use a toggle to switch, but use audio_follow to set the default?

My $0.02.

I like both approaches. I think follow should be the default but the toggle should exist to change the default.

jkr

Why don't you implement it this way?

1. Default to home
2. If follow is enabled in config file, override default with follow
3. Once I see how it's implemented, I can add in the toggles.

I think the first two are more important than the third.

jkr

Code question:

available[current_cursor][2] is the event_time, but it's a string. How can I convert this to a struct_time? Specifically, the hour is not zero-padded so I can't use strptime() on it. Should I regex it and zero pad it myself before calling strptime() or is there an easier way?

This question is specifically for the mlbrecord project. I would like to convert event_time and localtime to utc for games in the future and calculate the number of seconds I should sleep before beginning a recording.