Can't really do anything about those.

The URL request is done in two parts. First, request a media listings based on the event-id. In these listings, there are media-items which have content-id's associated with them. The second request refers to a media-item by content-id and the reply contains the URL. The JiBX marshalling errors, the best I can come up with from Google, occur when they can't convert a json object into xml and in my testing, they have always occurred in the first request (e.g. the listings are borked on the server side.) The only thing I can think of is that they may be getting content-id's from a different source (perhaps from the json objects directly???) In this case, you have the 'f' key option. I can modify soapevent.py to skip the listings request if you have specified a content-id on the command-line. I'm not sure if this will actually help because the first and second soap requests and replies are virtually identical (same function call), with merely different arguments and reply objects.

Maybe this is one of those things that will get worked out with time.

I stand corrected. The JiBX errors are games that aren't yet archived. For reasons unknown to me, SWARMCLOUD streams (aka autobahn) are available immediately after game completes which, for you guys with Premium accounts running autobahn.jar means you can watch archived games before they are actually archived. You'll see MLB.TV Premium Archives in the Media Center, but the MLB.TV column will say "Soon". My algorithm for determining games that are archived wasn't checking which stream was in the "MEDIA_ARCHIVE" state, only that a particular content-id was in that state. I'll have this fixed in the next patch. This means, you'll see "(Archived)" next to games but making requests will result in "This game is not yet available in the archives." error message. This should be preferable to a JiBX error but likely no less annoying. Unfortunately, the listings where I read the media state to determine whether to tag on the "(Archived)" text, and the SOAP replies that say whether the state is MEDIA_DONE or MEDIA_ARCHIVE are not synchronized. I hope this is something that gets fixed with time. If you are a Premium subscriber, you can always use 'f' key with autobahn.jar running to watch an archive before it actually gets Archived.

haha, well I think the "error you're not anticipating" in this case is 'PEBKAC' :P I admittedly didn't read the readme file first and didn't copy over the MediaService files to ~/.mlb. Once I did that, I'm able to download the 600k stream (now using 12/04/2009 Jays vs Indians). However, as you noted in a later post, I'm not able to download the 800k stream, and get 'streamnotfound' in my rtmplog.

EDIT: Using SVN @157, I'm actually not able to access the 800k stream for *any* games from the 12th, and am now making my way through the games from the 11th and only joy for one game so far (NY/KC).

I think I have the JiBX marshalling error fixed. As I stated above, it seems the scenario content (e.g. MLB_FLASH_800K_STREAM) can be in several different media states but only MEDIA_ON and MEDIA_ARCHIVE are valid for mlbdvr.py use. The flash player however, if you are using the autobahn.jar, can access the SWARMCLOUD media stream which is available immediately after the game is over. This is why you'll occasionally find streams archived in the flash player that aren't available in mlbdvr. Occasionally, when you try to connect to one of these streams that is not yet archived for the MLB_FLASH_*00K_STREAM, you'll get a JiBX marshalling error (instead of a more proper Requested Media Not Found error.) With this revision, if you try to access one of these streams that is not yet archived, you will get a "Requested stream is not yet available" error message.

ALSO...

The LIRC code has started to act up on my system where it used to never get touched before. In the process, I found a couple of bugs and "fixed" them (but I actually have no LIRC setup to test with.) If the LIRC detection code continues to fail for me (e.g. I don't have LIRC so it shouldn't try to make a connection), I might add a disable_lirc config file option. In the meantime, if anyone is using LIRC with mlbviewer, can you please test and make sure I haven't screwed anything up?

FINALLY

National blackout is detected upon selecting a blacked out game. A "This game is subjected to national blackout restrictions" error is posted. If you live outside of the blackout region and are not able to connect to this stream because of this error, please use the event-id in soapevent.py and send me the full text of the soapevent.py output so I can determine how the blackout keywords appear in a non-blacked out region.

COMING SOON

Groundwork is in place for video and audio follow. It should be available sometime next week. It won't be perfect though because I'm relying on manually adding broadcast call letters to the TEAMCODES dictionary.

Looking good, but I assume that m.lb (line 1057) in MLBviewer/mlbtv.py is a typo.

Yes, but apparently, that's not necessary for the request. I might trim out some of those fields because that rec_cmd_str is filling my puny putty window.

Another interesting bit of information:

I took a .mp4 file created by rtmpdump from a live game and uploaded it to my webserver. My media gallery uses FlowPLayer (flash-based) and it was able to play back the video and audio no problem.

I think you're a lucky exception rather than the rule.

I'm going to start looking into flazr this week as a replacement for rtmpdump. At least the flazr developer has been more helpful and more responsive than the rtmpdump developer.

I don't think so. Take any file created by the soapevent.py script and the patched rtmpdump and run it through FLV Extract and mplayer will play the .264 and .aac files no problem (assuming it has support for x264 and aac).

rtmpdump was based in large part on code from the XBMC project. I've got someone over at the XBMC forums who works with rtmpdump looking at a sample file from MLB.TV. Hopefully he'll be able to shed some more light on the container/header issue. I honestly think this is a relatively simple fix.

Let's hope so. I don't doubt that there's a valid video file in there. I just think rtmpdump is making faulty assumptions about that video file when it writes to the disk. Anyone using a recent version of libavcodec is likely going to run into "no frame" errors. I meant you're lucky in that you probably have an older version of libavcodec (as evidenced by the "unsupported codec" errors you get) that doesn't mind the container issues and plays it anyway. It's just weird that archived streams work but live streams don't. Every time I try to make sense of that WriteStream() function, I end up passing out. It's a better sleep aid than NyQuil.

I will pass on the super beer 9000 to the XMBC guys if they can fix this. Heck, I might even contribute an XMBC module to them for their efforts. If only my headless box was speedy enough to run XMBC. Then again, I haven't tried it on Linux so it probably is a lot quicker than the Windows version.

I tested the theory and I think I see what you're saying. I've been doing my testing on my Ubuntu laptop with versions of libavcodec, ffmpeg, and mplayer from the Ubuntu 8.10 repos. But I have a bleeding edge ffmpeg, x264, and mplayer on my HTPC box and I get the "AVC: Consumed only 1 bytes instead of X" error you were talking about. It's odd. On my laptop, I can get video but no audio. On my HTPC, I can get audio but no video.

I'll keep playing with it and I'll report back if we figure anything out over at XBMC forums. Dissecting the video file will probably lead us to the source of the problem. Here's hoping. ;-)

Good news!

I found that the domain-specific-attributes have names to them after all and I found out how to get those names from the suds (SOAP) replies.

I can abandon the effort to document all the media outlets for a team and use the coverage-association attribute to implement video and audio follow. I might even add a [HOME] / [AWAY] indicator to the status bar to allow you to choose your feed on a game by game basis. That way if you have a problem with one feed, you can try the other without having to add a video_follow parameter. I haven't figured out the precedence though. I imagine I'll enforce video_follow whenever it is present in the config file but for games where neither team is present in the video_follow option, which ever stream you indicate ([HOME] or [AWAY]), I'll go with that. Same goes for audio_follow and audio stream selection.

This way, I will never have to listen to Hawk and DJ again!

DJ's off the TV broadcast this season (moved to radio). Steve Stone's his replacement, and is a pretty huge upgrade. I can understand the desire to rid your life of Hawk though!

Using rev. 157 and the 4/13 White Sox/Detroit archive is already up (so happy to be able to watch it without the official player). Seems like mlb.tv's early season issues have been ironed out a bit.

daftcat,

I know this is a low priority at the moment, but what are you current thoughts on the ability of mlbviewer to interact with Autobahn? Is there any chance of grabbing the SWARMCAST feeds or would that require major rewriting?

I can grab the "url" no problem. You can do that yourself with soapevent.py. Just ask for the SWARMCLOUD stream (whatever it's called in the listings.) I just don't know what to do with it. If you know how to "talk" to the autobahn and give it that character blob (whatever it means), let me know. In soapevent.py, you can put in a sys.exit() before I call the subprocess.Popen method (near the very bottom of the script) to exit before starting rtmpdump. You can "print game_url" (or grep where that statement occurs in the code and put a sys.exit() after it) to print out the char blob. Give it a go and let me know what you come up with. I'll have a read up on autobahn. Maybe my new mlb.com friend can provide some assistance if we can't work out on our own. I tossed him a softball this morning to see how responsive to questions he'll be (I asked him about 600K vs. 800K archive streams.)

This might be the answer to the live games question if we only have to mplayer off the autobahn port.