MLB.TV in Linux

rjwood · 05-15-2009, 11:32 AM

That worked...Thanks

daftcat · 05-15-2009, 01:16 PM

Reposting this because of "thread scroll". Everyone will need to either update to SVN revision 203 (or later) or Sourceforge release 0.1alpha11. Please do this and READ these instructions before reporting any problems.

Before you report that you are getting "What happened here?" or "Uncaught error" errors, update to SVN revision 203. With this revision, you will need to copy MediaService.xsd to ~/.mlb and remove your suds cache. You MUST do this even if you did this when you installed mlbviewer. This file has been patched five minutes ago.

Code:

$ cp MediaService.xsd ~/.mlb
$ rm -r /tmp/suds

Instructions to update to SVN revision 203.

If you have already checked out mlbviewer using svn once before:

Code:

$ cd mlbviewer
$ svn up

(That might be mlbviewer-svn for some users who followed my recommendation to keep svn directories of mlbviewer separate from downloaded releases.)

If you have never checked out mlbviewer from svn:

Code:

$ cd ~/
$ svn co https://mlbviewer.svn.sourceforge.net/svnroot/mlbviewer/trunk mlbviewer-svn

You will now have a directory named mlbviewer-svn (do not mix this with your downloaded mlbviewer release directory.) You can get subsequent updates by performing the svn up procedure above from within that directory.

I will also post a new release to Sourceforge shortly. I was going to wait until Monday when I had a chance to fix up the login code but without this patch, nothing will work.

jeremybub · 05-15-2009, 01:19 PM

I don't know if I am in the blackout region, but I will try some other games and see if I get better luck.

daftcat · 05-15-2009, 01:53 PM

Quote:

Originally Posted by jeremybub

I don't know if I am in the blackout region, but I will try some other games and see if I get better luck.

They used to put return blackout in the status of the SOAP message (the URL location message.) That seems to have disappeared from recent server responses. It is also returned in the blackoutStatus field of the SOAP replies, but I'll have to do more testing before I use that field.

In the meantime, one question and one request.

1. Where are you located geographically?

2. Can you try the stdout.py method I posted above the next time you get an error so I can see the SOAP replies? stdout.py takes a event-id which takes the form of 14-<gameid>-<year>-<month>-<day> and will look something like 14-244726-2009-05-15.

To locate the event-id, use the mlblistings.py script:

Code:

$ ./mlblistings.py
MLB.TV Listings for 5/15/2009
PO: 11:20 AM: 2009/05/15/houmlb-chnmlb-1 E:                 None
 P:  4:05 PM: 2009/05/15/colmlb-pitmlb-1 E: 14-244726-2009-05-15
 P:  4:05 PM: 2009/05/15/minmlb-nyamlb-1 E: 14-244730-2009-05-15
 P:  4:05 PM: 2009/05/15/oakmlb-detmlb-1 E: 14-244732-2009-05-15
 P:  4:05 PM: 2009/05/15/phimlb-wasmlb-1 E: 14-244733-2009-05-15
 P:  4:07 PM: 2009/05/15/chamlb-tormlb-1 E: 14-244723-2009-05-15
 P:  4:10 PM: 2009/05/15/lanmlb-flomlb-1 E: 14-244728-2009-05-15
 P:  4:30 PM: 2009/05/15/arimlb-atlmlb-1 E: 14-244720-2009-05-15
 P:  4:38 PM: 2009/05/15/clemlb-tbamlb-1 E: 14-244725-2009-05-15
 P:  5:05 PM: 2009/05/15/anamlb-texmlb-1 E: 14-244719-2009-05-15
 P:  5:10 PM: 2009/05/15/balmlb-kcamlb-1 E: 14-244721-2009-05-15
 P:  5:15 PM: 2009/05/15/milmlb-slnmlb-1 E: 14-244729-2009-05-15
 P:  7:05 PM: 2009/05/15/cinmlb-sdnmlb-1 E: 14-244724-2009-05-15
 P:  7:10 PM: 2009/05/15/bosmlb-seamlb-1 E: 14-244722-2009-05-15
 P:  7:15 PM: 2009/05/15/nynmlb-sfnmlb-1 E: 14-244731-2009-05-15

Then use the number following E: corresponding to the game you want to watch with stdout.py as follows:

Code:

$ test/stdout.py 14-244731-2009-05-15 | tee soaplog.txt

Then post the contents of soaplog.txt to pastebin.com.

If you could actually test with the Mets-Giants game tonight while it's live, that would be even better since blackout rules don't apply to archived games. I could probably tell you from the SOAP replies if the cause of the failure is due to blackout and it would confirm my interpretation of the blackoutStatus field in the replies.

In other words, if you can do this for me and repeat last night's result complete with a log of the server replies, I should be able to get mlbviewer patched with the proper "You are blacked out from watching this game." error message instead of what you experienced last night.

Thanks!

Moon · 05-15-2009, 02:26 PM

Quote:

Originally Posted by Moon

1) Rather than copy *.xsd from ~/mlbviewer-svn to ~/.mlb on first installation, I used softlinks, like so:

Code:

cd ~/.mlb
ln -s ~/mlbviewer-svn/*xsd ./

Oops! As it turns out, what I actually did back then was this:

Code:

cd ~/.mlb
ln -s ~/mlbviewer-svn/Media* ./

Only one of the two files being linked to actually ends in ".xsd", so my original post's method wouldn't have created both of the symlinks needed.

poorboywilly · 05-16-2009, 01:08 PM

So I decided to go on a witch hunt to find the cause of the destroyed shell mlbviewer was leaving me with, be it bug in python-curses, KDE/opensuse, or mlbviewer. Well I've slayed that dragon (I must be mixing up my metaphors) because it turns out in the "mainloop" function, which is called by curses.wrapper and passed "main window ‘stdscr’ as its first argument" (take from python docs) which is referenced in mlbviewer.py by "myscr". Then, on line 176, "myscr" is assigned to reference the returned window from curses.initscr():

Code:

  myscr = curses.initscr()

Removing this unnecessary assignment fixes the shell-destroying. There is also some unneeded cleanup code still remaining in the quit section starting on line 1414, namely

Code:

    curses.nocbreak()
    myscr.keypad(0)
    curses.echo()

which are things that the curses.wrapper will do on exit too, but these calls are idempotent so that's not a big deal.

What I don't know is why this didn't seem to affect anyone else. Taken also from the python docs, curses.initscr() "Initialize[s] the library. Returns a WindowObject which represents the whole screen". It doesn't state anything about calling it twice being a bad idea. However, in some curses documentation I found, it does say "Portable applications must not call initscr(CURSES) twice". I don't know what a portable application is.

Anyways, it's not as inconvenient to quit/restart mlbviewer now, so that makes me happy.

daftcat · 05-16-2009, 03:46 PM

Quote:

Originally Posted by poorboywilly

So I decided to go on a witch hunt to find the cause of the destroyed shell mlbviewer was leaving me with, be it bug in python-curses, KDE/opensuse, or mlbviewer. Well I've slayed that dragon (I must be mixing up my metaphors) because it turns out in the "mainloop" function, which is called by curses.wrapper and passed "main window ‘stdscr’ as its first argument" (take from python docs) which is referenced in mlbviewer.py by "myscr". Then, on line 176, "myscr" is assigned to reference the returned window from curses.initscr():

Code:

  myscr = curses.initscr()

Removing this unnecessary assignment fixes the shell-destroying. There is also some unneeded cleanup code still remaining in the quit section starting on line 1414, namely

Code:

    curses.nocbreak()
    myscr.keypad(0)
    curses.echo()

which are things that the curses.wrapper will do on exit too, but these calls are idempotent so that's not a big deal.

What I don't know is why this didn't seem to affect anyone else. Taken also from the python docs, curses.initscr() "Initialize[s] the library. Returns a WindowObject which represents the whole screen". It doesn't state anything about calling it twice being a bad idea. However, in some curses documentation I found, it does say "Portable applications must not call initscr(CURSES) twice". I don't know what a portable application is.

Anyways, it's not as inconvenient to quit/restart mlbviewer now, so that makes me happy.

Good find. At first test, it appears the initscr() is redundant. I'll look up the curses.wrapper function and find out what exactly it is doing for us.

Wolfvorkian · 05-16-2009, 06:27 PM

Good work poorboywilly. The terminal has always locked up for me but I never considered it enough of an annoyance to mention it. But after your fix, it now works fine.

The sync for me though has been worse than terrible today. Every stream I've tried, the audio has been ahead of the video. Not by the normal 1 second but at times maybe a half minute. It was so bad this morning that being the Sox-Jays were on WGN, I suffered the Hawk.

I also tested by using the flash player. No sync problem there.

poorboywilly · 05-16-2009, 06:42 PM

Quote:

Originally Posted by Wolfvorkian

Good work poorboywilly. The terminal has always locked up for me but I never considered it enough of an annoyance to mention it. But after your fix, it now works fine.

The sync for me though has been worse than terrible today. Every stream I've tried, the audio has been ahead of the video. Not by the normal 1 second but at times maybe a half minute. It was so bad this morning that being the Sox-Jays were on WGN, I suffered the Hawk.

I also tested by using the flash player. No sync problem there.

Cool I'm glad it worked out for you. My games is blacked out, and local Fox Sports is playing Poker instead of the game (although they teased me with the pregame), so just gameday audio for me today...

daftcat · 05-16-2009, 11:29 PM

Quote:

Originally Posted by Wolfvorkian

Good work poorboywilly. The terminal has always locked up for me but I never considered it enough of an annoyance to mention it. But after your fix, it now works fine.

The sync for me though has been worse than terrible today. Every stream I've tried, the audio has been ahead of the video. Not by the normal 1 second but at times maybe a half minute. It was so bad this morning that being the Sox-Jays were on WGN, I suffered the Hawk.

I also tested by using the flash player. No sync problem there.

Try restarting nexdef or sometimes just restarting the stream works for me. I watched the last of the Yankees-Min game, Oak-Det was blacked out for me, the Royals game, and now I'm watching the Bos-Sea game. I had to restart the Royals stream a couple of times to fix the one second sync but didn't notice any big sync issues.

My guess is that your nexdef needs a boot to the head.

Wolfvorkian · 05-17-2009, 02:46 AM

Quote:

Originally Posted by daftcat

Try restarting nexdef or sometimes just restarting the stream works for me. I watched the last of the Yankees-Min game, Oak-Det was blacked out for me, the Royals game, and now I'm watching the Bos-Sea game. I had to restart the Royals stream a couple of times to fix the one second sync but didn't notice any big sync issues.

My guess is that your nexdef needs a boot to the head.

Whatever it is, it is getting worse. I did some googling on the issue and this is not an unknown problem with Mplayer. In fact it is a common complaint. A lot of hits, a lot of advice and seemingly few solutions.

Maybe I'll downgrade my Mplayer as I'm using the very latest svn build and the sync issue is worse than ever. Course maybe tomorrow, everything will be back to normal too.

The way the Sox are going this year, I may be selling my password for a dime on the dollar anyhow.

I just used mlbdvr to capture the game that was so far out of sync this morning it was unwatchable and it played flawlessly with Mplayer. So it seems like there is something about autobahn that Mplayer doesn't like or vice versa. Duh!

daftcat · 05-17-2009, 12:31 PM

So I'm subscribed to the rtmpdump support forums and there was a bug that came across about messed up framerates. The developer replied that it was fixed in the newly minted rtmpdump 1.6 (released last night.) I thought, "what the hell? I've been rebuilding mplayer almost daily, so why not try a new rtmpdump?"

Good news #1:

The patches supplied in rtmpdump-patches works with version 1.6.

Good news #2:

Whatever the developer fixed in v1.6 fixed the problems mplayer was having with the non-NexDef stream. I can now watch the game and it's in sync!

Good news #3:

No new code needs to go into mlbviewer for rtmpdump v1.6. That means you can download rtmpdump v1.6 from sourceforge right now. Patch it with the Patch.sh script in rtmpdump-patches directory of mlbviewer. Build and install rtmpdump and you're watching live non-NexDef games in under 15 minutes.

I still prefer the NexDef streams but at least I have the fallback option when NexDef goes wacky.

daftcat · 05-17-2009, 01:02 PM

I have to say, I'm almost a bit jealous of the non-NexDef stream. It seeks a helluva lot easier than the NexDef stream. Of course, when it's working, the NexDef stream beats the non-NexDef stream all up and down the sandlot. And the jump to inning feature is indispensable now.

daftcat · 05-17-2009, 01:05 PM

Quote:

Originally Posted by daftcat

So I'm subscribed to the rtmpdump support forums and there was a bug that came across about messed up framerates. The developer replied that it was fixed in the newly minted rtmpdump 1.6 (released last night.) I thought, "what the hell? I've been rebuilding mplayer almost daily, so why not try a new rtmpdump?"

Good news #1:

The patches supplied in rtmpdump-patches works with version 1.6.

Good news #2:

Whatever the developer fixed in v1.6 fixed the problems mplayer was having with the non-NexDef stream. I can now watch the game and it's in sync!

Good news #3:

No new code needs to go into mlbviewer for rtmpdump v1.6. That means you can download rtmpdump v1.6 from sourceforge right now. Patch it with the Patch.sh script in rtmpdump-patches directory of mlbviewer. Build and install rtmpdump and you're watching live non-NexDef games in under 15 minutes.

I still prefer the NexDef streams but at least I have the fallback option when NexDef goes wacky.

Please confirm this for me before I make an official announcement on Sourceforge.

daftcat · 05-17-2009, 01:26 PM

Quote:

Originally Posted by Wolfvorkian

Whatever it is, it is getting worse. I did some googling on the issue and this is not an unknown problem with Mplayer. In fact it is a common complaint. A lot of hits, a lot of advice and seemingly few solutions.

Maybe I'll downgrade my Mplayer as I'm using the very latest svn build and the sync issue is worse than ever. Course maybe tomorrow, everything will be back to normal too.

The way the Sox are going this year, I may be selling my password for a dime on the dollar anyhow.

I just used mlbdvr to capture the game that was so far out of sync this morning it was unwatchable and it played flawlessly with Mplayer. So it seems like there is something about autobahn that Mplayer doesn't like or vice versa. Duh!

Have you tried:

1. Restarting the stream when the stream is out of sync
2. Restart autobahn if 1 doesn't fix it
3. Add autosync and really-quiet to your mplayer command-line.
4. Reduce your stream speed. If 2200 is way out of sync, try the 1200 stream.

You may be pushing the limits of what your machine can handle. My poor little Thinkpad T20, 750x256 can't do anything more than 800K (I might be able to get 1200 out of it with a memory upgrade but older memory ain't cheap.) My other Thinkpad, 1.5x1.5 can do 2200K but it never liked the 3000K streams.