I've seen that problem with the rtmp streams but not the nexdef streams. Apparently, you can use nexdef without being a premium subscriber. I never knew this because I always sign up for premium service. Set use_nexdef=1 and use_wired_web=1 in your ~/.mlb/config.

As for why this is happening, I don't know. Try grabbing a few seconds worth using mlbgamedl.py and submit a bug report to mplayer team. They are maintaining librtmp these days.

Thanks, daftcat! I can confirm that this fixes the use-case I was describing.

Standings!

'g' key or STANDINGS action if you are customizing keybindings (see README for details on how to do that.)

They are not real-time. I could not find an XML from mlb.com but I did find a free provider at http://erikberg.com/xmlstats/api. The standings here are updated once a day. Every other provider of standings data wanted a subscription to a content feed provider.

Also in 450 (2013-sf-3) are various fixes to line score and master scoreboard related to "Completed Early" status. As more non-standard statuses occur, I will be fixing these views to handle them properly.

Added per game average Runs Scored (RS), per game average Runs Allowed (RA), and the difference between the two (+/-) columns to standings. For example, looking at the first record, as of 4/19/13, Boston scores and average of 5.0 runs and allows an average of 2.8 for a difference of +2.2.

I have adjusted the format string to accomodate this many columns. It's bugging me just slightly that all columns cannot be a fixed width. Let's see how this looks when W-L, HOME, and ROAD all have double digits.

Absolutly love this program, thanks for all the work you've put into it. Is there a way to return to the listings screen after starting a game?

Short answer: Open another terminal window.

Longer answer: When media is started, the GUI goes into a routine called waitInteractive() that both polls the "<streamer> | <player>" processes to make sure they are still running, while also waiting for user input so you can type either Ctrl-C or 'q' to close out these processes. Since mlbviewer is likely starting two non-trivial processes (one uses considerable bandwidth and the other uses considerable hardware), it would be very bad form for mlbviewer to not manage these processes (e.g. make sure they close correctly.)

Why would you want to return to listings anyway? Isn't your attention focused on the media you just started? I can tell you in-game action in the line score/master scoreboard/box score is ahead of the media. It would be one spoiler after another. I would not be able to do anything to fix that. The stream is on a delay (even for live media.) It's a trade-off to make a stream play smoothly.

I usually go back and forth between two games and the scoreboard, and wanted to cut down the number of windows. I'll just run it tmux. Thanks for answering.

Non-subscribers, make sure your user= is blank in your config file to exercise the new code. If user= is blank, I skip the login code. Make sure you can still watch highlights and condensed games.

Everyone else, just make sure that code didn't break your authenticated (non-blank user= and pass=) requests.

Just to say that I really like the new features, particularly the master scoreboard and standings.

The only blemish I can now see is the propensity to crash whenever a terminal window is resized. The immediate cause of that is the EINTR signal not being handled by the select loop. The attached patch catches the exception which python generates when encountering EINTR.

This patch causes nothing to be done after catching the exception (it does not resize the display), so although an increase in terminal size has no ill effect, there will still be a crash subsequently (say when L is pressed) if the window size is reduced when curses tries to draw outside the terminal boundary. I don't know the display system of mlbviewer (and curses) enough to know how to deal with that: what is probably needed is some code to schedule a resize of the curses window when EINTR is reached. Anyway, this patch might give some ideas.

Attached Files

signal.txt (690 Bytes, 15 views)

"propensity to crash" is putting it nicely.

I've known about this but without a satisfactory fix for a few years now. Good job on finding the EINTR part. I modified your patch ("continue" instead of "break" and using "errno.EINTR" instead of the integer value 4) and have included it. This at least covers the maximize and restore use cases.

I suspect to actually resize is going to be much more involved. Not only do I have to figure out why the curses.COLS and CURSES.LINES values are not getting updated when the terminal size changes, I also have to fix every call to addstr (across many classes) and padding routines to limit or possibly truncate the strings to fit. Granted, I probably should have been doing this from the start.

I have always regarded this bug as ugly, but very low priority. Accidental maximize is now fixed but intentional resizing seems like a corner case. (How often do you do an intentional resize of mlbviewer?) Especially since the crash is as benign as a crash comes. Once the window is resized and the program crashes, you can just restart with the new size. It doesn't impact program functionality like not parsing listings correctly or not handling network failures or failure statuses.

That said, I'll probably continue to look into this (and fixing addstr calls) and eventually come up with a fix. Just don't be surprised if it doesn't happen anytime soon.

When the program was in effect a means of launching mplayer, then crashing on resize was not much of an issue. What prompted this was that when scrolling over the master scoreboard, line scores or standings, it was a (my) natural user reaction to try to lengthen the window to get more on a page and a bit disconcerting when it caused the program to crash.

Anyway, this is your call. The last time I programmed for curses was about 15 years ago. It seemed pretty unintuitive and weird even then: that was addressing multiple windows with realtime updates. You have my sympathy.

On looking at some really old code, I see that on resizing the terminal, the terminal would send SIGWINCH to the foreground process group, and you could get the new size with an ioctl() call with the TIOCGWINSZ request code on file descriptor 0 (stdin). I don't now recall if initializing curses affects this but I have empirically checked that this still works with modern X terminals (gnome-terminal). Nor do I know if python has a wrapping for this ioctl() call.

This goes back to the days when CRTs were seen as a big advance over teletypes!

On looking further at it, the curses tigetnum() function will also get the current terminal size.

Putting the following in the else block of the select exception handler before the continue statement:

lines = curses.tigetnum('lines')
cols = curses.tigetnum('cols')
curses.resizeterm(lines, cols)

will prevent any increase or reduction in the height of the terminal crashing the program, but changing the width can still cause crashes because of other issues in the drawing code. (Obviously, this does not do any required redrawing to fit the new window size either.)

Sometimes understanding the use case is all the motivation I need to fix a bug.

That said, I have almost zero experience in curses programming. I inherited most of the curses code from the original developer and have just been cutting and pasting where needed. I think I am more impressed that my hack for scrolling actually works than all the new features I've been able to implement using it.

That said, I spent some time on this and here's what I have come up with. I found a piece of code from Stack Overflow that can get the new rows and cols by using a system call to stty:

Since all screens inherit MLBListWin (thanks to the rewrite), I embed that code above into MLBListWin.getsize() method which sets curses.LINES and curses.COLS to the new (y, x) values and returns these values to EINTR handler in mainloop. EINTR handler calls curses.resizeterm() with the new (y, x) values and then calls MLBListWin.resize(). MLBListWin.resize does two big things: it resizes the statuswin and titlewin and it moves them to the new y , x values (really only important for statuswin.) Finally, and this is the big caveat (e.g. trade-off), if the screen being resized is listings or master scoreboard, I call the PgUp() routine which resets the view to the first record and recalculates the viewable region.

I can re-visit this later to properly recalculate the current position and the new viewable region without having to reset everything to the topmost region. This would also be the fix for master scoreboard always resetting to the first record. It seems the lazy way to keep listings and scoreboard in sync is to always reset to zero position when navigating to scoreboard view and then keep all arrow actions (Up, Down, Left, Right) in lock-step with listings. The importance to keeping in sync with listings is that all screens originate from the listings data not the scoreboard data (e.g. how it is possible to play media, view highlights, navigate the schedule, open a line score, box score, or highlights all from the scoreboard view.) This is also why I checked in a change last week to refresh the listings whenever the scoreboard view is entered.

I believe I have tested all windows and combinations of resizing and navigation. However, there are a lot more screens and navigation combinations than there used to be.

Next up (besides not resetting to zero position in listings and scoreboard) is to change all addstr calls to addnstr calls to print only what fits on a line.

Hmm, I like that much more than a system call to stty.