The standard stream is definitely not doing it through the nexdef binary that MLB.TV make available. You can see that by firing up mozilla's flash plugin in firefox, first with and then without the latest nexdef.jar running. There must be some stream switching mechanism not revealed in the pages you referred to, which made interesting reading.

What speed do you think you were getting on the occasion you did get it working?

On my way out the door now, but I have got it working again (so far anyway). For some reason I had unset the use_nexdef option. With use_nexdef=1 and use_mlbhd=1 and speed=swarm in the config file, mlbhls is able to get the link to Saturday's Cubs game and start the download. You're right that "p" is broken now, and I have no idea what speed the stream is, but at least the stream is being accessed successfully. Also, no idea whether it'll work for live streams, but so far so good for archived streams...

Doubt I'll have time to test more today, but hopefully others may find this helpful!

"With use_nexdef=1 and use_mlbhd=1 and speed=swarm in the config file, mlbhls is able to get the link to Saturday's Cubs game and start the download."

That's interesting. Without mlbhls (which I don't have), the use_mlbhd option doesn't work (that option needs to be left unset), but if I pick the use_nexdef=1 option and speed=swarm and start 2012 nexdef.jar, then mlbviewer does work after a fashion, including on live streams. However, the nexdef server keeps cycling through its speeds which is quite unsettling and confuses mplayer and vlc, so it is not really watchable.

However, it does appear to show that the standard stream has been reimplemented quite significantly, and the nexdef stream less so.

Yeah, that's the option to use mlbhls, so you don't want it if you aren't using it!

Strange. mlbhls seems to have downloaded the whole game perfectly, with all three audio streams (well, the park one is silent because I assume HoHoKam isn't miked for it). I'm not sure which speed it is but it looks the same as it did last year. How often does it cycle? I haven't watched the whole game yet but after a couple minutes I haven't noticed anything yet...

I suppose it's possible that the server is doing something clever which screws up nexdef but which mlbhls just ignores?

Yeah, my patches may provide an ugly hack to get something working by hook or by crook, but I don't really claim to understand how the new streams work, which I'm sure we'll need to know eventually... that may have to wait until daftcat gets back!

In the meantime... if you can't get nexdef working, it might be worth it to try mlbhls? I'll report if I notice any more bugs with that process, but it is looking smooth so far.

Well, that didn't take too long... for the 3/09 Cubs-White Sox game, for some reason mlbhls won't download anything past the first 15 minutes or so of the stream. It did the exact same thing yesterday, so I'm assuming something weird happens 15 minutes into that stream. However, I think this is mlbhls's problem rather than mlbviewer's, since it looks like mlbviewer has correctly done its job of finding the game link and passing it to the downloader.

Incidentally, I noticed this line in the mlbhls README:

So maybe that's why mlbhls isn't crazily cycling between bitrates? It used to be a bug, but now it's a feature!

Annd now I'm getting the same thing with a bunch of other streams. For three different streams now, mlbhls downloads 103M, then stops. Saturday's Cubs game is the only one I've gotten to work without a hitch...

So this may require some more hacking even just to jury-rig something that works for more than a single case! But as I say, it does look like mlbviewer is now able to grab at least one of the links correctly. I assume that whatever is going wrong now is either that the downloaders (mlbhls or nexdef) aren't working properly, or that the answer lies in one of the new links.

In the meantime at least I have one game I can watch! And after that I'll just have to keep hacking while I listen to the audio broadcasts...

I have tried it and it doesn't seem to work, but maybe I am using it incorrectly. I have installed mlbhls at its most recent revision in SVN (revision 41): in my case compilation produced a single binary called 'mlbhls' which I have put in my PATH (in fact, in /usr/bin). I am using the same ~/.mlb/config file as before, and which still works with last year's archive, except that I have added 'use_mlbhd=1' and 'speed=swarm'. In addition, I have set 'use_nexdef=1' and 'max_bps=1200000'. When I try to run a stream, no error is shown, mplayer or vlc come up, but then they just display a blank, black, image. No actual downloading seems to take place.

Am I supposed to do something else? (I assumed the instructions in http://code.google.com/p/mlbtv-hls-nexdef/wiki/README were now superseded by the mlbhls option in mlbviewer.) Are you using a different revision of mlbhls?

Hmm, that sounds almost exactly like my setup, except... mine works. One difference is that I haven't updated mlbhls recently so I think I'm still on revision 37; it looks like there have been a few new updates that might have broken something?

If you set "show_player_command=1" in .mlb/config, does the mlbhls command show up before mplayer opens? You should see something like the following:

If you see that, then I think mlbviewer is doing its job and any problems are with mlbhls and/or mplayer/vlc...

Running mlbhls manually (as in those instructions) might help identify what's going on. Those instructions use mlbplay.py though and I'm not sure that's working. You should be able to get the same info by running mlbviewer in debug mode (press "d" at the listings page), then hitting enter at the stream you want, then quitting and checking the bottom of .mlb/log for the base 64 url. Then call mlbhls from the command line using the url as described on the mlbhls readme. If you can't get the url, then the problem is with mlbviewer; if you can then mlbhls may give you some error output if it goes wrong?

Ah, and now that I do this with the Mar 9 Cubs-Sox game, mlbhls does indeed give me lots of output. Basically, everything looks like it starts fine (that output is attached if you want to see it). Then when it gets to the 103M point (actually 107011668 bytes, apparently) it does this:

...So I'm thinking that my particular problem is likely an issue with mlbhls, although who knows why it works fine with some streams and not with others. Anyway everything above that error looks normal to me, so I am tempted to think that what I've kludged together at least partially overlaps with what is right!

Attached Files

mlbhls_successful_start_output.txt (1.2 KB, 13 views)

A couple things I've noticed after more trials:

Sometimes the 1200000 stream gives the BAD DECRYPT error immediately, but some of the other speeds (listed on the mlbhls readdme) will start downloading fine. Chris, maybe that's what's going on for you if it's not starting properly?

With the exception of Saturday's Cubs-Brewers game, every single stream that works at all gets the BAD DECRYPT error as soon as the download gets to (600s) and to (time: 1 -- 100). The other output differs from stream to stream, but every single stream that starts successfully and then fails does so at that point.

I may try emailing the mlbhls dev to see if he knows what's going on, although I'm a little hesitant given that this will probably all get rebuilt in a few weeks anyway...

I've looked into the bad decrypting issue and it seems the encryption keys are being changed after X amount of chunks. The previous behavior was to just use a single key for the entire game. I'll update mlbhls to fetch the new keys when needed (just like a 'real' HLS client).

Thanks for the debug effort and code support on mlbhls.

I have figured out how the basic stream is encoded and I will have a patch for that by the weekend. I'm returning from vacation tomorrow and will likely be catching up on work, laundry, and sleep before I can get to new code.

First priority will be to get the basic service working. After that is working, I will branch the code again for nexdef2012.

Thanks for your patience!

Not sure if this is related to the above. But --

I subscribe to Gameday Audio only and am not able to stream a live game. I get the error message: 'An error occurred in locating the game stream. 'Nonetype' object has no attribute 'groups'. However, I can stream and listen to an archived game.

Wow, I don't check the thread for a day and I come back to responses from two devs! Great to hear that you guys have solutions on the way, hopefully my rambling debugging helped a little. Am glad that the grown-ups are back in charge!

Looking forward to trying out the upgrades when I get the chance. And of course thanks to both of you x1000 for your work on this stuff, every time I have to use the official interface I remember how much worse it is than what you guys have put together. Kudos once again.

I found I had more time to work on this than I thought I would and the changes were not that difficult (so far), so basic service seems to be working now with speed toggling ('p') key as you would expect it from last season. The available speeds are different this year and one of these should be in your config file: 300, 500, 1200, 1800, 2400

e.g.

For those of you trying out hacks from a few days ago, speed=swarm is not going to be a valid configuration. Select one of the speeds above, but then also add "use_nexdef=1" (and probably "use_mlbhd=1" as I am not currently planning to support autobahn.jar (but I might look into this later after the season begins and all basic subscription issues have been fixed.)

Live games have not been tested yet mainly because I haven't been around during a live game broadcast.

What has been tested and works for me (which means someone else may still find an issue so please report them here):
- Archived basic video for the speeds listed above
- Archived audio
- Nexdef video using mlbhls

What has not been tested and may or may not work:
- Live audio
- Live video of any flavor
- Nexdef video using autobahn.jar