Yea, the Texas-Toronto game was the one that kept crashing (although I only tried the Toronto feed).

The resizing issue I'm having is with the mlbviewer window, not mplayer (which does resize just fine).

mlbdvr is your only option right now for non-premium. nexdef just doesn't let non-premium users access any of the streams. It actually returns some kind of error like, "user not allowed to access content".

At some point, probably this weekend, I'll move the rtmpdump code to the library and you'll still have the option of record_only or trying to watch the stream as it records (though many have reported this as "dicey" at best.)

Really until I find something better than rtmpdump, what you get now in mlbdvr is probably all you're going to get until a better rtmp streamer/dumper comes along.

About 95% of the new feature development will be based on premium features. Sorry but that's just the limitations and the beef I have with that dumb rtmpdump and it's most unhelpful developer.

Resizing mlbviewer has never been a huge priority for me. It's a curses bug or rather a bug with the way I handle it.

Also, I think you asked earlier, I believe autobahn should run as a separate service rather than integrated into mlbviewer. In some cases, I'll get read failed errors from mplayer attempting to stream from autobahn. Restarting the autobahn service fixes these most of the time. Also, since I've been specifically asked not to redistribute or repackage autobahn, I think it should be treated as a separate dependency rather than a part of mlbviewer (even though it's where all the magic happens.)

The stream sizes depend on whether it is available in HD or not. Rather than asking you to make a guess at whether the game will be HD or not, I believe max_bps just indicates your upper tolerance (not just for bandwidth but also cpu since bigger bitrates take more resources to process.) I can do the higher rates on my primary laptop with little problems, but my low end laptop (the one hooked into the stereo and the wall mount LCD) maxes out around 800K.

A sample of available stream sizes:

164
400
600
800
1200
1800
2200

At HD, these go up to 3000 I believe. That's K. So add three zeroes for bps. 164, 400, 600, and 800 seem to be the non-premium streams that are available for any broadcast. If it's in HD, those go up to, I think, 1500, 2200, and 3000.

2500000 (remember the extra zeroes) seems to be a good value if you want six bars which is about as much as my system can handle.

Pick the bar your system behaves best at in the flash player and then match it with the highest setting for HD and use that value. But this code may not work exactly correct yet. I just pass this value as a max_bps setting but I think autobahn is still doing auto-adjust, up to but not over this value.

Turning off auto-adjust and picking a specific "bar" or stream is the next thing I'm going to look into.

Tried that, got exactly the same messages.

I'm running YDL on a PS3, if that makes any difference. I cannot find anything else on the web about autobahn & YDL/PS3.

Do you need Autobahn/NexDef? MLB.TV runs quite happily on my Ubuntu web-book without it (and is actually better without it - it produces awful output on my Windows (spit) PC). I am a Premium customer, though.

Do you know how you check ports on a PS3?

If it's a Linux, you could try (with autobahn shutdown):

You could also try running it as root which may or may not be a great idea, security wise. Which JVM / JRE are you using?

since r166 I'm experiencing a problem with mlbdvr.py.

log

I forgot. If I highlight the game, press 'z' and then use soapevent.py with the 'magic code' found there then rtmpdump starts and downloads the game.

Really dumb, I know, but the YDL firewall was blocking 8001. I opened the ports and ran autobahn and got the following messages:

Time to init SSL: 98
Failed to override default socket connect timeout
Failed to override default socket read timeout
19:54:02.973 EVENT Starting Jetty/4.2.x
19:54:03.798 EVENT Started HttpContext[/]
19:54:03.800 EVENT Started HttpContext[/protected]
19:54:03.804 EVENT Started SocketListener on 127.0.0.1:8001
19:54:03.805 EVENT Started org.mortbay.http.HttpServer@77c1d5f1

But the

Exception in thread "AdaptiveMediaScheduler-1994333193" java.lang.ExceptionInInitializerError

Message has disappeared.

However, mlbviewer still does not get things going. I get the listings screen then select a game. Looking at the messages the URL is found successfully but then I get various messages, including "mplayer file not found".

Might be a mplayer issue. I can't remember my success in using mplayer in 2008, I used vlc instead because vlc always worked!

Been having a look around the gdx.mlb.com server, which is where epg.xml is fetched from. First of all, many of the directory listing are browsable (which makes navigation considerably easier). Secondly, in the same directory (for each day) as epg.xml is a file called grid.xml, which seems to have the essential data for producing the multimedia page. This may be worth looking at if you don't fancy trying to parse the html in the multimedia page.

"http://gdx.mlb.com/components/game/mlb/year_<year>/month_<month>/day_<day>/grid.xml"

Anyway, the content ids for the various home and away feeds (and national feeds) are in there, in an attribute called "id". Also, now beginning to appear are content ids for condensed games. These condensed games appear to be free to access at the moment, though, according to the MLB support forum, they are still trying to get them into the epg, and then only accessible with a subscription.

So, once you have this seven digit content id, further information can be retrieved from another xml file at this URL:

"http://mlb.mlb.com/gen/multimedia/detail/<content id digit 5>/<content id digit 6>/<content id digit 7>/<content id>.xml"

Within that xml file is the URL of the video file for that content id (in the case of the free videos). For example, the URL the condensed game of last night's Tigers Angels game is:

"http://mediadownloads.mlb.com/mlbam/2009/04/23/mlbtv_detana_4260711_1m.mp4"

Another use of the content ids would be to construct the URLs that are sent to NexDef, without having to fetch them by logging in to the MLB website. I have noticed that logging in to the MLB website frequently causes certain problems that could be avoided by manually (within the software) constructing the URL to send to NexDef instead.

I described how to construct the URL in an earlier post:

http://www.linuxquestions.org/questi...ml#post3512062

and

http://www.linuxquestions.org/questi...ml#post3512604

Therefore, by logging in and logging out once initially, values for ipid, fprt and ftmu can be obtained, these cookies could then be removed, and all subsequent requests sent without logging back in. The values of ipid, fprt and ftmu would be incorporated in the URLs sent to the NexDef plugin (autobahn jar) and all authentication would be handled by that. Note that, in spite of anything I said in those earlier posts, it is important to obtain those three values correctly, as using out of date values can result in login errors (which we all know can be a pain in the neck).

One thing that does not appear in the grid.xml file, however, is any reference to the highlights link that appears on the right hand end of each game row (after the game). This link on the multimedia page takes you to a more comprehensive (and higher quality) list of highlight clips (including the full game recap) than the in game highlights (as currently displayed by mlbviewer) provides.

The way it does this is by opening the video search page, and searching for the gamepk id of the game in question (the gamepk is the "middle" bit of the calendar-event-id, between the first and second hyphens). Obviously, you wouldn't want to try and parse that video search page, but you can, instead, fetch the json (or xml if you prefer) list of videos for that search. The URL for that list is:

"http://mlb.mlb.com/ws/search/MediaSearchService?game_pk=<gamepk>&start=0"

This URL will return the xml version, but, if you prefer the json version, you can add "&type=json" to fetch that instead. In addition, if you want more results you can "&hitsPerPage=<number>". In that list you will see the content id for each video (in an attribute called "content id"), from which can be deduced the URL for the xml file mentioned above, and thus get the URL for the actual video from that. Note that these videos are now going up to 1000K bps rather than just the 800K previously. Also, the condensed games are in 1000K bps.

So, taking this route to fetch the video files of game highlights might provide an alternative set of highlights (including full game recap) to the "Top Plays" highlights, particularly for archived games.

I see that mlbviewer now has some code for sending the "control" message to NexDef, although I couldn't find where that code is called.

Anyway, have you had any success using that method to control the required speed? Looking at the response to that message, it seems to tell you what the status was before it received the request (in terms of the encodings group and the current encoding), and by sending the request again, it is possible to see that the encodings group has indeed been changed by the request. However, it does seem that, if the bandwidth isn't available (even on an archive game) it will still go to a lower bandwidth stream even if it isn't in the encodings group. I suppose that even the archive games are only intended to be streamed live, but it is a pain that there doesn't seem to be an option to stay at a high quality stream even if it takes longer to fetch.

One problem I seem to be having happens when the stream changes mid-stream (as it were). Using mplayer -dumpstream creates a file that can be played with (in my case) Applian FLV player, but the stream is not seekable, so I can't move to the bit that I want. I can produce a similar file by passing the downloaded file to ffmpeg with video and audio codecs set to "copy". This gives me another file that can be played with Applian FLV player, but this time it is seekable, so I can navigate forwards and backwards at will. However, when the stream changes, ffmpeg does not cope with it, it produces a message along the lines of "skipping flv packet: type 18, size 141, flags 0" and anything after that point is unreachable. Does anyone know if this is something that the ffmpeg guys could be persuaded to have a look at, in case it is as quick to sort out as the original problem with the opening frame that they were able to fix?

I ought to add:

1) Apologies that my posts on this thread have all been rather long.

2) Many thanks to daftcat for sterling efforts working on mlbviewer, and to all the others on this thread whose contributions have helped move things along (particularly Theophile).

3) Whilst I don't actually use mlbviewer myself, having only discovered this thread fairly recently, the knowledge available on this thread (and within the mlbviewer source code) has inspired me to fill in the gaps in my own rather rough and ready Java that does some similar things (but for a configuration where my Linux box has no monitor, so I want to create the stream dumps there, and then watch them, over my local network, on my Windows box, which is connected to an LCD TV).

CubsFanUK,

There is preliminary code for constructing control messages but as you correctly have observed, it's not being used yet. I have rewritten this bit to support both "ping" and "encoding" type actions with another method to parse the response. I plan to put this bit in a much smaller poll() loop associated with the player process, e.g.

I can put a bit somewhere in there to try a few times at the desired encoding and if currentEncoding doesn't change, just give up trying and bear with it.

In a future release (likely after May 1 Sourceforge target), I plan on implementing the quality bars and jump to innings, and plugin-like seeking (use a slider control to seek 10 to 30 seconds at a time in either direction and send those as requests to nexdef rather than relying on the media player's ability to parse the frames.

Finally, even though we have to record for rtmpdump users, my intention was never to officially support recording as this both goes beyond the scope of the service we paid for and it represents a theft of sorts since mlb.com sells games for download. Once I move rtmpdump into the library, I'll probably manage downloaded files like temporary session files and remove them when mlbviewer is closed.

That said, there might be minor convenience tweaks I'll add just because I know a good many of you are already going to hack recording into mlbviewer anyway like %f expansion in video_player command strings. But, any bugs that occur in unintended use (which recording is), will be low priority.

Try SVN revision 169. I had originally thought to put nexdef handling in mlbdvr before I decided to revive mlbviewer. As such, it is requesting nexdef urls which we know won't work for you. The connection refused is likely coming from the fact that you probably aren't running nexdef since you know it won't do anything for you. Thus, your system is saying, "I've got no service at port 8001. Go away."

So until I've merged the rtmpdump code back into mlbviewer, non-nexdef users (and audio users) should use mlbdvr.py where I have set the use_nexdef to False. (I think somewhere even older than revision 166 I had set this to True.)

Give that a go and let me know if it's working again.

With regards to replacing the SOAP requests with grid.xml, the media type= identifier isn't consistent for basic service. Okay, it's somewhat consistent in that it is either mlbtv_home or mlbtv_away. But at least with the SOAP requests and my testing the other day with a non-premium subscriber's account, the SOAP responses return only those content-id's for which the user is entitled to. This is convenient because it means I don't have to write that logic into my own code or needlessly try premium feeds that a non-premium subscriber doesn't have access to. Besides, I rather prefer the SOAP code over raw xml. suds returns nice python structures from a reply while raw xml I have to iterate over and tell it what I think is important and how I want to store it. At first I thought SOAP was a pain in the ass but now that I have a better understanding of how it works, I wish they used it in more places. Funny how that works.

Still, I'll probably end up using grid.xml to get the content-id of the condensed games.