I have done a little research and apparently the ValiCert Class 2 certificate has (with about a dozen others) been made a legacy certificate because it only has 1024 bits of RSA encryption and therefore might (with some difficulty) be cracked at some point in the approximate future. Mozilla's policy was to take the paranoid approach and disable them sometime after December 31, 2013. That "sometime after" looks as if it is "not quite yet" since they still seem to be in the mozilla store, except that ubuntu 14.04 (but not 14.10) seems to have taken advanced action.

So MLB.TV should really be replacing this certificate.

However it seems to be a bit more mysterious than that, because the Go Daddy certificate is a root certificate all by iself (it is in my root certificate store), albeit that it is signed by another CA (ValiCert). So MLB.TV could also solve the issue by removing the (anyway incorrect) inclusion of the ValiCert certificate in their announced server certificate chain, and ditto the Go Daddy one. As the Valicert certificate seems to have been removed from the Windows store already, presumably Windows does not throw up on this, and accepts the Go Daddy certificate notwithstanding the absence of the ValiCert one - in other words it stops and gives a pass after finding the root Go Daddy certificate - or they would have been inundated with complaints by now, whereas openssl (and maybe nss) does throw up on it if the ValiCert certificate is missing. I suspect either behaviour is regarded as acceptable.

In any event, MLB.TV come across as somewhat unclueful on all this.

Edit: The ValiCert Class 2 certificate looks as if it is no longer in the mozilla store. Presumably we can expect to see it omitted from distributions some time soon.

Interesting, that's good to know! I did notice that when I checked the certificate chain in Firefox it only lists the chain as far as the Go Daddy cert and doesn't mention ValiCert at all. When you say "ditto the Go Daddy one", do you mean that that cert is deprecated as well, or is it okay? I'm at work now, but I can't remember whether my Ubuntu machines had that the Go Daddy Class 2 CA cert in their list; I'll try to check later.

I guess this means that the ideal thing would be for me to remove that ValiCert certificate if/when MLB gets rid of it? (Although obviously it's not a showstopper having it there.)

Thanks again for the info. If anything it's good just to know that there's an actual issue and I wasn't just crazy.

No I don't think it is deprecated. However, if it is a root certificate it does not need to be included in the server's announced certificate chain.

They don't need to remove a certificate. They need to correct the server's announced certificate chain so as not to include the ValiCert one, which would enable you to remove the ValiCert certificate from your root store when using openssl with MLB.TV.

Yeah, that's what I mean, when they get rid of it from their cert chain. I guess I'll keep an eye on it then, and refer back to this set of posts if I run into any more problems. Thanks again for the info about this, it is definitely well outside my area of expertise so I appreciate it.

I think that was me. Although I can't recall what I asked ;-) I followed last year's season using the PI. Not everything went smooth all the time, but it worked fine most of the time. I relied on mlbview.py, together with some scripts. See here: https://github.com/lcvisser/mlbviewer-remote (this repo also includes the web-based front-end for mlbview.py that I wanted for using my phone as remote control).

To make a long story short: I faked "mplayer" with a simple bash script named "mplayer" and put the fake player first on the $PATH. The script just pipes stdout to the pipe and starts omxplayer reading from the pipe:

This works just fine most of the time, although omxplayer is really sensitive to wacky data. I'm glad mlbviewer has inning selection

If I can help with anything, let me know.

Installed MLBLIVE on Ubuntu 14.04 LTS media server w/VirtualBox using script supplied. Default config file has "video_player=mplayer". When a game is selected, window frame with mplayer2 on the banner opens, but no video is displayed in the frame. Tried mplayer2, & MPV as config settings, but those fail completely, returning to the list of games.

MLBVIEWER w MPV works on my dualboot laptop best. It also works on the server's virtual desktop, accessible via vnc. Haven't been able to get CYGWIN to work. Desktop VNC to server is acceptable, laptop VNC to server too laggy to watch. I got this far reading this forum and linking to other mlbviewer information sources, but MLBLIVE as a VM is (I think) a 2014 development, and I am experimenting and learning as I go. Bootable CD works fine, and given that the VM is running the .iso, I'm stumped as to what to do next, so I'd appreciate any suggestions. Plenty of ram and disk on the server.

I find nexdef mode (press 'n' or change use_nexdef=0 to use_nexdef=1 in config file) works better for me than rtmpdump using the VM. But that may just be that I am always using the VM from work where they have historically filtered out RTMP.

Hi!
It's me again with a problem using mlbviewer... ;-)
Since yesterday I get this message when I want to start a live coverage:
ERROR: Media response contained a notAuthorizedStatus.

The log file tells me this:
04/11 21:18 | 2015-04-11 21:18:38.271266
04/11 21:18 | SUCCESSFUL MEDIA REQUEST: status-code: 1 , event-id = 14-413722-2015-04-11
04/11 21:18 | See /home/lars/.mlb/successful-1.xml for XML response.

Any suggestions? Thank you very much in advance. :-)

Btw: Archived games still work fine...

Lars

I've never installed NexDef here on my work Windows box (it's not even listed on the downloads page anymore), but when I watch using Chrome I get the "highest HD quality available" indicator and Live DVR abilities. Is NexDef somehow built into Chrome's Flash now, or is it really using something else? I will try again tonight when I get home, but Chrome on Linux did not offer me live DVR, saying my device doesn't support it. The FAQ for that message indicates NexDef is required, but the link to the downloads page doesn't have it, so obviously their content needs some updating. Still, I'm not sure what the discrepancy is, and I will be irritated if live DVR doesn't work on Linux at all.

Does mlbviewer support live DVR at all? Does it go higher than 960x540 in NexDef mode? I am able to get 960x540 with the Kodi MLB plugin, and skipping is fine for archived games, but live games are locked live.

EDIT: I could have sworn I had live DVR when I tested at work (win7/Chrome) but I tried here at home and both Linux and Windows XP Chrome ask to install the NexDef plugin for DVR functionality. Also, MLBViewer NexDef allows 720p streams.

Are you basic or premium subscriber? Maybe basic subscriber trying to access a premium stream? Next time it happens, post the contents of the (un)successful-?.xml log file indicated in the message. That file is overwritten with every request so I need to see the contents directly after the error and before the next request.

1. Nexdef is historical term for when high def was only available through the Nexdef plugin. Back in the day, mlbviewer users had to download the Mac version of the plugin, extract it, and run the Java jar file. One thing that hasn't changed is that it is still the source of the High Def streams. It's just now the Apple HLS is handled at the streamer (mlbhls) rather than in the plugin itself.
2. No idea whether the streams max at 720p or go all the way up to 1080p. Set min_bps= and max_bps= or whatever the option name is (look in readme) to 4500 and check the stream properties.
3. Live DVR is primarily a player feature. Mlbviewer is more like a media broker than a media player. It negotiates the stream URLs based on GUI selection and hands off to helper applications like rtmpdump and mpv. So live DVR really means pause and seek functionality on a live stream. A large part of that will be your buffer size and how your streamer/player handles seeking beyond the buffer.
4. I believe the consensus is that rtmpdump (non-Nexdef) in combination with mplayer2, mpv, and possibly vlc support live DVR but you don't get the highest quality streams. It maxes out at whatever 2400 bps whereas Nexdef goes on to 3000 and 4500.
5. I plan to rework all that mode and speed selection to be more informative and less historical. Maybe have a couple of views based on personal preference. I like selecting based on stream speed but someone else may want to select solely on resolution (480p, 720p, 1080p.). Also, change Nexdef to Highdef.

On a side note: I got notified that Google is taking down Google Code. Does anyone know if mlbhls (which is now being hosted at Google Code) is being migrated to somewhere? Is it being maintained at all?

Yeah, I think I'm getting my head around it better. Is there anything special about what mlbhls is doing, or can any HTTP live streaming implementation handle it?

I had it maxed according to the readme and was getting 720p, but it was also swapping adaptively to lower streams, so I could have had issues maxing it out. But MLB's bandwidth test said I was at 12000 and you only need 3000, so I don't know what was up, other than I was going through a crappy fast ethernet router.

I guess the issue here is that the rtmp version maybe doesn't allow for seeking or specifying a start time like hls, so to do this in Kodi the stream would have to be saved the whole time and you could only skip around through what was downloaded. Either that or I have to get the mlbhls version working again (it did at one point but is now broken). I'd love to get hls working with the skip buttons jumping through innings.


@lcvisser - Google Code has a button to migrate projects to GitHub, so I think that's the preferred destination, or else be merged in with mlbviewer.

This wouldn't exactly be accurate since Nexdef has highdef, but also has lowdef feeds (even some that rtmp doesn't have such as 800kbps).

I don't know very much about other HTTP streamers, but as far as I understand, mlbhls does need to fetch an auth key of some sort periodically to keep the stream going. I've assumed that's the reason why thegryghost wrote it in the first place instead of simply passing a link to curl or something.

But as I say, I'm no http streaming expert, so there may be other good reasons too.