Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi daftcat. Thanks for the consistant loyalty to this project. I'm preparing for viewing the new season and tried to watch a game just now and got the following error.
Quote:
Requesting media: ('WPHL-HD', u'143', '25873533', '14-346180-2013-03-30')RTMPDump v2.4
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
mplayer: could not connect to socket
mplayer: No such file or directory
INFO: Connected...
WARNING: Received FLV packet before play()! Ignoring.
WARNING: Received FLV packet before play()! Ignoring.
WARNING: Received FLV packet before play()! Ignoring.
I also got the following while scrolling down through the games listing.
Quote:
Traceback (most recent call last):
File "mlbviewer.py", line 632, in <module>
curses.wrapper(mainloop, mycfg)
File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
File "mlbviewer.py", line 160, in mainloop
prefer = mysched.getPreferred(available[mywin.current_cursor],mycfg)
File "/home/rob/mlbviewer-2013/MLBviewer/mlbSchedule.py", line 490, in getPreferred
if homecode in elem[1]:
TypeError: coercing to Unicode: need string or buffer, NoneType found
If anyone has been having their game interface crashing these last few days, this patch seems to fix it. When the patch is applied, it might apply a line or two off, as I have also patched the file to allow 800kb/s streams which MLB.TV are providing that on live streams this season.
The patch might also come in handy for the all star game.
Verified and checked into rev396. An SVN update will take care of this so you will not have to manually apply this patch to every revision.
Hi daftcat. Thanks for the consistant loyalty to this project. I'm preparing for viewing the new season and tried to watch a game just now and got the following error.
I also got the following while scrolling down through the games listing.
The scrolling issue will be fixed with an "svn up".
As for the media play issue, make sure you are using mplayer2. I would look for "-really-quiet" in your video_player command and remove it. That should tell you which mplayer you are using. Or just type "mplayer | head" and it will be in the first line:
Quote:
matthew@dubstep32:~/mlbtv/mlb2013$ mplayer | head
MPlayer2 9d6b188 (C) 2000-2012 MPlayer Team
Usage: mplayer [options] [url|path/]filename
Basic options: (complete list in the man page)
-vo <drv> select video output driver ('-vo help' for a list)
-ao <drv> select audio output driver ('-ao help' for a list)
vcd://<trackno> play (S)VCD (Super Video CD) track (raw device, no mount)
-alang/-slang select DVD audio/subtitle language (by 2-char country code)
-ss <position> seek to given (seconds or hh:mm:ss) position
-nosound do not play sound
If it's not Mplayer2, you may have problems playing the stream. It's also possible that the "-really-quiet" is just covering up the messages about cache fill (buffering) and that if you gave it enough time, it would start playing.
The scrolling issue will be fixed with an "svn up".
As for the media play issue, make sure you are using mplayer2. I would look for "-really-quiet" in your video_player command and remove it. That should tell you which mplayer you are using. Or just type "mplayer | head" and it will be in the first line:
If it's not Mplayer2, you may have problems playing the stream. It's also possible that the "-really-quiet" is just covering up the messages about cache fill (buffering) and that if you gave it enough time, it would start playing.
The scrolling issue is fixed but not the other. I installed mplayer2 from the ubuntu repositories and removed the -really-quiet from the player line. I'm getting this:
Quote:
Requesting media: ('WPHL-HD', u'143', '25873533', '14-346180-2013-03-30')RTMPDump v2.4
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
INFO: Connected...
MPlayer2 UNKNOWN (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing -.
Reading from stdin...
Cache fill: 0.00% (0 bytes)
I let it sit for a while and then get:
Quote:
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleInvoke, error decoding invoke packet
Cache fill: 0.00% (0 bytes)
Quote:
MPlayer2 UNKNOWN (C) 2000-2012 MPlayer Team
Usage: mplayer [options] [url|path/]filename
The scrolling issue is fixed but not the other. I installed mplayer2 from the ubuntu repositories and removed the -really-quiet from the player line. I'm getting this:
I let it sit for a while and then get:
Which game is this? What stream speed? Do you have use_librtmp=1 enabled in ~/.mlb/config? I am not convinced librtmp is working correctly.
A little bit of searching on the error string and I see it is actually an rtmpdump problem and not an mplayer problem. What version of rtmpdump are you using? I don't see this problem with 2.4 and the Tor-Phi archived game.
Hey daftcat, I've got a few problems with the mlbplay script. I'll explain using the game 2013-03-30-nyamlb-abkbbc-1-YES-HD.
Using the newest revision (397) mlbplay doesn't work. There is no output at all. I'm using the following command:
Quote:
python ~/MLB/mlbplay.py v=nyy j=03/30/13
use_librtmp is 0 and so is use_nexdef, speed is set to 1200. When enabling debug I get:
Quote:
Media URL received:
*A URL that looks correct*
Using revision 383 of mlbplay doesn't work either, but gives errors as above:
Code:
MPlayer 1.1-4.5.4 (C) 2000-2012 MPlayer Team
Playing -.
Reading from stdin...
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleInvoke, error decoding invoke packet
ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len: 16181142
The old revision is not that important - but the current one doesn't seem to do anything after getting the media URL.
Using mlbviewer works though - in both revisions.
Thanks for any help you can provide! Does mlbplay work for you?
Last edited by mkomko; 03-31-2013 at 04:44 AM.
Reason: Additional info
A little bit of searching on the error string and I see it is actually an rtmpdump problem and not an mplayer problem. What version of rtmpdump are you using? I don't see this problem with 2.4 and the Tor-Phi archived game.
I did another svn up today and when I fired up mlvbiewer-2013 I saw this on the splash screen
Quote:
2013rev384+
It's even more odd because when I snagged the updates this is what was returned in my terminal
Quote:
$ svn up
U mlbviewer.py
U REQUIREMENTS-2013.txt
U MLBviewer/mlbConfig.py
U MLBviewer/mlbMediaStream.py
U MLBviewer/mlbConstants.py
U MLBviewer/mlbSchedule.py
U README
Updated to revision 397.
$
Should I be seeing the version update on the splash after I grab updates or is the plus sign the only expected sign that I'm running a newer version?
ETA: Also, is there a way to avoid having my password visible in clear text in the config file? I'm the only one who uses my laptop and when I step away I always lock the screen but it bugs me having a clear text password there.
Last edited by BostonPeng; 03-31-2013 at 08:09 AM.
1. Quick fix was to deprecate it (e.g. remove the difference in stream selection) and an added safety was to override it after cfg file is read. The only reason why I didn't remove it completely is because I put it some if/elif/else code that I haven't had a chance to de-tangle.
2. I don't know if I want to put that patch in only because I haven't had the chance to test all the use cases and the bug seems to only affect condensed games. There is code elsewhere (presumably locateMedia() of which locateCondensedMedia() is an early shortcut within that procedure) that handles librtmp.
In other words, your use case is much smaller compared to other cases that can be affected by your patch.
In more blunt terms, the patch can do more harm than the bug.
At this point, I would say if you can use rtmpdump and you cannot justify to me why you would rather not use rtmpdump, wait it out until I have the time to put a proper fix in.
2a. librtmp/rtmpdump and nexdef are mutually exclusive except condensed games. There are no nexdef streams for condensed games. Rtmpdump or librtmp is exclusively used for condensed games unless you want the lower quality 3GP streams.
3. I don't know what this means to have a mercurial mirror on bitbucket. Does it require any extra effort on my part? Could it result in different versions of the code residing on the mirror than what's on sourceforge? Will there be different versioning schemes? Again, like the patch above, it sounds like it could result in more work for me than it's worth for everyone else. It's GPL so you can do with it what you want but I'm not likely to do anything but maintain the sourceforge versions.
Regarding (2), here is an adaptation of the patch which is more "local" -- i.e., it should only affect condensed games:
Code:
diff -r b196f7e51de5 MLBviewer/mlbMediaStream.py
--- a/MLBviewer/mlbMediaStream.py Sun Mar 31 04:49:09 2013 +0000
+++ b/MLBviewer/mlbMediaStream.py Sun Mar 31 15:46:40 2013 +0300
@@ -390,6 +390,8 @@
def prepareMediaPlayer(self,game_url):
if self.streamtype == 'condensed':
+ if self.cfg.get('use_librtmp'):
+ return game_url
return 'rtmpdump -r %s' % game_url
elif self.cfg.get('use_nexdef') and self.streamtype != 'audio':
self.nexdef_media_url = game_url
AFAICT, locateMedia is too early to make a change, since it is only after returning from there that the command line is modified by prepareMediaPlayer.
Truthfully, what I'm really interested in is not "librtmp" per se, but rather just the ability to construct my own command line (by setting the video_player) around a given condensed game's url. However, normally (when use_librtmp=0), the command line is partially created by mlbviewer, to pipe rtmpdump's output via whatever is set as the player; thus, if the command line I provide is not prepared to read from stdin, it breaks; in the past, I believe that setting use_librtmp=1 would circumvent that (presumably, because that setting means that mlbviewer no longer needs to apply rtmpdump itself, since use_librtmp=1 means that whatever I specify on the command line is already rtmp-aware), passing on just the naked url, around which my own command line could be built; so it is that behavior that I am trying to preserve in these patches. Possibly, there's a more correct way to fix my root problem, although it would probably also involve more invasive changes.
Regarding (3), what I intended was to set up a mirror which would then make it somewhat easier to submit patch proposals. But yes, it would require manual updating (which *I* intended to do) in order to remain up-to-date with the official subversion repository; and the version numbers would be different; so it may be more confusing than it is worth. I'll drop this for now.
I finally have my 2013 article about setting up mlbviewer written for my site. If anyone sees anything I missed or got wrong (I was writing it from a system already able to run mlbviewer and may have forgotten something I did to get it working) please let me know on the article's comments.
I'm noticing looking at the top plays for games doens't seem to show all of the available highlight videos. A case in point: Yesterday's final spring Freeway Series game between the Dodgers and the Angels in Anaheim shows four clips:
Conger's walk-off blast
Kemp opens scoring with sac fly
Punto's sparkling inning-ender
Trout's RBI groundout
But if I go to the league site and pull up a video, then click the More From This Game link and I see two additional clips:
Hanson's great outing
Greinke's strong spring start
If I go to the MLB Media Center and click the Highlights link it shows the complete list of all six videos. I'm guessing it's due to how MLBAM provides data about the videos but I wanted to mention it in case it's something that can be tweaked in mlbviewer.
Last edited by BostonPeng; 03-31-2013 at 11:30 AM.
I did another svn up today and when I fired up mlvbiewer-2013 I saw this on the splash screen
It's even more odd because when I snagged the updates this is what was returned in my terminal
Should I be seeing the version update on the splash after I grab updates or is the plus sign the only expected sign that I'm running a newer version?
ETA: Also, is there a way to avoid having my password visible in clear text in the config file? I'm the only one who uses my laptop and when I step away I always lock the screen but it bugs me having a clear text password there.
Too much trouble to rev the version every time and I haven't figured out how to get SVN to do that for me. I revved it last to mark post-rewrite and the actual sourceforge download will have a real version number. Something like 2013-1.0-1. Always go with "svn status" or what svn up reports since the version on the splash is not likely to change as frequently.
If you are a non-subscriber, you don't even need user= and pass= in the config file. Especially since we established that condensed games for non-subscribers won't play unless the user= and pass= is blank. Otherwise, I just recommend using a password for mlb.com that you don't use anywhere else. The low risk of anything bad happening if someone got your mlb.com password outweighs the development effort to secure it. I could change the way the default file is written to prompt and encrypt the password but no-one else has really asked for it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.