LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Fedora
User Name
Password
Fedora This forum is for the discussion of the Fedora Project.

Notices

Reply
 
Search this Thread
Old 04-19-2013, 02:45 AM   #3991
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76

Quote:
Originally Posted by mkomko View Post
It's amazing how much time you have dedicated to mlbviewer this year. Thank you very much!



Apparently I'm the only one with this problem:
It regularly happens that I need many tries to get a game started. It's not really a mlbviewer problem, since mlbviewer is able to get the media URL just fine. But then rtmpdump just can't get the stream going. The error messages are usually along the lines of:
Code:
ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len: <random number>
Code:
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleInvoke, error decoding invoke packet
Code:
WARNING: Received FLV packet before play()! Ignoring.
WARNING: HandleInvoke, Sanity failed. no string method in invoke packet
When it happens, it takes me anywhere from 5 to 30 tries to get the stream going. Often, when I wait a while, it works on the first try. Sometimes it works on the first try right away. I don't know why it's happening. It happens on all games and all speeds (no nexdef, no librtmp).

I have tried different rtmpdump versions including the current git version and different mplayer/mplayer2 versions.

Am I the only one this happens to? Any ideas why this could be happening?
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.
 
Old 04-20-2013, 01:11 PM   #3992
dovf
LQ Newbie
 
Registered: Jul 2010
Posts: 13

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
MediaStream:

* Changed prepareMplayerCmd to prepareLibrtmpCmd to more accurately describe what it does
* Added check for streamtype == condensed and use_librtmp to prepareMediaStreamer
* Added extra checks to prepareLibrtmpCmd to not construct a librtmp url for use_nexdef=True and streamtype == video
Thanks, daftcat! I can confirm that this fixes the use-case I was describing.
 
Old 04-20-2013, 04:01 PM   #3993
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
SVN revision 450 (aka 2013-sf-3): Standings!

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.
 
Old 04-21-2013, 05:26 AM   #3994
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
SVN revision 451: Minor improvement to standings

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.
 
Old 04-21-2013, 11:18 AM   #3995
ckipping
LQ Newbie
 
Registered: Feb 2010
Posts: 2

Rep: Reputation: 0
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?
 
Old 04-21-2013, 01:32 PM   #3996
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
Quote:
Originally Posted by ckipping View Post
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.
 
Old 04-21-2013, 02:53 PM   #3997
ckipping
LQ Newbie
 
Registered: Feb 2010
Posts: 2

Rep: Reputation: 0
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.
 
Old 04-22-2013, 02:07 AM   #3998
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
SVN revision 452: Added code to skip login for non-subscribers

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.
 
Old 04-27-2013, 09:33 AM   #3999
chrisVV
Member
 
Registered: Aug 2010
Posts: 108

Rep: Reputation: 1
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
File Type: txt signal.txt (690 Bytes, 4 views)
 
Old 04-28-2013, 04:24 AM   #4000
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
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.
"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.

Last edited by daftcat; 04-28-2013 at 04:28 AM.
 
Old 04-28-2013, 05:07 PM   #4001
chrisVV
Member
 
Registered: Aug 2010
Posts: 108

Rep: Reputation: 1
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.
 
Old 04-28-2013, 06:12 PM   #4002
chrisVV
Member
 
Registered: Aug 2010
Posts: 108

Rep: Reputation: 1
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!
 
Old 04-29-2013, 05:16 AM   #4003
chrisVV
Member
 
Registered: Aug 2010
Posts: 108

Rep: Reputation: 1
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.)
 
Old 04-29-2013, 06:06 AM   #4004
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
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:

Code:
sy, sx = os.popen('stty size', 'r').read().split()
x=int(sx)
y=int(sy)
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.
 
Old 04-29-2013, 06:08 AM   #4005
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,745

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
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.)
Hmm, I like that much more than a system call to stty.
 
  


Reply

Tags
help, install, installation, instructions, seek, vlc, windows


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
mlb.com gameday audio stream statmobile Linux - Newbie 6 05-06-2008 10:16 PM
link dies intermittently-seemingly at random- between win<->linux not linux<->linux?? takahaya Linux - Networking 10 03-09-2007 10:37 PM
triple boot linux/linux/linux No Windows involved toastermaker Linux - Newbie 12 03-02-2006 10:40 PM
Redhat (rhel v2.1) bootup problem with linux (linux vs linux-up) namgor Linux - Software 2 06-24-2004 02:49 PM


All times are GMT -5. The time now is 01:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration