Did you install rtmpdump after you built it? The Makefile doesn't have a 'make install' so you have to manually copy the rtmpdump executable to some place like /usr/bin.

Here was what my post was going to be, but it was too long.

http://pastebin.com/f2ffedccf

EDIT: About the makefile not having make install, that is exactly what I did...

sudo make install

and it printed out "cp rtmpdump /usr/bin/rtmpdump"

and then exited

I assumed that was the command it executed.

For #3, the backlight...

Use gconf-editor (type it in a command shell to bring up the GUI) and uncheck the following two settings:

apps -> gnome-power-manager -> ambient -> enable (uncheck this)
apps -> gnome-power-manager -> backlight -> enable (uncheck this)

Basically, your problem is a bug in some ACPI (mine and yours) where ambient is kicking in but you might as well tell gnome-power-manager not to manage the backlight at all (which is what the second one does.)

So VLC put out 1.0.0-rc-1, I've downloaded the win32 binaries and now sweet, sweet mlbviewer on windows, without compiling a thing!

It looks like it's working but you're just not waiting long enough.

It takes a moment for all that connect stuff to happen, and then mplayer has to fill its buffer to at least 20%. So if the -cache in your mplayer command is 8192, then it has to download at least 2048 bytes before mplayer will start playing.

So in the first one in that pastebin, everything was working fine but you left the -o - at the end which was saying to output to standard out and since there was nothing reading from that file, it failed and exited.

The second one worked because tee was capturing the standard out. In fact, if you ran mplayer over the tee'd file in the second one, I bet it would be the same result as the third one: a playable mp4 file.

So I'd say run stdout.py from your grandfather's house and it will probably work just fine if you give it enough time to load.

You probably have it working just fine through mlbviewer too but you didn't wait long enough. You can reduce the wait time by lowering the cache value.

By the way, if stdout.py works, you can write a script for your grandfather:

You'll probably have to teach your grandfather to run mlblistings.py just to find out what time he should run that script. You will probably also want to edit the mplayer line about 7 lines from the bottom of stdout.py to include -fs to start mplayer in full-screen mode.

Although, honestly, I think it would be easier to set up the configuration file with the following settings:

And teach him how to use the mlbviewer gui.

That all basically says don't bother with nexdef which is probably more than he needs and still quite a pain in the ass.

show_player_command=False means hide that big line of rtmpdump | mplayer which is probably more than he needs to know.

The video_player will start in fullscreen mode once the cache fills to about 1024 bytes (about 10 seconds.) You could even reduce the cache to 2048 to bring the startup time down to about 5 seconds.

The audio_follow means if the game is 'Local blackout' or 'National blackout' he can use the 'a' key instead of the 'Enter' key to listen to the radio broadcast. Audio_follow=nya means always choose the NY radio broadcast.

Favorite line says highlight whatever game the Yankees play in a different color from the rest so it stands out.

And finally, the x_display is a convenience for you. If you wanted to do this all over ssh for him, all you would need to do is make sure you type "xhost +" from his machine whenever you first log him in. That says, "allow all clients to connect to his X display." The xhost command only needs to be done once per X session. The x_display, if set in the config file means you can connect remotely over ssh and have the video display to his machine. You could also experiment with setting the x_display to your machine provided you have X-forwarding configured correctly. Though I've never tested mplayer/mlbviewer in this configuration so I can't guarantee that it would work. I do know, though, because I put that in for my specific setup, that setting x_display=:0.0 allows me to start games remotely through ssh (as long as I use "xhost +" on the remote machine from its local display.)

Thanks for all of the help!

The xbacklight fix provided by jeremy worked for me... I have since turned off the gnome power manager but I haven't checked to see if it's actually working (xbacklight is still on) -- now the program is fundamentally functional! Exciting!

My processor is an Intel T2060 at 1.6 GHz, 2 GB RAM, ~1 Mb DSL connection, shared among about four computers in a household -- I don't anticipate the highest def streams will work too well even once I can load them.

Here's my config: http://pastebin.com/m12525cb5

As long as I choose a non-NexDef option, mplayer currently starts just fine, but if I try a NexDef stream (with autobahn running), I get the following errors:

The stream loads, but mplayer dies after 15-30 seconds.

Cool beans!

I use Applian FLV Player on Windows mostly because the only time I use Windows is at work. I don't need full-screen because it would look like ass anyway at 400K or 164K (about the only speeds I feel comfortable streaming at without incurring the wrath of the IT department.)

Just to be on MLB's good side, let's keep this off the official support forums (that mlbviewer works with Windows.) I think they don't mind mlbviewer so much when they think that it's mostly a Linux application. If we were to show them that this homegrown app outstrips their Flash player, they might get a little sore over all those hours they put into it.

Okay, first, if you're on a 1 Mb DSL, you're not going to get anything but the 800K stream and below. You might be able to get the 1200K stream but that would suck up all the bandwidth in the household. So let's change your max_bps setting in the config file to 800000 (800,000):

which is actually the default so you can remove that line altogether.

You can try setting it to 1200000 (1.2 million) to see if you can get the 1200K stream. By the way, if all you can get is the 800K stream, that's the same as not using nexdef except you lose a few cool nexdef features like picking your coverage and jump to half innings (and instant archive.) My low end laptop, the one connected to the wall mount LCD and stereo can only handle the 800K stream but I still like using NexDef for these features. For example, I came home late tonight and was able to jump to the top of the 1st (effectively start the game from the beginning) even while the game was only 4.5 innings old. Without nexdef, I'd only be able to join the game in the 5th and have to wait for the game to finish and get archived if I wanted to start from the beginning.

So, try setting that max_bps to 800000 and see how you fare with it.

New rtmpdump 1.6 w/ patches + removing %s from .mlb/config file =

1) 800K streams working now, archived & live.
2) Gameday Audio working now, archived & live.

Nexdef streams, top plays, condensed games & jump-to-innings already worked.

Amazing. Just amazing.

Fixed %s support for non-nexdef.
Fixed 2008 support.

However, all that new code for handling coverage selection and HD indicator has broken the Bookmarks code. I guess that's the next fix but I may not get around to it for awhile.

hey I am trying to get the non-nextdef working in os x leopard. I have the regular nextdef working perfectly. . .

when I download rtmpdump 1.6, patch it, make clean and make, and put it in the /usr/local/bin directory, I still get "rtmpdump command not found" error...

when I install rtmpdump with macports, I get this error in mlbviewer:
any ideas? I'd really like the standard non-nextdef streams to work...

Sorry to cut in on this thread, but is this the longest thread ever for Linuxquestions?

Try putting the compiled rtmpdump in /usr/bin. You can't use the one in macports because it doesn't have my patch for live games. Speaking of which, make sure you run Patch.sh in rtmpdump-patches before you 'make' or run 'make clean' and then apply Patch.sh. The instructions are in REQUIREMENTS-2009.txt.

Probably not.

When I run stdout.py, I get this, with an archived game: http://pastebin.com/f8dbcdac Note that it just cuts out at the end and does nothing. There is nothing to wait for. No buffering, it gives me back a terminal. This is with xhost + run on his computer through vnc, and then x_display=:0.0

This is the EXACT same game which downlaos perfectly with soapevent.py.

When I try to run the command it prints out at the end, I get http://pastebin.com/f904ccbe

So regardless of what *should* be working, it doesn't work with mlbviewer, or stdout.py, in a terminal opened over vnc or one opened through ssh. Note that the second output is exactly what I posted before. The 0% line makes it look like it is downloading and I just need to wait more, but This time, just like last time, it prints it out but then cuts to a terminal (I.E. crashes).

In order to make sure I did it right, I deleted my config, ran mlbviewer, and then added in my username, password, autosync to mplayer, favorite team, x_display, video_follow=nya use_nexdef=False.

and, part of the problem may be that TEE IS MESSING THINGS UP. When I run ./test/stdout.py blah I get DIFFERENT OUTPUT than ./test/stdout.py blah | tee /tmp/blah.txt as in it is somehow messing with what I am seeing. If you can figure that out, that may help you debug, as currently, everything I run beside soapevent.py crashes and cuts back to the terminal, meaning it is impossible that the issue is I am not waiting long enough for streaming Everything I have posted is a log of a completed command, so stuff like 0.0% or whatever at the bottom does not mean it is streaming, because it crashed. The same is true for mlbviewer. It just fails and exits.