yup that's the same error i'm getting. it means you've logged into mlb.tv too many times in an alloted time period. if you were to try the website right now, it would tell you the same thing and not let you watch/listen to anything!

(homer simpson voice)that's hoooow they geeetcha!!

I was successfully listening to Gameday audio via the web site. Then while still listening I tried mlbdvr.py, Sign-on Restriction Error. Closed out of the game I was listening to, tried mlbdvr.py, Sign-on Restriction Error. Then I clicked back on Gameday audio via the web site and the audio stream resumed. Strange.

Gotcha. To my surprise, this actually doesn't work. mplayer spews network errors and if a player window ever does appear, it doesn't play in real time. Buggy container problem rears its ugly head again.

But if you're going to work rtmpdump into the equation anyway, why bother writing the file to a web directory and pointing mplayer there rather than just pointing mplayer right at the local file?

You already had a valid cookie on the website. Log out of the website, then log back on and see what happens.

They don't have 720p feeds for every game. It depends on their source feed.

I signed out of the web site, cleared all my cookies, closed Firefox and tried Gameday audio via the site. It let me in and I'm listening right now.

If you mix and match the website with the mlbviewer tools (mlbdvr, mlbviewer, gamedayaudio, etc), the servers detect that you are using two different session keys. There might be a way to read firefox's cookies to synchronize the two but it's probably more work than it's worth. If the website is working for you, you can remove your mlbviewer cookies/session key:

This may or may not work. If it doesn't work, try logging out of the website. If logging out of the website and removing cookie/sessionkey still results in Sign-On Restriction (or status code -3500), then you'll just have to wait it out. I believe it's about 20 to 30 minutes this year. Not nearly as bad as the 24-hour concurrent use jail they had last year.

I plan on implementing real sessions with mlbviewer/mlbdvr where we login once when the application starts and logout when the application exits and remain logged in for all requests in between. This should cut down on the login/logout churn that might be pissing them off.

Even the regular flash player users are running into this so it can't be completely my fault.

Hmm, I started typing out my rational only to realize that mplayer actually makes no distinction in the command-line between:

and...

So the video_player command will work regardless of whether I dump it and play it or dump it and stream it.

I guess the next step is move all that nasty rtmpdump code into the library and return the /path/to/file.mp4 as the stream url for basic service. I've already got a parameter for use_nexdef in GameStream so I can select whether to return a nexdef url or a local filename. I'll see about merging the mlbdvr.py and mlbviewer.py code in the next couple of days (read this as, "I'm a stubborn code monkey and will probably get this done tonight even if I lose sleep over it." )

Now a better question is whether we can get mplayer/ffmpeg guys to continue improvements on the files so that we can get a decent experience whether it's dumped or streamed from nexdef?

I'm also having mixed luck on my lower end machine playing from nexdef and the dumpstream from nexdef was useless.

I just wish mplayer would support rtmp already.

I'm not convinced that setting max_bps alone is doing the trick. I'll be playing around with adding the control messages and seeing if we can lock on specific streams. I might do something like, based on your max_bps setting, I pick the largest stream size less than or equal to it and say that's the only stream I want to accept. That may not come until the weekend though.

My highest priority is to get mlbviewer and mlbdvr code merged so I only have to support mlbviewer again.

Does your low end machine have a spare PCI slot? :-D

I agree with all that and hope for the login/logout issues with mlbviewer to get resolved. I personally have been in mlb.tv "jail" all night since around 7:15 CST. I'm starting to wonder if I should call them up.

edit: ok, i am now totally confused. I've been trying to login on my laptop, and cannot do so in firefox or mlbviewer. I'm watching the end of the cardinals game on my desktop pc, just in mlb's viewer. it's playing fine. when I exit, I cannot use mlbviewer on the desktop, although it's not giving me the sign-on restriction, it just won't even connect to swarmcast:

No stream found to handle url http://local.swarmcast.net:8001/prot...2309usdohsodge (etc)



edit#2: now it appears nextdef is down for many streams, and they're also having audio problems.

It's a laptop. Think it will fit in the PCMCIA slot? :-D

I think that card is as powerful as the laptop itself (567 Mhz vs. 750 Mhz, and 512mb VRAM vs. 256 mb laptop memory.)

I'm actually contemplating replacing the mobo in my old higher end laptop (1.4 Ghz, 1 gb ram) even though I'd sacrifice a DVD-RW drive if I switched laptops. Might be a small compromise to make if I want to watch baseball without the stream burps that plagued me last year.

Great job with all the new updates. This is getting pretty sweet. I'm not able to save the streams with VLC yet, but I can play the mplayer saved streams .

Has anyone ever had problems with the ncurses hiding the typed input in the terminal after mlbviewer is quit? I use konsole on KDE 4.1.3 on Opensuse 11.1 x86_64. I've just ignored it to this point, I figured it was affecting other people, but this may not be the case.

Thanks again for everything.

I suspect konsole isn't behaving like a normal xterm so the curseswrapper function that is supposed to reset the terminal back to sane settings isn't working on konsole. Try mlbviewer within a proper xterm and see if you get the same result.

The h264 code needed to be patched in ffmpeg. You may need to file a bug report with VLC to get the patch integrated into vlc code.

I'm also hoping that vlc will improve their rtmp code to support command-line options for the connect/createStream parameters since these can't always be deduced from the rtmp url itself. But that's a fight for another day.

When I first implemented nexdef support, I set a start_time of the game start time for all games. This meant 'In Progress' games began from the start rather than the current time. (Boston game is currently in the 5th inning but if I select it in mlbviewer, I'll start from the first.)

In revision 168, for 'In Progress' games, I will pick up the game from the current position (from the 5th instead of the 1st in the Boston example.) As a convenience for anyone who liked the ability to pick it up from the start (and I admit I rather do like that...except for when nexdef craps out in the third and I don't want to watch the first three innings again), I added a config file option:

will pick up a live game from the first.

Also in revision 168, I've improved the highlight url selection to always choose the best quality available (which is usually 800K but sometimes only the 400K highlights are available.) I'm still looking for how to find the Game Recaps (without parsing actual web pages.)