There's not much mlbviewer can do for connection issues. You can try increasing the cache value passed to mpv/mplayer2 in video_player=.

You can also try enabling adaptive streaming (adaptive_stream=1) with nexdef and set min_bps and max_bps to a wide range like 1200 to 4500. You will definitely need a newer video player like mpv for adaptive streaming.

Other than that, if there's network issues, not a whole lot mlbviewer can do to fix those.

Anyway, I don't even get to watch these games live on mlbviewer or the website due to their pay TV wall. I listen to the audio and pull up one of the PostSeason.TV camera angles. Or I go out to a bar.

Works great, thanks. Unfortunately I don't think I'll be enjoying it beyond today's game, unless the Angels pull a miracle. I don't suppose you can come up with a patch to help the Angels win? ;-)

I wonder if it would be a good idea to have a screen that shows all available streams (including any that would normally get dropped) and lets you choose any one of them to play? It would be a good workaround for if this sort of thing happens again, so you don't have to rush another patch out and we don't have to wait for one to be able to watch a game.

You may have to cycle through once, look for any stream with a "*_auth_required" and if it exists cycle through a second time and toss out anything without it.

I'm personally not too fond of the postseason flag, config settings should remain fairly static, imo, and not have to be flipped between regular season and postseason, or even just based on which game you want to watch. Isn't there some way to detect if a game being listed / requested is a postseason game automatically rather than having to flip this config setting every time?

It occurs to me that this logic of trying to select one stream and then giving up if it doesn't work may not be the best way to go, the logic seems to be getting more and more complex and is prone to failure if MLB makes any small change. A better approach might be to try to sort the streams (instead of skipping or dropping them) based on this logic, but if the first one doesn't play, automatically try the second, then the third, etc. So that way the logic will try to get the best stream first, but if it fails for some reason and there's another stream available that can play it will still play and the whole thing doesn't fall flat. It would basically just be adding some robustness to your code so that it would still work under less-than-ideal situations.

1. There is a screen to see available media: the media detail screen, "e" key.

2. The problem with postseason arises from the fact that there are two different streams that are national broadcasts. Regular season, there's usually only one national broadcast (e.g. the game of the week or All-Star Game.)

3. While making an assumption based on the presence of *_auth_required is fairly safe, making assumptions based on the absence of that parameter is not so safe.

The postseason= and international= flags are safe for regular season too. postseason= flag basically says, "ignore blackout statuses" and international= says, "filter out pay walls." In regular season, ignoring a blackout status will still result in a blackout response. And regular season doesn't employ pay walls.

One thing I can probably implement easily is to extend mlbplay to select games based on content-id. Or call letters.

Perhaps I could make a drill-down at the game level to list and select all streams. That's more involved and may not happen until next weekend.

Yeah I know, but you can't select a different stream from there to play other than the same ones that play from the listings screen.

Right, but what's the alternative? I suppose you could look for the -NAT in the call letters, but as you've already said, that's a rather ugly hack. My suggestion, though was to check for the presence of the header first in a separate loop, and then to loop through again and discard streams where it's absent, but only once you know that the game in question has streams with the header present, this is a bit more logic but should be a safer approach. At any rate, this is more of a suggestion for improvement for your national viewers, since I'm international it doesn't affect me this way anyways.

Ahhh, ok, I wasn't aware that postseason was safe for regular season use. I was aware that international should be safe, though, and agree that should remain a config setting. It's not so bad for postseason if it can just be left on all season. Perhaps "postseason" would then be better named, "ignore_blackout" but I guess I can understand why you wouldn't want to do that, it would give the impression that mlbViewer allows people to bypass blackout restrictions which is most certainly not the case here.

That would help, or just any way to select alternate streams other than the one that would play by default.

That's fine, I'm not expecting you do do this with any urgency. I really do appreciate everything you do for this project, it enables me to watch baseball on my old lower-powered laptop which just doesn't like the flash-player for it.

I can't thank you enough for mlbviewer -- I love it and use it on a daily basis.

I'm the maintainer of the Arch linux AUR mlbviewer package, and over there we're having some trouble watching nexdef streams. rtmp streams still work.

I actually did not diagnose the problem personally, so I'll copy the information that another Arch user provided. I did confirm identical behavior. Any help would be appreciated!

---------------

When I ran mlbhls independent of mlbplay, I found that mlbhls was not able to verify the SSL certificate, and there were a lot of these errors:

[MLB] (CURL ERR) SSL certificate problem: self signed certificate in certificate chain (URL: https://mlb-ws.mlb.com/pubajaxws/bam...ostalCode=ec1m)


Attempting to curl that URL resulted in similar errors:

curl: (6) Could not resolve host: URL
curl: (60) SSL certificate problem: self signed certificate in certificate chain


The weird thing is that netcat's CA bundle (/usr/share/ncat/ca-bundle.crt) would successfully verify, but I couldn't find any way of forcing mlbhls to use a different CA bundle.

In the end I patched the mlbhls source like so, to disable SSL verification: http://termbin.com/ih4e

It's not a solution of which I am very fond, but it's the only way I've been able to get nexdef to work.

I'd rather implement one of two options over making assumptions on 2-pass processing or call letters:

1. Make the home/away toggle work even when there are two national broadcasts.

2. Drill down menu

I can't implement either one until there's a pay wall game in the listings again. The -NAT streams go away when archived and, not surprisingly, Fox doesn't seem to want to share the broadcast to national users tomorrow. Or at least for now, there isn't a pay wall listing to be found.

Hey, just wondering if you saw my previous post about SSL errors with nexdef streams. Not trying to nag, but it took a while for the post to show up, so you might not have seen it. It would be great to get nexdef working for the LCS!

That's cool. I'm not watching any more because the Angels are out now, but if there's a specific game you'd like me to test from overseas, preferably an evening game, just let me know and if I can I'll check it really quick for you to see if it works.

I cannot reproduce it. If there are specific games that are showing this problem, please tell me the date and game and the stream (home/away, or in the case of LCS, whatever the call letters are from the media detail screen ('e' key.)

Also, I got a note from the mlbhls developer earlier this season that he's not going to support it anymore. He's got a different program he's writing that looks like overkill for mlbviewer.

Finally, if it's only a live stream issue, I cannot do anything to debug that because I'm blacked out in every possible way they can think of from watching live games: regional for the NLCS, US for both series, and they don't support my cable provider so I can't even use their pay wall workaround.

It's all games, live and archived. This cropped up a few weeks ago, around the end of September. I thought it might be related to Arch's curl package updating, but I downgraded to an earlier version and it didn't help.

Alright, so I guess this is really about mlbhls, not mlbviewer, and it appears to be Arch-specific, so maybe this is not the right place. Perhaps if I ask the mlbhls dev directly, he would be willing to attempt a fix? Is it still the email listed on the Google code project page?

mlbhls uses libcurl. So if libcurl is not correct, mlbhls won't be correct either. When you downgraded curl, did you also downgrade libcurl?

I am guessing this is an Arch-specific issue since this is the first I am hearing of it. I have personally verified this unreproducible on Debian and Linux Mint (which is an Ubuntu variant.) And last week it was verified on OpenBSD.

While you are trying to figure it out on Arch, you can download the virtual machine version here:
http://sourceforge.net/projects/mlbv...files/mlblive/

Download all the files (except the .bat) and run the .sh file to create the virtual machine and attach the ISO to the cdrom virtual device in VirtualBox.

Once you boot, you can set user= and pass= in config file. You should also do an SVN up in the mlbviewer directory since I am not sure what revision the live version uses. I previously used the VM version all the time when I would watch games at work. It was easier than trying to install it with Cygwin.

You can read the README at the link I posted while you are waiting for the ISO to download.

curl/libcurl are the same package in Arch.

I'm becoming increasingly convinced that this is an issue with Arch's ca-certificates. There were some upgrade issues right around when this problem began, and maybe something is still broken. I'll continue to search for a solution.

libcurl is probably built against nss. Check to see when nss was updated and try reverting that.

OK, I was able to get it working by downgrading curl, nss, and ca-certs to their versions from around 24 Sept. It appears to be related to this: https://lists.archlinux.org/pipermai...st/037057.html