Corner stretching does no good.

Then I suspect the problem is as Theophile says and the problem is with the mplayer driver / video driver interaction. Check out his post at 4:27 to diagnose... I'm not sure what the fix is though.

Ooops! That's my fault. I decided this weekend to make it a quick and dirty "fix" where the internal speeds are still modeled as '400' and '800' but the actual speeds are 800 and 1200. So if you have '800' in your config file, it will actually be 1200 (the higher quality standard definition stream) in the code. I'll have a fix for this in the next day or two.

Theophile, can you do me a favor? For nexdef, can you comment the sys.exit() line at the bottom of test/nexdef.py and look at a stream or two (using mlblistings.py to get the event-id's)?

I tried this earlier this morning and it kind of worked except the stream was coming as 1280x1024 resolution and my laptops don't support that resolution. Is there a way to force a different resolution in mplayer? I will Firebug nexdef later tonight and see if there are ways to request specific streams from the start. Maybe a lower bitrate will force a more conservative resolution. I think the video_player line is coming from the top of the script rather than your config file so you may want to change that to dumpstream and have a look at what the video really is. We've had trouble before of what the attributes are purported to be aren't really what's in the file.

Hi, thanks for putting mlbviewer together and debugging it. Here are the problems I'm having:

- The video plays without sound (I'm running BSD, which could be responsible).
- I can intermittently get Gameday audio during a game, but usually not.
- The Gameday audio I can get (either archived or live) is in Spanish

Any suggestions?

EDIT: I can get Gameday audio during a game, if I'm willing to wait 15 minutes for the cache to fill. The obvious thing to do is change the cache size or play with cache-min for mplayer on the 'audio_player' line in my config file, but below 32 mlbviewer announces a failure and gives up, and playing with cache-min doesn't seem to do anything (and neither does going from '-cache 64' to '-cache 32' or '-nocache').

Curious what happened to the 400k streams... they were nice for my slow DSL connection.

I've been having fun experimenting with the cache-min value, as suggested a couple of pages back. I'm getting a lot less stuttering now.

It looks like they have every flavor of stream up to 1800K available to non-premium subscribers. I don't think I'll get to it for awhile (maybe this coming weekend), but I'd like to implement, at least for a quick fix, a high-low model where you can specify in your config file what should be your preference for high and low speed for non-premium subscribers. Maybe in your case, you might want your high-low to be 500 and 800 where someone else might want 1200 and 1800. Later I might implement all the speed choices.

Right now I have the code modeled after last year's 400/800 offering where 800K is the new 400 and 1200K is the new 800. I was so lazy when I made that change this afternoon that the config file option speed still needs to be either 400 or 800. Ooops!

Let me see what I can do over the next few days to get the other speeds available.

Because the flash player is still very much usable even on Linux (and BSD has linux-binary emulation), gameday audio is not a high priority for mlbviewer at the moment.

Having said that, when you're using mlbviewer, you are using rtmpdump to feed the stream to mplayer since mplayer still does not support native rtmp streaming (and for good reason: it's an ugly protocol!) I'm not sure if rtmpdump has a cache setting of its own.

I don't know why you would have to wait 15 minutes for gameday audio. I just tested -cache 64 and it started up right away.

If gameday audio works, I don't understand why you're not getting audio with video.

Try recording a short sample of yesterday's nyy-bos game with the following:

Once you have a few % of the game downloaded, you can Ctrl-C that and go to work on figuring out the mplayer command that will work best for BSD and for that audio/video combination.

I'm hoping Theophile will chime in here and help you with the details and debugging of getting mplayer to work for this file.

As for the Spanish language, um, it's a feature. Seriously, though, is it for all games or just one in particular? If you tell me which game you experienced this with, I can look into it in more detail.

The good news is that the basic architecture looks nearly identical to last year. I don't have to rewrite the listings, media location, and playback code like last year. And given where mlbviewer was last year at this time, my work load looks much lighter.

The bad news is that I don't have as much time this month as I did last April.

The following are my priorities (which may change daily):

1. Get nexdef working. May be easier said than done because I don't know if my laptops support the nexdef file resolutions. The other thing is that mlb.com looks like they don't quite have archives working yet. If my development time is limited to live games, I will probably only get to work on this code on the weekends.

2. Implement a better speed selection algorithm: probably expand the 'p' toggle to 128, 500, 800, 1200, and 1800. That said, I'm not sure how many of these mlb.tv will actually support for all games.

3. Highlights and condensed games. Don't expect these to work for awhile.

4. Sleep. Yeah, this one should be higher priority.

Yes, I get the same thing! It also happens with flvstreamer.

The flvstreamer/mplayer -dumpstream combination does reconnect and finish the download though. I'm talking about archived games here.

When watching it, playback stops at the spots where the download broke off. But you can skip past these spots and continue watching.

So, could you or anyone else help me with these questions:

• Is there a different tool that we can try to dump files than mplayer? Maybe mplayer is the problem, or maybe MLB, who knows right now.
• Is there a tool (for Linux or Windows) that runs through the finished mp4-file and repairs it, so that it can be watched in one run-through?

Thanks in advance for any help or advice you can give me or us. And since I will only use mlbviewer to download the 1200K/800K archived games and watch them, I'm already quite happy. Awesome job you did here. Thank you so much!

I appreciate how much work and research you put into this and I will definitely donate something to you. But I still hope I get the dumping of archived games working flawlessly

For archived games, it starts right up (although some of the recently archived games behave as if they're live, and take forever). Judging from the status bar at the bottom of the shell, it seems to wait until (it claims) it has 50,000-60,000 kB cached, no matter what I set -cache or -cache-min to.

Something went wrong - it terminated and the last few lines to stderr were
It's only some - for example, the Red Sox feed from Sunday's game, or the Mets feed or the Marlins feed from today. The Yankees feed from yesterday is in English.

Thanks!

For audio caching problem, I can try live game tomorrow. Can you do a 'ps -ef | grep mplayer' on it while it is taking forever to verify the audio_player command is as you expect it to be.

For the stdout.py tool, can you tee it to a file and post it to pastebin.com? e.g.

<event-id> is the number that follows E: in mlblistings.py output.

For the Spanish language bug, I think I have a fix. I'll have it checked in soon.

I'm guessing the servers themselves are trying to discourage stream downloaders by doing something like limiting the amount of bandwidth allocated to a client over a given period of time. If you use mplayer without -dumpstream, mplayer's cache management paces rtmpdump so it doesn't get kicked off the stream. With -dumpstream, the test/soapevent.py script has -resume added to the rtmpdump command so if you run the script I posted, it will pick up the download where it left off before it got kicked off. Putting the stdout.py script in a loop will progressively download the entire game. The first time through the loop, it grabs about 35-40%. The second time it resumes where it left off and downloads to about 85%. The last time it grabs the last 15%.

I'm not sure what you mean by stitching the finished mp4 together. Are you saying that you have run the test tool (or the script I provided) and it created "dead spots" in the file where the playback gets interrupted where the stream resumes occur? If this is the case, you'll need Theophile's media expertise to help you debug and fix this.

As far as I know, rtmpdump/flvstreamer are the only rtmp streamer tools for linux. Vlc has some rtmp support but it's not very good. I also don't like telling my users they all have to use vlc when most of us have much better luck getting mplayer to work with those FLV files.

At some point in the future, I can implement a language preference. For now, this code rejects all alternate audio feeds.

If you want alternative language support, please find a game using the mlb.com website that has the language you want and tell me which game this is. I need to see the debug output using the test tools to document the valid languages.

I've said it several times but it's worth repeating for the new folks who've joined the discussion.

I am very grateful for the patience and respect that you all show me.

When mlbtv service is having problems (like it does every April), I'll read the support forums to see if i can get an official word on what's working and what's not. I'm always shocked and disgusted by how those subscribers expect everything to work flawlessly from day one. Every year, it boils up to a lynch mob fervor in there.

I'd be out of here so fast if this discussion thread ever turned into that.

So thanks for hanging in there with me and we'll have it working as mlb.tv itself gets it together.