This is a script I whipped up last season to see what bps I was getting. I would fire it up during periods of sluggishness to see if it was network or application that was causing hiccups.

It takes a read off ifconfig packet stats every five seconds and calculates that interval's average bps value. Ideally, this should be right around what you are expecting from the stream (in our case, 800000) but networks being what they are, it can burst higher or lower in a given interval. The amount of cache you use should be able to handle this burstiness.

It should also be apparent that you shouldn't really use your internet connection for anything else when you run this script or you'll get that bandwidth included in the interval averages.

daftcat, lifesaver... thanks for your ideas. here is what i got on my
acer 291 lci, 1.4 ghz, 512 mb ram, running on ubuntu 9.10 karmic koala
also, i am on a wifi connection i share with my partner.

didn't work, mlbvieewer went back to the game window, telling me that writing didn't work, closing connection

exiting telling me it didn't find audio and video drivers.

so far this seems to be working very smoothly. the file name is great to locate, it plays smoothly, so it seems to do anything i would like it to do. sweet.

anyway, i still was able to watch the debut of german mets prospect kai gronauer in a spring training game. first german to ever attend a spring training, and his first game in a mets uniform. exciting, exciting!

thanks, thanks!
markus

The second one is telling. You might pick a weekend to sit down and mess with building mplayer from source. Tweak the ./configure parameters until you get alsa and xv enabled. There are other options that I don't remember that you'll want as well. I hope I put some of that into the REQUIREMENTS file.

But if the third is working for you and you have the disk to spare (about 1 GB for an 800K game and obviously a lot more when we get into the higher quality streams) then stick with that for awhile.

One of the flexibilities of that video_player command is that you can build a private mplayer in your home directory and then put the full path to that in your video_player without messing up your globally installed mplayer.

Example:
Once you're happy with that result, you could run "sudo make install" to install it globally. In the meantime, you can keep the dumpstream option commented/uncommented so you don't miss any action while you're tweaking the best performance out of your system. Mplayer website also has an extensive section in their documentation about tuning your mplayer and system for best performance.

in mlbviewers of the past, the stream could be viewed with VLC player as well... I can't check because I don't have vlc installed at the command line (i'm on snow leopard)... it's installable through synaptic.

I would suggest trying to install vlc, and changing simply to

video_player=vlc

see if that plays or not. daftcat or other users can probably shed some more light whether this will still work

Heard rumors but never personally had vlc work with the new h264 streams from last year. I hated (re)building vlc source and no matter what I did, it never seemed to pick up the newly patched and rebuilt shared libraries.

But perhaps the binaries have finally included the fixes the mplayer team had made for us last year in the shared code that vlc needed.

VLC works fine for the video streams we are getting from RTMP dump this year. For some reason it is having trouble with the gameday audio streams, which are oddly enough delivered in a FLV container with a video stream of undefined codec that doesn't contain any data. Not sure why it's like that.

It worked OK last year with the nexdef streams, it just stopped playing if the bitrate changed--so you had to start the stream, wait for it to ramp up to full rate (watch it crash), then restart it and you were home free. This of course assumes your connection (and MLB's service) was stable enough to keep the top stream flowing, else you would have to restart it. Annoying, but less annoying to me than building mplayer from source.

for me, as it looks right now, i have much less problems playing a stream with vlc as with my current version of mplayer. the problem being that mplayer apparently can't handle the framerate for the video that mlb.tv sends my way.

right now i really like the option of using mlbviewer with dumpstream and then playing the output file with vlc, but a test this morning (i am in central europe) with vlc player in the video_player-line gave a steady stream without the hiccups mplayer has.

of course this is only testing for me with archived streams, so whether i will have any new problems will have to be seen.

thanks everyone!
markus

vlc player on snow leopard, not built from GIT, just using the basic installed from videolan SORT of works...

I changed the config to: video_player=/Applications/VLC.app/Contents/MacOS/VLC

it plays properly for about 30 seconds, then stops working with error:

[flv @ 0x8a9a10]negative cts, previous timestamps might be wrong
30164.133 kB / 307.74 sec (2.6%)[flv @ 0x8a9a10]Unsupported video codec (8)
[flv @ 0x8a9a10]negative cts, previous timestamps might be wrong
AVC: nal size 1585432512
no frame!
3

my mplayer works flawlessly, but VLC seems to be giving me some problems. any ideas? It's not a huge concern but I would like to know. There may be others trying to run mlbviewer on their Macs

edit: reading poorboywilly's post, could it be it was changing bitrates and stopped working?

I found this thread yesterday while troubleshooting mlb.com audio. Besides rebooting, not sure what I did, but I'm listening to games just fine today using Firefox in ubuntu 9.10. *fingers crossed*

I had started installing mlbviewer but pulled up after reading all of the manual config steps. I was figuring just to wait until the season started and mlb.com and mlbviewer worked out the kinks. Hopefully now I won't need it we'll see.

Sorry, don't know much anything about the mac, don't know if I can help. My information regarding the changing bitrates only applies to the nexdef streams. AFAIK, the nexdef application was some sort of p2p type framework, and it adjusted the bitrate down if the player ran out of buffered material to play. It would also adjust the bitrate on manual command.

However, so far in spring training all the games have been delivered in the "standard" mlb.tv format (that is, not the "premium" subscription or nexdef formats), and mlbviewer uses RTMPdump to grab these streams. The bitrate of the stream that RTMPdump fetches is determined before the stream starts and cannot be changed without stopping the stream and selecting a new bitrate.

So, to make a really long answer short, no I don't think you are experiencing the changing bitrate issue I described.

For audio only, there really is no need for mlbviewer (unless you are allergic to Flash.) It excels better at video. Though I know there are a few users who prefer the mlbviewer interface even for audio.

Won't know what this season will be like compared to last, but I presume it's going to similar, if not identical. In any case, there will likely always be a number of manual steps for mlbviewer. The good news is you'll likely only have to go through them once.

It is probably a good call on your part to wait until the regular season starts to see what mlb.com is going to do with the service for the new year.

Besides, some of us are Linux old-timers. For us, it's not even worth doing if it doesn't require frustrating manual configuration.

I'd like to see if it's possible to write some sort of rudimentary web app to run on a machine running mlbviewer, so that a mobile phone/device could connect to the ap, select a game, and mlbviewer would grab the gameday audio, transcode, and stream it to the phone/device. I have an Android phone and it seems a bit extravagant to spend $15 on an app to get audio if I can do it another way with content I've already paid for.

LOL, that was hilarious Theophile .

Sounds intriguing. Can the Android connect to a local wireless network, or only through 3G? What bitrate can it manage in either case? Does it run some version of Chrome for its browser? Do you know what it uses to play multimedia? I assume Chrome can probably play audio if not video either itself or through a plugin.

It depends on the device, but I don't know of any Android phones that don't have wifi. I have the Nexus One and it has wifi and 3G (though no 3G network near me, so I'm EDGE only). The Nexus One can decode h264 so for video, I'm sure the high bitrate streams would work fine. For audio, it can decode AAC, including AAC+ and enhanced AAC+ (and of MP3 and Vorbis of course) so audio should be a piece of cake. The default Android broswer is a webkit broswer and as of Android 2.0, it supports HTML5.

I'm about to do a basic test, but my thinking is if I use mlbviewer to select an audio stream and use the mplayer dumpstream option to toss the file into the web root, simply pointing the Android browser at the file will fire up the media player and stream it. If so, the hardest part of my idea would simply be writing a basic web frontend for mlbviewer with a little "PLAY" button at the bottom. Of course, there are probably much more elegant ways of doing this (flvstreamer port, anyone?).

Yup. It works. About to mess with video.