Quick report from the far north. With the DSL upgrade, MLB.TV thus far has performed superbly.

Mlbviewer using the -dropstream option with the mplayer command in the vidio vewier line in the .mlb config file is simply marvelous. I tune in a few minutes behind real time after mlbviewer catches the stream and logs me in and am able to watch each play as many times as I want before I move on. I am no longer dependent on how many times the networks chooses to show a play. I can also slow the action down to help determine if the ump blew the call or not, etc. :-) ( I'm not an ump basher, afaic...blown calls are just part of the game adding to it's charm and I really resent this trend towards reviews like the NFL has which helped ruin that game imnvho)

I'll automate the process by spending the 2-3 minutes necessary to setup mlbdvd.py... promise ... soon.

For any complete novices using mplayer, a list of both essential and convenient keyboard commands can be found with a couple to three page-downs here. http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

Straycat and Jesse are my cyber heroes. A simply wonderful piece of software. Now knock-on-wood when the almost inevitable changes occurs on opening day.

Pardon the testimonial.

You mean -dumpstream, right?

I think you'll like mlbdvr.py. It really doesn't take that long to setup. DVR-POLICY is not nearly as large as the README (or this thread. ;-) And it will let you watch while you record and resume if the player process drops (nothing yet for resuming if the recorder process drops.) It also has a flag for record only so you can record one game while you're watching another. This is very helpful for the WBC.

And I like the testimonials. I like hearing the ways mlbviewer is being used and enjoyed because it gives me ideas of how to improve upon it. Big on my list is improving the command-line support and finishing mlblistings.py into a full-fledged demonstration application without the curses so others have an easy reference on how to develop new MLBviewer applications. I've also got a mlbrecord.py version of mlbgameid.py so you can automate recording games with "at" or cron jobs by parsing mlblistings.py and scheduling an mlbrecord.py at the correct time.

Someone asked me about whether I would consider supporting XBMC. Well, after trying it out on several different machines, I'm going to say no. Granted, I have only tried the Windows version but it was really slow and not very intuitive. It was a pretty pig, though. My Linux machine (a 900Mhz, 256 MB Debian laptop) would almost definitely choke on it if I can expect a similar experience on Linux.

What I do plan on doing is finishing mlblistings.py as an API demonstration application. This way if someone wants to develop an XBMC module, they can use the MLBviewer library and the mlblistings.py script as a reference on how to create and manipulate the various objects and call the right functions without having to muddy themselves with the curses code.

Biggest problem I had was figuring out where 'dropstream' ;-) was dumping the file to. I looked everywhere for the damn thing, my home directory ~/foo, .mlb etc. even into the /tmp directory....you name it and I looked and couldn't find it. Finally I stumbled across it in mlbviewer. Actually that isn't true. The biggest problem I had was realizing 'dumpstream' was actually working. All I saw was my terminal locking up and a bunch of babble running across it with the final fragment saying "stream not seekable". I erroneously assumed I wasn't capturing the stream and dicked around with that for god only knows how long.

The idea of making it easy to set up a cronjob appeals to me. I like that.

Also, if somebody wants to incorporate a '-vf screenshot' argument into their mplayer command, you capture the umps screwups for all of eternity by hitting the s key.

Keep up the good work.

I assume you're not talking about mlbdvr.py. That should drop the file in the $HOME/mlbdvr_games directory, creating it if it doesn't exist, or whatever you specified in the dvr_record_dir config option.

Yeah, the output of -dumpstream is cryptically unhelpful. That's why my first hack of mlbrecord (a specialized version of mlbviewer) had a poll loop that wakes up every five seconds and performs and ls -h on the recorded file printing the output to the screen. If the file size was increasing, things must have been going well.

I took that code one step further in mlbdvr.py by adding a player process. The best part is that both processes can run in the background without actually having to configure background processes in the command strings (e.g. you don't need "mplayer %s &" which would actually end up the polling code that runs in the foreground.) So every five seconds, the poll loop wakes up and increments the elapsed time counter. If the "record only" flag is set or the delay condition hasn't been met yet, the file size is updated. If the player process has already started, then the elapsed counter is incremented but no output is printed.

Hmmm....there's a corner case I haven't tested. I've been assuming show_player_command=True and keeping all the output in a single window. But if you guys are creating xterms for your player processes (the logic still defeats me, but that's your perogative), then I should continue to update the recorder progress window. I'll put that in the next revision.

In the meantime, here's a screenshot of the recorder progress to tempt you into using mlbdvr.py. Notice that elapsed > delay but recorder progress is shown because the "record only" flag is set to True.

http://www.eds.org/~straycat/mlbdvr.jpg

No, I was referring to just mlbviewer. I got mlbdvr going today and it looks just like your screenshot. Works fine. No problems so far. Works as advertised.

I signed up for the premium package last night because I want to at least have the option of hi def feeds in Windows if I want to. I am impressed with the software but not so impressed with the video quality I have seen of the spring training games so far. I think I have seen the 400k and something between 500-600k. I do have to say it looks better in at the native resolution mlbviewer than it does on the flash player because the flashplayer wants to stretch it. Hopefully when the reg season starts, the 800k will be a lot better.

I see some earlier posts incorporating mlbviewer into mythtv so I can't wait to try that out. I'm just wondering how sad I will be when it looks like crap b/c mlb will not provide a higher bitrate stream without nexdef.

I have no plans to incorporate it into mythtv but the API is out there for you guys to do with it as you please.

If someone else is porting to mythtv, send me a private message or an email at daftcat75(at)users.sourceforge.net so I can post a cross-link to your project on the mlbviewer sourceforge page.

About the stream speeds...

We're in Spring Training and so is MLB.TV. The spring training games are all 400K. The WBC games are 600K unless you have the flash player. The flash player at it's highest level without NexDef seems to be somewhere between 700-800K. We probably won't see 800K streams until Opening Day.

However, if you're curious what an 800K stream looks like, try:

...and watch the BOS@TB ALCS archived game (or any day from last season.) From my bookmarks file (did you know mlbviewer supports bookmarks?), there's the Bos 19 Tex 17 game on 08/12/08 where Big Papi hits two 3-run dingers in the first inning.

It's definitely not high def, but it's still a great quality. I mean when you think about it, 2006 was 350K. So a default of 800K is like the difference between a gramophone and an iPod. Maybe in a couple of years, HD will be the default and the next generation super-HD that obsoletes it will be the premium (Quality so good you can see the Just For Men in Big Unit's nose hairs.)

So, theres no hope of getting the hd quality this year? I don't use windows so thats not an option for me. I guess I should just save the 30 bucks, or is there some reason to pay it.

BTW--Great job on this...You guys rock!! I can always count on Linux geeks to keep it fair for the rest of us.

Where should I make a donation?

Only ways mlbviewer could support HD are:

mlb.com abandons autobahn or more specifically the mlb-nexdef-autobahn plugin.

mlb.com releases the source code for their modifications to the freely available cross-platform autobahn package.

Someone finds a way to get nexdef working in Linux whether it be through wine or finding some jar file the mac os x version might contain.

So yeah, it's probably not worth it to go premium if you have no intention of ever running windows.

...

Donation? Not necessary. But if you must... You can send any donations to straycat000(at)yahoo(dot)com via Paypal. Seeing as I got myself into a mess of debt flying out to Boston and New York last summer to see a game at Yankee Stadium and Fenway, any donations would be much appreciated.

I think it should be pretty usable in Mythtv in its current form. I am not very familiar with lirc, though and just editing my default user's .lircrc file with code like:
Does not seem to be having any impact. Is there any documentation on this already?

I'm ready for the season to begin already. The one game I was interested in today wasn't televised and it also turned out to be perhaps the most exciting game of the spring season. KC and Halos combine for 15 homeruns, 30 runs, and 40 hits.

Me too - I'm ready!

If I remember correctly, I think I viewed a game with mlbs new viewer and I was able to increase resolution as advertised in their demo. Anyway, mlbviewer seems to render a better stream. Why is that?

I'm wondering if the only feature we will lack is the dvr functionality, and I think we have that with mplayer.

I should search this next question but before I strain my eyes looking, I'll ask. Can we skip the commercials when viewing an archived game? Please don't hit me!! I'm fragile!!

Thats ridiculous!

I can hazard a guess at the first one. Without the new flash player, it's a constant bitrate, and probably a lower bitrate from my testing, but it doesn't have any artificial intelligence saying, "no, really, you need a slower (or faster) stream now." When the season starts, the base stream will be 800K whether premium or basic. The premium just means the flash player can work with autobahn do to some compression and buffering tricks to get a better quality stream, but possibly not as reliable.

There's a lot of cool stuff that's being built into the flash player that I don't even want to try to support. I mean aside from the things autobahn does. There's actually a lot of information out there in xml files like player stats, box scores, links to player pages, etc. But xml is much harder to parse than the single json page we use now and mlbviewer would get over-cluttered if I tried to support it all. Plus, I don't want any run-ins with the copyright lawyers.

As for the dvr functionality, I've attempted the best hack I could with mlbdvr.py in the svn repository. I hesitate to roll it into an official release because of that whole, "any reproduction..without written consent..." etc. But you can grab it from the svn repository using instructions in the README file.

Finally, you wouldn't normally be able to skip commercials without the autobahn plugin. The mlbdvr.py hack is a best attempt at providing that functionality. If you wanted to do that, my best recommendation is to make sure you record enough stream so that the player doesn't try to buffer past what the recorder has recorded. A new fix I'm currently testing will allow you to toggle the dvr_record_only flag without restarting mlbdvr.py so that if you do try to play past the recorded stream, you can suspend the resume code long enough to let the recorder get ahead again. Good time to get up and grab another beer or use the bathroom. I still have to "save" the last elapsed time counter so that if you say, suspended playing in the 3rd inning and resumed after the 8th inning is recorded, the player doesn't try to play from the 8th inning but resumes playing from the 3rd inning. When I have that in the code, I'll check in the changes into the repository.

There is an xml on their network somewhere that lists stream id's for half innings. This would allow you, in theory, to jump to a half inning. Though I don't think this worked quite so nicely in practice when I tested it last year. You may just have to resign yourself to knowing that there are a lot of features mlbviewer can't or won't support.