Minor fix checked in.

Rookie seasons (only a single year for a player, e.g. Tanaka on the Yankees) was crashing player stats from box score. Fixed in SVN rev 597.

mlbviewer is trying to force me to watch the home stream for the free game of the day.

According to the MLB.TV schedule on the official website (http://mlb.mlb.com/mediacenter/index.jsp?c_id=mlb, the Free Game today comes only in one flavor (e.g. "home" coverage.)

This information is also available in the 'z' screen:

Looking at the first data tuple, the list (enclosed in []) following the datetime.datetime() portion is video. The next list is audio. The audio and video lists should contain two tuples of (call-letters, team-id, content-id, event-id). We can see that the video list has only one element:

So even if it weren't the free game of the day, only home coverage is available for this game. To verify the coverage team, you can do the following:

Sorry for not trying sooner but have been away. Still having problem with install.

dennis@dennis-Aspire-7540 ~ $ python mlbviewer.py
python: can't open file 'mlbviewer.py': [Errno 2] No such file or directory
dennis@dennis-Aspire-7540 ~ $

For this command to work, you have to be in the directory where mlbviewer.py resides...

In your post from April 8th, you had this:

dennis@dennis-Aspire-7540 ~/mlbviewer-2013 $ mlbviewer.py

ie. correct subdirectory, wrong command, then you had wrong directory, right command -

give it another shot with correct directory - mlbview-2013 and correct command python mlbviewer.py -

and good luck.

If you have a favorite team in your config in favorite= option, listings and master scoreboard code will now focus the cursor on your favorite team's game. No more having to manually scroll to your team's game. This should work with all listings operations too (Left, Right, and Jump to date/Jump to today.)

1. If you have more than one favorite, it jumps to the first favorite it encounters.

2. I do not have an option to turn it off. If you guys don't like it, let me know and I'll add in a config file option to turn that behavior off.

3. Also, let me know if there are any problems with this feature. It took me a lot longer than it should have to figure out how to get the screens and focus correct if the favorite team is on a second or third screen of games (e.g. small terminal size.) I probably also still have some cryptic debug code in there if things crap out unexpectedly. Just tell me what the error message was even if it doesn't make sense.

4. If it is crapping out unexpectedly, you can revert to a previous revision until I can fix it with "svn -r599 up".

I live in New Zealand, which is west of the international date line and in the southern hemisphere. This seems to affect two minor related issues in mlbplayer.

The first issue is that when I start mlbplayer the game schedule for tomorrow is always displayed and I have to hit the left arrow to display today's games. I think this has to do with me being on the other side of the international date line putting me a day ahead of the US, I think this has to do with the wrong day displaying.

The second issue is that the game times are (currently) an hour off. Since I'm in the southern hemisphere our summer happens during winter in the US and vice-versa. This means that daylight savings time is also opposite here. Now there is a short (approximately two week) period during spring and fall when both the US and New Zealand are in daylight savings, and during this time the game times displayed correctly, but as soon as we dropped out of DST a start time of (for example) 2:05pm displays as 3:05pm in mlbplayer.

These are certainly minor issues, and I think that mlbplayer is a great product, it enabled me to watch ball games on my older (less powerful) laptop hooked up the the TV and for that I am very appreciative. Please keep up the great work with this product.

Oh, just FYI I am running the 2013 stable release of mlbplayer not the latest svn, so apologies in advance if these issues have already been fixed.

Please try the latest SVN release. I put something in that may have fixed it earlier this year.

Timezones are tough because I get the listings in US/Eastern which has its DST rules. Then I convert to UTC before converting to local time which has its own DST rules. On top of that, I'm not sure if the Python calls I am making to check for DST are correct. In any case, I know I have something checked in this year that wasn't in 2013 code related to this.

Here's the breakdown of a specific example.

Listings are fetched and a 12:05 US/Eastern start time is retrieved. US/Eastern is observing DST so that should get converted to 16:05 UTC (EDT = UTC-4.) From there, it should be converted to 4:05 NZST (UTC+12) the following day.

However, since I cannot find a specific way to specify the listing time is actually EDT, the best I can do is convert to UTC first and then from UTC to "local time." The problem you are seeing arises from using a flag in Python time object called is_dst. Since I cannot seem to treat a time object as if it belonged to a specific timezone, e.g. "hey Python, this is an EDT time object. Please convert it to localtime for me,", I am using the local is_dst flag for both conversions. So in the first conversion, is_dst is False (from NZ point of view), and thus 12:05 EDT gets converted incorrectly to 17:05 UTC. That's the problem. I cannot find an easy way to say, "tell me if US/Eastern is currently observing DST," or alternatively, "treat this time object as US/Eastern when converting to UTC."

Also, I honestly did not know that southern hemisphere reverses DST but it makes total sense to me.

I will look into restoring the old time_offset= option to override these conversions if I cannot solve the timezone issue in Python datetime/time classes themselves.

The second issue is a real brain buster. You're firing up mlbviewer on 5/6/2014 localtime but it's 5/5/2014 in US/Eastern where the listings come from. But mlbviewer is going to pull game listings from 5/6 because that's what your clock says. If I re-implement time_offset, I will look into supporting that option in the pulling of the listings as well. In other words, when you fire up mlbviewer at 10:00 PM PDT (according to the time stamp on the message you posted) which is really 17:00 NZST on 5/6/2014, I would do an inverse time_offset to retrieve the listings. In other words, if you specify +16 as your offset from US/Eastern, then I would do a -16 on your datetime.datetime.now() used to determine the day for retrieving the games. There is an additional check in the mlbviewer listings code that says if localtime is before 9am, use the previous day's games anyway. Since most games don't start before noon Eastern, this is a pretty safe assessment that before 9 am, you are interested in the previous day's games. Thus, the reverse conversion of localtime (-16) would put your local clock (from mlbviewer's perpsective) at 01:00 < 09:00 and thus, it should subtract a day and show you the correct listings, adjusted correctly (+16) for local time.

I think I just confused myself.

ACTION NEEDED

time_offset= was re-implemented and the format of the option has changed. If you "svn up" to this release and times are suddenly in US/Eastern, that means there is a time_offset= option in your ~/.mlb/config. You'll have to comment this out (or remove it) to get the pre-603 behavior.

MORE DETAILS

I reimplemented the time_offset= option except I have changed the format. Previously, an offset of -330 meant UTC - 3 hrs, 30 min. From SVN revision 603, this should be time_offset=-3:30.

Due to the discussion above regarding Southern Hemisphere DST rules and timezone naive datetime objects (and the absurd way to implement timezone support in Python), I have changed the time_offset option to be specified as +/-HH:MM as an offset from US/Eastern (UTC-4)

Why as an offset from US/Eastern instead of UTC? Because US/Eastern and local timezone may have different DST rules (e.g. Southern Hemisphere has opposite DST dates), in order to avoid an incorrect conversion to UTC based on localtime is_dst flag, the time_offset= option skips the intermediate conversion and translates directly from US/Eastern.

If you have a time_offset= (blank) or time_offset= is commented out, you should see no difference with this revision. If you have time_offset= specified in the old format (without the ":"), your times will be displayed in US/Eastern (no game time to local time conversion.) You can either comment out time_offset=, fix it to the new format, or remove it completely from your config.

NOTE

The time_offset= option is not DST aware. I think everywhere that observes DST has already done their clock conversions so this shouldn't be an issue until Fall (Spring for Southern Hemisphere.) By then, I'll have implemented a time_offset=/alt_offset= option so you won't have to change your time_offset= option twice a year.

Also, for a time_offset= specified, the reverse offset will be applied to localtime effectively converting the local machine to US/Eastern time when determining the startdate for games. This should theoretically fix those on the international dateline starting a day ahead of the current day's games. If you encounter any problems with the start date after updating to this revision, let me know and I'll implement a separate option to adjust startdate offset independently of game time conversion (time_offset= option.)

I'll try the new revision as soon as I get a chance, I'm a bit swamped at the moment.

Have you considered using a library such as pytz to do the conversion?

I'm really trying to avoid adding in more library dependencies.

Although the tzinfo class in the time library seems overkill and unwieldy, all I really need is to convert the times in US/Eastern to UTC using US/Eastern's DST rules and not the local computer's timezone DST rules. Why is that so hard in Python? Anyway, I am experimenting with moving gameTimeConvert (and now it's helper function timeShiftOverride) into a separate class so the time changes I make in one do not have to be repeated into mlbviewer.py, mlbSchedule, milbSchedule, and anything else that uses a US/Eastern time. Once I have all the time conversions using a common class, I can experiment with ways to get a reliable EST/EDT to UTC conversion.

Can you do me a favor and try the latest revision (rev 611) without time_offset= option first? I changed it up again and implemented my own US/Eastern to UTC routine using US timezone rules (e.g. 2nd Sunday of March <= daylight savings time < 1st Sunday in November.) That conversion was the troublesome one in your off-by-one hour problem since the old code was using NZ rules for determining DST for US/Eastern (damn timezone naive objects in Python!)

For the second problem, I do it in reverse converting your localtime into US/Eastern time to determine the start date for listings.

If the automagical rules above still don't yield the correct result, specify time_offset as offset from US/Eastern (currently UTC-4 until November.) I know it's weird specifying an offset from a specific timezone rather than UTC but that will bypass all the DST rules and just do a straight conversion from the listings time to the desired local time.