Theophile, unsupported codec means your libavcodec is out of date. You can try downloading a new copy of x264 and ffmpeg but that's never worked for me. I've always had to download and build a new copy of mplayer.

As for the media issues, the rtmpdump developer got back to me and he was less than helpful. I suspect there are some header or streaming issues that are lost on him when he's writing the stream to disk.

poorboywilly, yeah, I'm getting that too but luckily the sign-on restriction jail isn't 24 hours like it was last year. Sometimes it's as short as a few minutes. If you're combining mlb.com's website and mlbdvr, you might run into session-key conflicts where mlb.com thinks it already gave you a session key and you're using a different key. This is pure speculation. You could try deleting your sessionkey file in ~/.mlb, you can try using the website, or you can just wait it out.

berselius, if you are running it as "java -jar autobahn.jar" and getting that error, maybe you have a wrong version of java. I think it's supposed to be java 1.5.1 or newer. You can check with the "java -version" thread.

Just updated to revision 152. Still getting StreamNotFound on three games from 4/10 that play in flash. TEX@DET NYY@KC and PHI@COL. At least now mlbdvr reports that the operation was unsuccessful, but it's pretty strange that these games are just hidden somehow.

DevilWearsPrada, you get your own reply since your issue is not quite so easy.

Turns out the stream that works off mlb.com's website for 4/10 Rangers-Tigers is a 600K stream for the away stream, and 800K for the home stream. I hope this was just a temporary hack on their part. The larger problem is that I still haven't figured out how they know which is the home stream and which is the away stream from the SOAP response. There's a free-flow section of the response called domain-specific-attributes but there doesn't seem to be a particular order these attributes come in. Furthermore, how in the world am I supposed to know when they are using 600K streams because their 800K feed wasn't available?

A temporary solution is that I've logged the content-id's to ~/.mlb/log like so:

I've modified soapevent.py to take content-id as the third argument. For the Rangers-Tigers away stream, the 600K one that works on MLB.com (600K is not Premium! darn it!), you would do:

Normally (I would hope!), all archives will be the 800K stream.

The options available to us are:

1) an intermediate screen between 'Enter' and stream play that allows you to select which
content-id to play (this would be preferred if I could figure out an easy way to display the domain-specific-attributes--perhaps a prune list that removes some attributes that aren't informative and will hopefully result in just the call letters of the stream)
2) speed switching - you're stuck with the content-id my algorithm chooses but at least you could switch to a different speed if they pull this 800 vs 600 crap again
3) allow you to override content-id in soapevent.py

I've implemented #2 and #3 and I can work on #1. Maybe I'll ask my new MLB.com friend how to interpret the domain-specific-attributes.

I'm off to test the rest of your StreamNotFound errors.

Well now that I can watch live video, I just have to figure out how to put the audio with it. I am also wondering whether it would be possible to use mlbdvr.py in conjunction with autobahn.jar to pull down the full 720p feed. Is this even possible?

I don't understand how you are able to watch the video unless you've tricked mplayer into using a different codec than what's in the file.

No trickery necessary. I just played it. rtmpdump doesn't do any converting, it just dumps the data. As I mentioned previously, rtmpdump handles h264 video just fine. See also my posting of the output of mediainfo. The file identifies the video stream correctly.

There is some kind of strangeness, though, since it won't play back once rtmpdump stops capturing. Also I've not been able to remux the mp4 file because MP4Box identifies it as a .flv file which is unsupported. I think it's just a file header problem. But the video data is there.

It seems that MLB.com has been mixing 600K streams with 800K streams in their archives. There seems to be no way of knowing which will work either. So, to correct the StreamNotFound errors, I've implemented speed switching like last year. Everyone should be using 800K even if you're not a premium subscriber. This year, 800K is the basic support and all the premium features are in the nexdef plugin. To ensure you are using 800K, just put speed=800 in your config file. I'm also going to make this the default for new installations now. For those streams where the recorder returns right away with "Command completed.", if your /tmp/rtmpdump.log has a StreamNotFound error, you can toggle the speed setting with the 'p' key. This will make a request for the 600K stream.

I've tested this with all of the 4/10 games. There were a few that were not working as 800K but they did work as 600K. Only the Houston-St Louis game was not available with either 800K or 600K. Instead it was returning JiBX marshalling error. These I can do nothing about.

This is a temporary solution. Ideally, I'd like MLB.com to be consistent and always archive the 800K stream. In the meantime, I'll implement some kind of toggle to select the alternate stream. For now, I pull the first stream I find in the MEDIA_ON or MEDIA_ARCHIVE state. There doesn't seem to be any rhyme or reason about whether this is the home or away stream.

Tell me if you still have StreamNotFound errors and which games after you've tried with both the 800 and 600 stream.

Hey daftcat,

I recently came upon this thread (when I was initially looking for a way to use nhl gamecenter streams in linux!), and I have to say I'm impressed with all you guys have accomplished so far Also, you asked a question earlier about whether anyone would be interested in an nhl equivalent of mlbdvr/viewer - I know of a few Canucks here in Oz that would be!

Back on topic though, I'm also a baseball fan, and have given mlbdvr a go. For the 4/11/2009 Jays vs Indians game, I'm getting the following errors (for both 600/800k) on svn revision 154:

Followed by:

Thanks again for all your hard work - it's especially important to those of us who don't have an octo-core Nehalem required to play HD h.264 streams in flash on linux! >

Argh! I hate those Uncaught errors because it means there is an error happening that I'm not anticipating. When I anticipate an error, I can set the error string to something other than "Uncaught error" (which is the initialized error string.)

As for 'u' referenced before assignment, I believe I have that fixed in revision 155.

You might want to try that game again. I was able to get the 600k stream to work.

daftcat,

I can confirm the live video problem is simply a container problem. I used mlbdvr.py with the "z" key to get the game ID which I then passed to soapevent.py. This started rtmpdump which began recording the live game. I stopped it after a minute or so.

The resulting .mp4 file would not play in mplayer, even though it would while in the process of recording. However, mediainfo could still see the elemental streams.

I then used a Windows program called FLVExtract which demuxed the file into raw .264 and .aac streams which I remuxed to Matroska using mkvtools in Linux. The resulting .mkv file played fine, audio and video (though there were sync issues I think were related to framerates).

This means that rtmpdump is getting all the correct data, but I believe it is marking the file as flv rather than mp4 as it should.

Everything seems pretty awesome with rev 155. Big thanks to daftcat for being much more responsive than MLB.com's support staff.

Tangent: MLB's Media Center page lists the stations that provided the home and away feeds. Every time I see the listing for Royals games, I die a little inside. FSKC is a little too close to four letters nobody wants to see.

The SOAP response contains call letters of home and away feeds in the domain-specific-attributes. Except those dsa's have no rhyme or reason about the order in which they appear. The home and away team codes also appear in the dsa's but there's no logical way to associate the team codes with the call letters because both teams' code appears, often more than once in the dsa field. Perhaps the best I can do is use the first field of the TEAMCODES dictionary (that, until now) hasn't been used, for call letters. Only problem is that it's only one field. I could change a lot of code around to use two fields for both audio and video and then build a dictionary of TEAMCODES and call letters using that method to implement audio and video follow. The other option, which is probably more of a pain to the user, is to have the user specify the call letters instead of the team name. I'll look into expanding the TEAMCODES dictionary first. Heck, if I could sit down one night and build the entire teamcodes dictionary for minor league baseball last season, I could add 60 more codes to the teamcodes dictionary.

Yeah, FSKC caught my attention too.

I think it's more than just an flv trapped in an mp4's body (transgendered codecs anyone?) I think there's a subtlety of framing and perhaps even streaming h264 that the developer isn't aware of. The reason why I think this is because with a properly updated mplayer, the libavcodec module reports "Consumed only 1 bytes instead of 1926" (or however many bytes rtmpdump wrote as the frame size.) This seems to me like libavcodec is saying, "this frame really isn't valid." It would be great if I could find an H.264 decode module for wireshark even just to validate the header on the frames.

I want to implement some form of stream switching or audio/video follow and catch the last of the uncaught errors. Then I can focus more attention on the live streams. If I can learn a little java, I wouldn't mind moving to flazr instead of rtmpdump just because I find the developer of flazr a lot more helpful than the rtmpdump dude.

That error could also be caused by a confusion between where the keyframes actually are and where the player thinks they should be.

The question really comes down to this: is rtmp dump modifying the data stream as it writes the file on the hard drive, or is it just writing a 9-byte FLV header and appending the data it receives from the server, as it receives it?

I don't know since I can't look at the code, but since rtmpdump uses negligible CPU cycles while working, I have to assume it is doing NO processing, just writing. And once I extract the elemental stream from the (incorrect) container, they both play fine.

That's why I think this really is just a "transgendered" file. I think if it were possible to strip out the first 9 bytes altogether, the file would play. The video would look corrupted until it got to a keyframe, and seeking probably wouldn't work, but I think it would play consistently.

Here's a new one: the Pirates-Reds game today is available archived through the flash player, but when trying to download it, mlbdvr says "Server raised fault: Error in JiBX marshalling". Go figure. Using revision 155.