You can't seek in archived games....yet....

However, probably in a week or two, I'll release a version of this mlbviewer which records the stream. If you record a stream and give it a head start (I like 10 minutes or more), then you can play the recorded stream as it is being recorded and fast forward. The only problem is you can't fast forward past the point where the recording is. So if you gave it a ten minute head start and fast forward to 11:00, that won't work. One of the reasons I'm holding off on releasing the record code is because I'd like to be able to schedule a record. If you know you're going to miss a game, you don't have to be there when it starts to hit record. When you get home, you can fast forward, pause, and rewind all you want.

In the meantime, if you can't wait, you can change the player command to:

or

for recording audio streams. You'll record from whatever point the game is in at the time you connect. This isn't a bad thing if you're watching half a game and would like to record the rest.

You might have to have two video_player lines in your config (one commented out) that you swap between to change from playing to recording. Or you can create a copy of the mlbviewer.py script and hardcode the record command in the line that says:

to

(note the space between mlb.asf and the single-quote. This is necessary.)

If all of this sounds like too much work, you can just wait for my mlbrecord script to be released.

You can also change volume in mplayer with the / and * keys with / decreasing the volume and * increasing the volume. I believe this controls the application's volume without affecting the system volume.

I'll get all this tips and tricks on my howto page.

jkr

Are you ready to put this on my howto page or do you want to wait another release or two?

I think the last changes I want to make before general release is putting some kind of "trying" message whenever it performs a network operation so it doesn't look frozen when the network is slow. The other change is to make the log file append rather than overwrite.

On second thought, why don't we wait a week for general release? People can still find this thread or the sourceforge project via Google. I'd like to try to make us look more like Firefox from the network side.

Audio and video syncing is harder than it sounds. I was watching a game on my normal system and testing concurrency on the laptop I usually work from. One of the games I was testing was the same game I was watching and the streams were off sync. The buffers may be different though. Anyway, it was weird. I'd see a play happen on the laptop and then it was like I was clairvoyant and could tell what was going to happen on the main screen. ;-) It would probably be easier with recorded files.

I'd eventually like to support top plays, condensed games, scores, probable pitchers, news URL's with a configurable helper app to view them when selected, and whatever other info they give us in the listings and the info page.

As for all the gui options, the reason why the new release was separated into individual files instead of a single file is that we hope the engine is now sufficiently separate from the "gui" so that other developers in the open source community can import our library and create their own gui. In other words, if you understand python and Jkr can adequately document the data structures and API's, you would be able to code up whatever interface you want. My particular setup loves interfaces that can be launched from a putty window. Yes, one of your chief developers on this project is primarily a Windows user with a Linux laptop that operates more like an appliance than a desktop. My focus consequently would be to continue and improve the curses interface or even create a command-line product like I hinted at several pages ago. I know Tcl and I've done some Tk work so if you could convince me or bribe me, I might write a Tk gui, but it's not in my interest at the moment. Far more useful to me would be a php interface that supports both local and server-based playback. That's something perhaps a lot further off. I honestly don't know how well php and python interface.

Anyway, the long and the short of it is that the network side stuff is going to get better, the curses gui will continue to improve, but other gui's may have to wait for other developers (unless jkr is moving forward with the gui he demo'ed several pages back.)

Thanks for the feedback. It's much appreciated.

jkr

Is there like a call and response model you can think of for GameStream and "gui" to update each other on status?

I'm when we select a game, we should update the status bar with "Logging in..", "Logged in.", "Getting URL...", etc. This isn't a problem from the GameStream as we can set a status_str like we're setting error_str (by the way, y'all, how do you like the error handling in the new release? better than the beta message, eh?) The problem is, g.url() is atomic. The GUI can't do anything until it's done. I suppose "Trying...." is better than nothing. The only way I can think of improving this is to make g.url() asynchronous but that could be a whole new hornets nest of problems (like launching multiple games before the first one has completed.

I guess I'm just thinking out loud right now. I'll experiment with a "Trying..." message and see how that grabs me.

Oh, I got a feature request.

We should have a date selection method so that if I want to watch last year's World Series, I don't have to back arrow my way to October. I know this would be trivial from the listings side but two questions arise. What do we do if the user inputs an invalid date (31st of February) or picks a date that had no games and would return a 404 from the listings page? Should we show an error page and return to the current day?

A trying message, or "Fetching URL" as it turned out, is a fantastic idea, and definitely improves how responsive it feels. I do think making g.url() asynchronous is more trouble than it's worth... or at least requires some serious thought. As you suggest it could accidentally create problems with accidental windows. I'd be happy to listen to arguments, though.

It would be cool to be able to have another game you could switch to during commercials (or picture in picture if the players supported it) but (a) I don't know how audio would work, and (b) what would it look like to their servers to have an (admittedly small) set of their users constantly downloading two streams at once? I don't have a lot of faith in their log-checking... but if we're trying to emulate normal browser action, we should keep that question in mind.

I was planning on getting back to it as a side-project after a few more improvements and cleanups are made. One of the main reasons for it, oddly, enough, would be to improve cross-platform experience, since curses is flakey at best on windows, and not everyone has cygwin. Now, whether we'd want it to be easy to use on Windows is another question... just as far as our numbers and therefore visibility. But as we've said, I don't think they're changing anything, and, as far as I can tell, we're far from violating any TOS. We're just ignoring their recommendations, which as linux users, we've been doing all along anyway.

Daftcat, we might want to add an experimental directory in the next release or two for things like the guis and mlbrecord.

My todo list is:

1. Get dates working.

Timezones are tricky, and full localization might bloat this unnecessarily. My preference is to default to reading the user's machine's UTC offset, unless you explicitly set 'time_zone_offset = -0500' in your config. It would have a harcoded end-of-daylight-savings date so it could convert their string time to UTC. (This would just have to be an annual update, and it would likely be by far the least of our annual update worries.) Looking around at timezone libraries, a true implementation would either require more network calls, or would more than triple the code base. But the above approach seems simple enough.

2. Add a debian/ directory so I can release proper debs with dependency checking. It would make system install/uninstall a good deal easier. (If anyone who knows more about rpms wants to be in charge of those, let me know.)

3. Add back-end support for the pitching matchups.

I might leave front-end implementation up to someone else.

4. Code cleanup.

Licenses in the right places. Global variable properly handled in the __init__.py file. This shouldn't be noticable to anyone but me and daftcat.

5. Finish up simple usable wxPython gui.

The panel applet will have to wait for someone else.

By the way, if anyone has any experience writing documentation (README, INSTALL, man pages, etc.) and feels like being responsible for that end of it, speak up. I'm in an English department, so I suppose this should be my area, but I'm doing this mainly as a way to use a different part of my brain. If you've been following development, and you want to be involved without coding, let us know.

Yes, I think so. I also don't know if last year's listings had the same format, either in URL or JSP format. There would definitely be a problem with new features. I.e. let's say 1200 worked (bear with me) and the user had it set in the config. Then they went to last year, which had no 1200. I realize I had to make a non-existent case, but there might well be a few gotchas.

So, yeah, I'd say any error should give a message and return to the current day.

Curses has a nice text entry system. (I was going to add one in the next release or two which, if there is no config file, asks at opening for username and password and asks if the user wants it to be saved.) So 'd' could ask for a date in the bottom linein a certain given format ((m)m/(d)d/yy) and then do the call.

One thing I was wondering about: can dumpstream pull down faster than real-time for archived files? Or maybe mimms or some other approach? If there were *any* way to do that, it would be cool to have that be a built-in way (turned on by configuration option, natch) to watch archived streams transparently... like mythtv. I know you and Theophile were talking about this, and I remember one problem was that there's no way to get the video player to give you a buffer at then end of the file; it just fast forwards past the end. But as you develop mlbrecord, we should keep thinking about whether there's any way to use it to make a buffer transparently for archived games.

(For live games, I sometimes just push pause in mplayer if I need to take care of something, and then there's a buffer there as well that I can fast-forward through.)

Just signed in to thank all of you guys fo this great piece of software.

I will try new version as soon as possible (maybe tonight or tomorrow) and, if it will work correctly I will probably write an ebuild for the gentoo linux distribution (which I'm an user of).

Last words just to say that for the recording issue I'm quite satisfied with this command as video_player
I found the --resume option, lacking both in mplayer --dumpstream and mmsclient, really helpful when my buggy connection drops.

Again, Thanks

p.s. I'm using latest mimms ( 3.1 )

Open call for testers:

Okay, I put basic time zone support in. It defaults to figuring out your computer's offset from utc, but you can also put 'time_offset = -0500' or whatever explicitly in your config file. On the whole, if your computer is set up correctly, I think it should just work.

It seems to work fine for me, either putting offsets in explicitly or changing the timezone on my computer. However, I'd like a few testers. Not just for timezones, but to catch how it behaves on different setups.

As far as timezones go, though, it sounds like there are a lot of Californians here -- any midwesterners? And turf212, you said you were in the UK, right? Also, anyone in a place that doesn't do daylight savings, it would be great if you could test it.

Kind of chicken-and-egg, since I don't want to release this until it's tested, so I'll have to ask you to check it out from the source repository. It's easy, though. You just have to install subversion, which isn't that big, and is in every distribution.

Then go to some directory or another and type in:
There might be other little glitches we're still working on. I just want to check out how the times look.

I'll download and test when I get home. If it works me then should be good for those in the states.

I've been using the old version until today, and been working fine, but decided to try the new one. The time zone works fine for me without having to put it in the config. Also, I'm using Slackware so consider it tested on a much different setup. Oh, and I'm a midwesterner, but I'm in Eastern Time (Ohio).

Guess I'll chime in on this too...

1. Are you able to watch live games? archived games?
Edit: Live and archived both work

2. Are you using gameday audio? Is it working for you?
Haven't tried it.

3. Any other problems or feature requests?
The main request I have is one that others have requested...being able to watch the Daily Rewind

4. Who's your team?
Cardinals (although not sure I should admit that, jkr might block me out :P)

Just wanted to say thanks for all the work you guys are putting into this. I thought I was actually going to have to use Windows for it until someone pointed me at this thread.

Turns out supporting last year would require different code. Game id is w_id and the url's are http:// not mms://. But even trying one of their http:// url's it would connect but bail out. Of course, we're still not hitting their servers like Firefox does so we might be getting bad url's.

We can throw an error for right now when the year is not 2008 and put 2007 on the todo list. As the season grows longer, it's going to take more time to go back to say, opening day.

I wasn't going to implement full timezone support for record either. Offset from UTC is the best approach I could come up with as well. This latest svn with local-time support looks good to me. I haven't looked at the code yet but it's nice to see game times in local time. Daylight saving time is kind of a moot point since the clocks don't roll over until after the season ends. Thanks to Bush's genius energy plan, even the post-season now falls into daylight saving time. As long as we can consistently determine offset from UTC, we're all good. No game times will be in standard time. :-)