For anyone using the older version, you don't have to try the latest svn, but please upgrade to the new version released on Monday. The networking code and error handling have been improved.

My biggest concern with people using the old version is that the User-Agent is set to python/urllib. In the new version, the User-Agent is set to Firefox on Windows. This makes it look less like we're trying to hack their service. We're still not 100% network transparent (meaning we still take a different approach from the browser-based service) but we're getting there. The goal is to look indistinguishable from the browser-based client so that we don't raise any concerns from the mlb.com staff.

Plus, if you've ever experienced the "Records show you are logged in on multiple computers" error (or in the old version, it's the "This error will be more helpful in the real beta"), that's been fixed in the new version.

jkr

Please consider deprecating the old version. We are still an alpha release so I think we're within our rights to force, er, strongly suggest that users remain current until we have a stable beta that includes network transparency. At that point, I don't mind if users don't stay current.

We can't record faster than real-time. The best we can do is increase the buffer size. The flip-side to that, besides memory consumption is the amount of time it would take to initially load video. If we wanted to buffer 10 minutes, we'd set the buffer to 24mb on a 400k stream. Playback would start at 20% buffer unless we changed that too. So we would actually only have 2 minutes in our buffer when playback started. That also means that it would take 2 minutes for playback to start.

One thing I was considering is that my record code uses poll instead of wait so the record process is non-blocking. This should allow us to launch another process to play the stream we are recording. I'll look into this. I'll have to measure how long commercial breaks generally are. I'm thinking between five and ten minutes is a good head start before playing. Of course, I'd make this configurable.

My to-do list includes:

Improve network transparency

Meta-refresh support (keep trying when we receive "Estimated delay" web pages)

Date jumping (if you beat me to this, I won't be upset. ;-)

Online option setting (meaning you could change your config file settings within the program without having to restart the application)

Log rotation (how big is too big for the log? 2 mb? 5 mb?)

Recording support

I didn't notice. Is x_display in this new one? If not, I'll put it in tonight.

I'm liking the splash and "Fetching" messages I put in last night. It's much nicer than throwing up a blank screen waiting for the network.

Is it possible to automatically put an svn version in VERSION since we have now opened up svn to testers? It would be nice if people could post the top line of 'h' screen when reporting problems and have it map to an svn release so we know if it's been fixed or not in the current svn.

If you don't have a help screen when pressing 'h', your version is too old. You should update.

Times all show correctly, although the dates dont match up (They go over past midnight here Archived games work. Will let you know about live ones once they start (though I'm sure it will still work)

I was actually wondering about that, for European and especially Japanese users. The issue is that 3 a.m. games are still on the previous day's schedule, right?

This might have to be a configuration option, since it comes down to personal preference. My sense is that even if it goes past midnight it should still be part of that day's games. But an 8 am start in Japan is a different matter. Suggestions welcomed.

"time_zone_offset" doesn't seem to be working right now, I've tried changing it in the config file but it hasn't changed the time displayed at all. Fortunately my time zone is detected properly.

Here's my config file:

user = me@me.com
pass = mypassword
speed = 800
audio_follow = chc
time_zone_offset = -0500

I'm using Ubuntu Gutsy, which uses Python 2.5.1.

The config option is time_offset

Not yet. It would make more sense if you put it in, since you're better acquainted with the use case.

Just put in date-jumping. Dirty details in mail.

Oops! I accidentally copied the syntax from your earlier message (#397). I've tried it using time_offset and can confirm it's working just fine on my setup.

Whew. (Um... they need this to be more than 10 characters in length.)

I've now run mlbviewer 0.1alpha5 on both my Ubuntu system with VLC and my OLPC (Fedora) with mplayer. I've only tried archived games, but everything seems to be working fine, including audio, video, audio_follow, and time zone. There was one game where the audio wouldn't play (Cubs audio for 4/13), but it looked like it was a server-side problem -- sometimes it would begin to play and then crash VLC, others I would get an error that said something like "there was a problem with this stream".

One interesting note about seeking: I can confirm that it is possible to seek through archived games using VLC, but only for the first minute or so after the stream begins. That is, if I seek to 2 hours into the broadcast right after VLC opens, it'll do it; but if I wait two minutes and then seek even a little bit in any direction, I lose the stream, no matter where I am in the broadcast.

I was able to do the same thing last year. I assumed then and now that it's an authentication issue: I think the game authentication expires after a minute or so, so my guess was that the same token somehow applies to the ability to seek as well. VLC does take a while to seek, so maybe it's actually re-aquiring the stream with a new start position or something?

Anyway, it's annoying that mplayer doesn't easily do the same thing, since I don't think VLC works very well on the OLPC, which is where I really want this to run. Anybody know if there's a way to force mplayer to do this the same way VLC does?

Of course, recording would make seeking trivial, but my connection's a bit flakey so I'm doomed if the record doesn't work.

Couple thoughts:

1. As much as I favor the recording feature, I worry that including it would attract the ire of MLB. They're very paranoid about unauthorized distribution and I think this is why they're moving toward video output in browser windows only.

2. If we can figure out who developed the "NexDef" plugin, we might be able to convince them to share the specs or at least enough to make it work in Linux. But maybe it's not worth it. The 1.2M streams aren't much sharper than the 800k streams, but the 800k streams are much, much smoother.

3. Another feature request: Ability to watch half-innings in archived games. Or is this a flash/silverlight/bloatware-only feature?

Oh, also, jkr, it looks like you might have already committed the day-jump thing, but as a user in "Europe" (don't tell my British friends I said that), I'd definitely prefer the games to be listed under the US date they were/are played. That way it matches up with press, external schedules, etc.

Are we really talking about which day the games are listed under, or just how the times appear within each day? If it's the former, then a game played tonight at 6:55 EDT would show up under tonight's listing and a 7:05 EDT game would show up under tomorrow's...

To keep things from getting too dizzy, I'd say keep the listings under US dates and just change the way times are displayed, something like "3AM + 1 day". (Or even ditch the airline-speak and go with "3AM the next morning"?)

Incidentally, I hope enough people are telling you guys that you totally rule for doing this that you get the idea that you really do. If not, let me know and I'll keep repeating it at the bottom of every post.

I mentioned this several pages ago in this thread that I'm not very comfortable with releasing the record feature. I'm concerned that games would start appearing on the torrents networks and recording probably violates the TOS. I'll have to review that.

My feeling now is that if people want the record feature, they have the source and they have the architecture to do it themselves (even without modifying the source by methods I've listed earlier.) I'd rather the project not attract the attention of mlb.com. They seem rather powerful and not afraid of litigation (sling box or something like that comes to mind.)

Read it here now

Recording is officially off the roadmap. If you want it, you have the source and you have the tools to implement it yourself.

I hope jkr is okay with me saying this.

In fact, I hope we can make it an official position of the project that we don't support recording so we can cover our a$$e$ in case we do attract unwanted attention from mlb.com.

I would think MLB and MLV Advanced Media would be pleased that you guys are taking care of their customers for them, free of charge. The atmosphere in this thread is entirely different from that on the Mosaic forum, which I just visited for the first time today. Wow!

But sadly, that probably isn't the case. If Microsoft ends up on the winning side of the hostile takeover of Yahoo, Linux users will be even further screwed since Yahoo and MLB just signed a 3-year advertising and content delivery/branding deal.

That said, I wouldn't worry about games ending up on torrent sites. mimms has been around for a while and regardless, DVRs are abundant and all these games are on TV somewhere and you can't find them on torrent sites.

Anyway, keep up the good work, y'all!