To checkout nexdef2011 branch:

Do this from outside your mlbviewer or nexdef2010 directories. In other words, this doesn't patch what you have, it checks out a different branch.

Decision time.

You can switch back to the mlbviewer trunk which is the last nexdef2010 code that will be maintained only for bug fixes.

Or you can move to the nexdef2011 branch which will still have active development on it. In other words, this branch will get new features, but may also get new bugs along the way.

As additional incentive to check out the new nexdef2011 branch (because I need testers besides myself), I have added a new script called mlbplay.py. It's a gui-less utility like the test scripts except it uses the actual MLBviewer code base. You get more of the mlbviewer features without the curses gui.

I haven't updated the documentation yet, but the usage is pretty easy. All arguments take the name=value form. All names have both single key and long names. In the case of single key arguments, I have attempted to keep the keys consistent with mlbviewer.

Long names (and single keys) supported are:

audio (a), video (v), condensed (c), speed (p), startdate (j), debug (d), zdebug (z)

To select a game, use the two or three letter teamcode found in the README file (also used in blackout, audio_follow, video_follow, and favorite config file options.) By specifying the teamcode, you are also selecting the broadcast you desire (think of it like audio_follow or video_follow.)

EXAMPLES

To view today's Phillies game,

$ ./mlbplay.py v=phi

or

$./mlbplay.py video=phi

Either long name or single key can be used.

To listen to today's Marlins broadcast,

$ ./mlbplay.py a=fla

To watch yesterday's Boston game,

$ ./mlbplay.py v=bos j=05/13/11

To watch it in nexdef (still not really supported yet but you can try anyway),

$ ./mlbplay.py v=bos j=05/13/11 n=1

To watch yesterday's KC condensed game,

$ ./mlbplay.py c=kc j=05/13/11

TEAMCODES from the README file:

You may still need to use mlblistings.py just to see what games are playing. But if you're a real fan of one team, you probably already know when your team is playing and when they have off days.


LIBRTMP

Also new in nexdef2011 branch is support for librtmp. Mplayer (and presumably vlc though I haven't tested it) has the option to build it with librtmp support so the flvstreamer/rtmpdump code is within mplayer rather than having to use both commands in a pipeline. To try it out, you'll likely need to checkout mplayer from SVN and ffmpeg from git. Instructions for both of these are on the web. To enable the feature in mlbviewer/mlbplay, add "use_librtmp=1" to your ~/.mlb/config file. If you are getting "Access denied" errors from what looks like the rtmpdump/flvstreamer code, your librtmp wasn't built correctly. You may also need to checkout a recent rtmpdump, build, and run a make install and make sure the librtmp.so library is installed. I'll have better instructions for this later. This is mostly for those of you who already know how to checkout, build, install, and Google for help and want to try something different.

hi guys! a little offtopic question.

Anybody knows how to get, through Yahoo Pipes or any other stuff, a feed rss of this page: http://mlb.mlb.com/search/media.jsp?...ey=reebok_flex

i'd like to have an everyday link via rss of the best defensive plays of the day..

Is it possible to run mlbviewer on an Android device? If so, does anyone have a step-by-step?

This is not supported and not encouraged for the simple reason that MLB.TV exists in the app store for most mobile devices and mobile operating systems. Providing a mobile version of mlbviewer would threaten their mobile revenue stream. It has been stated policy that mlbviewer should only provide what a user has paid MLB.TV for and not grant any services or privileges beyond what their subscription entitles them to. And quite frankly, as an iPhone MLB.TV user, I think they have done a better job with their app than I could do with mlbviewer.

One more thing, if you find a way to do it, please don't tell me about it and please don't publish any instructions in this forum. If you want to publish instructions, please don't associate your efforts with the mlbviewer project.

Thanks!
Matthew
(mlbviewer maintainer)

Are you talking about the MLB At Bat app? If so, for most Android phones it only provides live audio. A select few phones (namely, those with processors that can run Flash) can see live video, but for the most part it is audio only, unlike the iPhone's version. But it's the same price whether you can get live video or only live audio. I am not a lawyer, but in my opinion if you have purchased the MLB At Bat 2011 app, then you would not be robbing MLB of any revenue if you manage to get live video working on a phone that the app itself does not support (like the LG Optimus S in my case). Ideally a mlbviewer Android implementation would somehow check to see if that app is purchased before continuing, but I'm not sure how that could be forced.

That being said, I understand you not wanting anything to do with it, either by working on it or by having it discussed in this thread.

I am a lawyer, and I do not think there are any legal problems with doing it even if you haven't paid for the MLB At Bat app. There's legal precedent out there for the proposition that "place shifting" does not violate copyright, similar to the way the Betamax case from another era said that "time shifting" does not violate copyright.

Unfortunately, the reason such uses are frowned upon is not a legal reason but a practical one. MLBAM could make it impossible for apps like mlbviewer to work at all. They know we exist and have even been somewhat helpful in the past, but if they suspect we are cutting into the profit stream, that ambivalence will probably turn into hostility quicker than you can say "new RTMP handshake." So the SOP right now involves continuing to fly under the radar and not making any waves.

Unrelated, but... can you believe Big Papi is batting .302 on the season???

i got a "Nexdef reports that requested stream is not available" error.. what can be?

Nexdef isn't really supported yet this year. They made a change to the plugin last year (e.g. autobahn.jar) that has made it not so great since last year. It's probably a combination of the change and a bug in mplayer/ffmpeg but it would be hard to reproduce it for mplayer/ffmpeg team to fix. Anyway, I've been experimenting with another approach but that's not ready yet. If you really want Nexdef, you have two options. You can look for the NEXDEF-2010.txt file in the svn archives on sourceforge.net but don't be surprised if it doesn't work. Or you can use the flash player on the website (also using the autobahn.jar.)

Or you can wait it out and I might have something next month.

I have been using the nexdef2011 branch of the svn and it works great. It looks like the nexdef (autobahn.jar) is working for live games as the resolution seems quite good and the streaming is quite steady and reliable. I am using a Gentoo distribution & the latest mplayer2 available for it.

I am working on an ebuild for mlbviewer so it can be installed on Gentoo in the standard way. Now it is looking for a file: "setup.py". If I write the code for this standard python install/uninstall script, could it be included in the nexdef2011 branch of the svn?

I actually discourage installation in a global sense. We tried this back when mlbviewer was much simpler. As it has evolved, I have found that the combination of frequent svn updates and a global install was causing confusion. People thought they were running the update but the library was still the last one they installed. If it's something just for yourself, then have at it with the understanding that it's your responsibility to keep the global install updated with each svn update you download.

Also, I'm not sure what exactly you mean by working on an ebuild. Is this something just for your own use or do you plan to submit it to portage? I am requesting that you don't submit it to portage. I have a hard enough time keeping the official sourceforge download updated without having to worry about whether a distribution is including an obsolete update in their package management system. It has been my experience that Linux users who are paying for MLB.TV are not having too much trouble finding and downloading mlbviewer. Even the newbies figure out svn pretty quickly to stay updated.

I originally started this for my own use and entertainment, but I had hoped others would find it useful too. I won't submit it to portage. I have passed it on to one other person and will pass your wishes on to him as well. Running the ebuild causes a fresh copy of the svn to be downloaded thus making it easy for me to keep the latest version in a fixed location on my machines. On a gentoo system it is almost always desirable to install software using portage with an emerge command. The setup.py would never have needed to go on a non-gentoo system.

If there is something else I could do that might be of more use perhaps you could point me in the right direction.

So we've ported mlbviewer to an XBMC plugin, and it's working great. But a user said he compared the video quality and network bandwitch usage between the 1800k feed from the mlbviewer-based XBMC plugin and the "official" Boxee MLB.TV plugin, and concluded that the Boxee plugin looks better and uses more bandwidth.

I've played with the Boxee plugin and I am almost certain that it uses the same RTMP direct-stream access mlbviewer does. In other words, it's not embedding the Flash player like other Boxee apps do. So is there now a higher-quality stream available than 1800k? Or is it possible that the Boxee app is working with NexDef? If the latter, I'll try to grab the latest source for the Boxee app. Maybe we could reverse engineer NexDef support from that?

I know in the past, boxee (or xbmc?) used an embedded flash plugin to support mlb.tv. The highest quality stream for non-nexdef is 1800 according to the grid listings. Nexdef provides a 2200, 3000, and new to this year, a 4500 (4800?? don't remember) stream. Unfortunately, in past years, the nexdef plugin acted as an rtmp to http proxy where the plugin did all the buffering and stream management work before compiling an http stream. Sometime last year, the nexdef plugin became an rtmp to rtmp proxy (HTTP Live Stream or HLS.) Furthermore, the strict=true flag that used to work to tell the plugin only the chosen stream is acceptable no longer seems to be supported (or respected.)

I believe there is an mplayer (ffmpeg) bug that does not like the stream changing operation of nexdef plugin. Thus, current nexdef operation only works as long as the stream does not change bandwidth. I had begun work on a native python solution to this problem but did not get very far before life took over. Perhaps I'll have more time soon to look into this.

I noticed the grid also contains a feed labeled CLOUD_WIRED, which I'd been assuming was for NexDef. But it looks like Boxee directly accesses that feed for playback in 720p. Here's a Boxee info log indicating as much:

http://pastebin.com/2p8k0m8U

The thing to note about that is that this log is from my Linux box, which is NOT running the NexDef plugin at all. Moreover, the MLB.TV app for Boxee does not appear to package a separate version of it. And in any case, you'll note that the Boxee player uses ffmpeg for playback. So whatever Boxee is doing to "get at" the streams, mplayer should be able to handle it.