I think last year they was only for subscribers, but this year they have always been free.

I've made some progress on getting a xbmc/boxee plugin working. Should have some time to knock some more out this weekend.

Hi dols,

You emailed me about a couple of minor fixes but you didn't tell me which version you were working off of so my line numbers weren't matching up with yours. Can you tell me what version/revision you were referring to?

I guess when they first introduced CG's this year, they only supported the 1000K Flash. Now they have all these mobile phone formats and my lazy parsing was returning a 3GP URL.

I have fixed this to look specifically for the 1000K Flash.

I also found that the debug model of "show url but don't play it" wasn't working for CG's, so I fixed that too.

I'm enjoying a long overdue break from development but I'll look into supporting flvstreamer (and generating whatever patch set I need for it) as the replacement for rtmpdump. In the meantime, I unofficially encourage you to find your rtmpdump v1.6 wherever you can. We neither download the stream to disk nor use the RTMPE (encryption) protocol for MLB.TV support. So Adobe can bite me until I find the time to look over flvstreamer.

I still get the daily digest emails though if you uncover bugs like the CG issue.

mplayer has been quitting frequently on me; has anyone else had this problem, and is there any fix for it? I'm at the latest svn.

A screen shot of how I watch my games. Its on a 47 inch monitor. I like the colorful border. High Def, too.

Attached Thumbnails

 

This diff was against revision 206 of mlbtv.py. Let me know if you want context diff output.

I get constant breakups with the higher quality streams so many in fact I watch only the 800 stream and it is rock solid and the quality is good enough afaic. I seldom if ever have a break down using the non-nexdef but anything above that for my relatively slow 3M IP speed and ancient hardware just doesn't hack it. Plus I suspect the HD streams are a bit on the flakie side too.

One of the computer literate can probably give you a more definitive answer but I my guess is your problem has little to do with mplayer with the culprit more likely being MLB.

I'm also running the latest mplayer svn (like daftcat does, I've gotten into the habit of updating it daily), and the recent revisions definitely blow up more frequently with nexdef streams than the ones from more than a week ago did. Of course, it could be that the recent nexdef streams are the problem, and not the recent mplayer revisions. Like you, I find that the 800K streams do not usually crash mplayer. If the nexdef streams are "having a bad day", I'll switch to an RTMP one just to get through the game uninterrupted.

Another problem that I'm seeing with the recent mplayer revisions and the nexdef streams is no picture (black window, audio only) at the start; switching to a different stream in the mlbviewer window usually corrects this (and then going back to the original stream rate works fine), but sometimes after this procedure the audio sync is now sufficiently "off" that mplayer can't correct it. This lack of initial video doesn't happen with 800K streams, and it just started occurring with nexdef streams in the last week or so. I've tried dropping max_bps to 2200000 and removing -fs from the player command; neither config change prevents it.

So let me get this straight...using mplayer SVN, everyone else's player just switches video size when you use stream selection? Mine just crashes. I was thinking it was just VLC that was crashing but I finally svned the mplayer source and compiled it and sure enough it crashes on the switch too. WTF?

Lo and behold, increasing the mplayer cache from 4096 to 8192 seems to have fixed the lack of video at startup, and even the 3000K stream now usually fires up properly and with audio in sync. I'm still seeing the occasional stutter at launch that others have reported, but a (very) quick double-tap on the spacebar to pause & unpause it still fixes it nicely; it seems to work even better the faster you do it, AFAICT.

I've been testing with yesterday's archived games; we'll see later on if mplayer blows up any less frequently now when running today's live nexdef games while using the larger cache size.

One source of mplayer crashes that I had been having earlier on, based on the brief error message it would throw in the mlbviewer screen, was related to using the pulseaudio output module (Pulse is default on this distro, Mandriva 2008.1, and on many others as well). It compiled in OK, but just didn't work well, presumably due to it lacking whichever pulse-related patches the distro's own mplayer package gets. Making mplayer use ALSA instead fixed it, with '-ao alsa,' added to the mplayer command line (be sure to include the trailing comma, which means "if that module doesn't work for some reason, try something else").

Mplayer has a feature that I've found to be quite handy; you can make a config file for it (~/.mplayer/config) and put both your default *and* your special-case options in it (the latter are called "profiles"). This lets me use player commands like these in my mlbviewer config:

video_player = mplayer -profile mlb
audio_player = mplayer -profile mlb-a

And here's my current .mplayer/config file:

# Write your default config options here!
vo=xv
dr=1
autosync=30
framedrop=1
softvol=1
[mlb]
ao=alsa,
cache=8192
#fs=1
panscan=0.5
fixed-vo=1
really-quiet=1
geometry=800x450+112+159
[mlb-a]
vo=null
ao=alsa,
cache=256
really-quiet=1
[dvb]
xy=.5
delay=-0.1
cache=32768
#vf=pp
#autoq=50
panscan=1

Everything above the [mlb] line are the default options I want used for everything it plays, and then I have three profiles defined with additional ones: [mlb] for mlb video, [mlb-a] for mlb audio, and [dvb] for watching TV with my tuner card. Note that options like '-fs' and '-really-quiet' become 'fs=1' and 'really-quiet=1' in the config file.

By moving the mplayer options out of the mlbviewer config file, I can leave that file alone and make all my tweaks in the .mplayer/config file. The main benefit of this method that I can now quit mplayer but leave mlbviewer running, change my mplayer options (for example, uncommenting the 'fs=1' line within the [mlb] profile), and on next launch of mplayer by mlbviewer those new settings will be used without my having had to close and restart mlbviewer. I expect this setup to become even more useful once daftcat finishes work on the single-login code for mlbviewer, as this should insulate me even further from the dreaded "signed on too frequently" errors.

I found that the following options in the above .mplayer/config file appear to have helped in getting the stream switching under control:

fixed-vo=1
geometry=800x450+112+159

I run a 1024x768 monitor here, and that geometry option ensures a video window at 850x450 (the natural size of the 2200K stream), centered properly on my screen, no matter which of MLB's streams is being used to fill it. The fixed-vo option tells it to re-use that same window when the source input changes. Even when I have it defaulting to fullscreen, I can then switch over to windowed mode (say, to select a different stream rate) and have it behave consistently each time I do. It appears to be surviving through stream speed changes, both those that are manually requested and those that are the result of nexdef's adjustments, fairly smoothly since I went with these options.

Note that with or without these two settings, if you have mplayer defaulting to fullscreen launch (with '-fs' in the player command line in .mlb/config, or 'fs=1' in .mplayer/config), while you can then go into and out of windowed mode as needed once it's running, it will jump back into fullscreen whenever it notices any sort of burp in the stream; this will usually include any speed changes. Conversely, if you have it launching in windowed mode by default and then switch into fullscreen once it's running, it will revert to windowed mode on its own at each burp encountered.

No dice...it's not just jumping out of fullscreen, it is plain old crashing--i tried the fixed-vo and geometry settings and it still crashed.

Is anyone else running 64 bit?

It did much better than it had been doing before (in the one live game I've watched so far since increasing the cache size), but it still crashed twice - once about 10 minutes in, and then again in the bottom of the eighth. Definitely an improvement, though. 3000K stream, BTW.

One thing I'd love to see in mlbviewer is the ability to prevent it from automatically switching away from the stream selection screen and back to the listings one upon detection that mplayer has ended (perhaps with a config file option?). In those cases where mplayer has died and printed a potentially useful error message onto the bottom of the stream select screen, the listings screen redraws over it far too quickly to be able to read said message. Something like what's done on the top plays screen, where it asks you to type L to return to the listings before it continues on, would be ideal for troubleshooting purposes; the way it works now makes perfect sense as the default behavior, but not being able to change it temporarily does make troubleshooting mplayer crashes a bit trickier.

@poorboywilly: Sorry, all 32-bit OS and apps here (running on 64-bit hardware, but that's not particularly relevant). You might be on to something, though; I hope you get some feedback on this from others who are also running 64-bit mplayer svn builds along with mlbviewer.

Sorry if you've answere this before, but what video output method are you using? X11? Xv? XvMC? VDPAU?

The next question is what gfx hardware and drivers are you using?

I'm using a Radeon mobility chip with the open source radeon driver and xv on AMD64 and I haven't had any problems with crashing.