Ah, a rival. I'm not from Kansas City, but I've been a Royals fan ever since I was young. I think it started with all the George Brett cards I had in baseball card collection but it was definitely solidified by Danny Tartabull and his wife. She was a customer of my Dad's pharmacy and he gave me an autographed baseball of the late 80's Royals (don't remember the year but it has Seitzer, Saberhagen, Quiz, and Bo among others) and tickets to season finale at Kauffman. Mom was doing business trips to St. Louis at the time so it wasn't that hard for us to get out there.

Right now we print the splash directly using about three or four lines of code which automatically adjusts where to put the strings based on the length of the string.

It wouldn't be that hard to read it from a file except that you might be constantly changing that file to adjust for any differences in version string length between releases. Also your file would look kind of funky on the disk because you'd have to leave room in the ascii image for the string to expand the lines to right length.

If you wanted to code it up with a text replace on some tag like %version%, perhaps we could include it the official source and mask it out with a config file option so you wouldn't have to patch every version you download. Note that we use four lines (three for name, version, url, and one for "Please wait while listings load..." e.g. the real reason why we have a splash at all.)

I actually think a legend accomplishes the same thing without requiring extra key strokes. Code wise, I can see a menu as getting tricky because it would be another screen object to manage if you wanted to navigate the menu (e.g. up/down and select.) A legend is something we could manage as a hideable object that accomplish much the same except that you would still be responsible for entering in a hotkey but at least you'd see your options in front of you.

Then again....

I'm not ruling it out. There are a lot of OOP features and principles we're not using yet. We could define a base menu class and let each screen inherit that class with entries and functions that make sense for that screen.

You'll likely see a hideable legend first and perhaps a menu as our gui code becomes more object-oriented.

If there are no objections, when condensed games come back, I intend to put those on the top plays screen to reuse code. I suppose it would be possible to hotkey that to 'c' as well.

Has anyone else noticed that mlbviewer says the second CLE @ KC game is to start at 3:33 AM ET?

That's not right. My scoreboard app says the same thing and it's pulling from a different xml.

Oh well, all we can do is parse what we're given. And I sure hope for both teams' sake that they're not pulling an all-nighter tonight.

I just hit pay dirt! I found the xml that has real-time game highlights. No more waiting for Top Plays to get posted.

Because I'm anti-spoiler and because it comes from a different source, has different videos from Top Plays, and because there is no xml parser code in mlbviewer yet, I will initially implement it in mlbscores. That way if you want spoilers, this is where you'll find them. If and when the two code bases are merged, I'll look at how I can combine them without overlap. I do have stream id's so it should be possible.

I'm not sure if mlbscores will be in the coming official release but I'll let you know just as soon as it hits svn. Besides, I'll need everyone on long last name alert to make sure Saltalamacchia batting against Chamberlain doesn't overrun screen space buffers. ;-)

I found all kinds of cool xml's including a mapping of players in the game to their player id's. This means we'll eventually be able to link a box score directly up to their player page on mlb.com through a supporting external web browser.

Good things on the way....

For those who wanted the scheduling feature, is it okay to block or do you want it non-blocking?

The problem with implementing a non-blocking solution is that at the top of our event loop, we're sitting in a blocking getch() call waiting for input. I believe that would mean we would have to change from getch() to select(). I don't know how difficult that's going to be.

Oh, it looks like we're already using select, I guess I'll look deeper at how we're doing this.

Not sure I'm smart enough to know what you're asking... If you're saying the scheduler would block other input until the scheduled event, it seems like we'd want to avoid that. ...But it also seems like you might need to check something else out first, so I'll hang tight till then.

Also, pulling svns from yesterday and today gives me this every time just after the splash screen:

I'm on revision 61 at the moment, on two different laptops. My backed-up old version (not sure which one, but I think it's at least a week old) works fine.

Anybody else seeing this?

Fixed.

It looks like you never defined your speed in the config file (not required) so we picked it up from DEFAULT_SPEED. The problem was this was defined as an int but anything that comes from the config file is treated as a str. So when we were looking up the speedtoggle string, it was returning a None (or not found.) I fixed it so that the DEFAULT_SPEED is a string instead of an integer.

You can run svn up to get the latest fix.

Just got the new revision and it works great. I did wonder if it was an issue with a missing config option, but wasn't sure which one to look for.

It's pretty funny how much you and jkr pwn over whoever's running the offical MLB player. Thanks for the fix.

Okay, it looks like code-wise, non-blocking scheduling could be added but it's not a trivial patch like I thought it might be.

It's not going to make the next release (which I've encouraged jkr to make available this week.) If you have the latest svn, there probably isn't going to be any big changes. Maybe the bug fix I added Sunday morning and an auto-configuration routine for anyone doing a fresh install.

Otherwise, the next release is just to have a recent official release to point new users to. Thanks for all your testing. I think we've accomplished a lot in a short time and have a really rich and stable product right now.

I'll be fielding bug reports and fixes as quickly as possible but new feature development may move slower for awhile.

If anyone is wondering what "Unknown Status = S" means, it's fixed in the latest svn. ;-)

I'm assuming the crickets in here are indicative of happy baseball fans watching/listening to their favorite teams in total bliss.

Hey everyone,

I want to apologize for my absence here recently -- though I doubt you really noticed, since daftcat has more than taken up the slack. It's been quite busy here, and I haven't had a lot of development time.

But I did want to let you all know that (as daftcat suggested) a new release should be coming by the end of the week (barring any weird bugs that pop up between now and then). I imagine that you're all testing it out pretty much every day with your favorite teams, so I also imagine that it's working pretty well. Please let us know if anything pops up. Otherwise, just keep your eyes open for the announcement.

After this release, I think we'll all have the ability to watch baseball the way we want to, with the service we paid for. And hopefully we'll be able to open that up to a few more unix users as well. Thanks again for all your help with testing and suggestions. Development will continue after this, but at a rather more relaxed pace. Still, suggestions will, as always be heeded and appreciated.

Anyway, just wanted to say hi to everyone and let you know where things stood. Hope you're all enjoying the warmer weather (or, if you're in the Southern hemisphere, the cooler weather).

--J

Was there every any headway made with MythTV integration?

Not exactly. The writer of mythstream did send me an experimental version which could handle python scripts, and that is coming out sooner or later, so it shouldn't be hard. But (a) for some reason I couldn't get it to build correctly (or, rather, it would build fine, but then crash), and (b) that was right around the time that the concurrent login issues were surfacing, so it seemed better to get that part handled.

Frankly, though, the reason I haven't given it that much time is that I've just been using your solution from a few weeks ago, with a mythtv button kicking it over to a full-screen terminal. With LIRC, it really does everything I need it to do, so it's a bit hard to work up the energy to figure out why the new mythstream is crashing for me and then redo it.

That all being said, the code is pretty nice and modular now, and all of the work of parsing and streaming has been separated out from the frontend. It should be pretty trivial for someone to either make a perl implementation for the current mythstream (it would just have to invoke python as an external process), a python version for the next one (cleaner, obviously) or a native c++ plugin that either rewrites the classes or calls them. My satisfaction with my current setup, though, is such that I might not be the one to do it. Be glad to help out anyone who wanted to, though.

jkr

Can I add mlbviewer to my MLB Linux Howto yet?