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.
Now that the revision I released yesterday or the day before tells you what stream you are using, are you guys actually getting the 3000K stream?
I never get more than the 2200K stream, but I'm not complaining. The 2200 is more than enough and Comcast probably can't give me more than 2.5 mbps without upgrading to a Docsis 3.0 cable modem.
I'm going to have an extremely busy weekend (my dance competition season is beginning with two comps in two days this weekend) so I'm just going to finish up some documentation, the rtmpdump integration, and maybe a couple more features like an HD indicator and condensed games and call this ready for first Sourceforge release for Monday. After that, jump to innings interface will probably be the last major feature. Then I can shift to maintenance mode for awhile. Maybe even make it out to a real game instead of testing the streams 24/7. Later next month or June I'll write a stream downloader based on mlblistings.py and soapevent.py for the non-premium users to replace mlbdvr.py. No curses gui, but decent command-line options. Finally, I expect if Adobe makes good on their promise to release the RTMP specification, I'll probably be busy again later this summer if and when mplayer/ffmpeg support RTMP natively.
When I set the max_bps to 3000k mlbviewer reports it as using 3000k not 2200k.
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
* HttpContext[/protected]
* HttpContext[/]
The links above may not work if a virtual host is configured
Yes - that is exactly what I get. is this good or bad news?
If you got this it means all hope is not lost yet. The web server is running. I'll get you a script later today to make proper requests to autobahn and see how much of it works. You might just try nexdef.py with an event-id from mlblistings.py.
Heck, try this one:
Code:
$ test/nexdef.py 14-244501-2009-04-29 | tee /tmp/nexdefmessages.log
Post that log file to pastebin.com.
Wait, have we done this before?
Do it again anyway, because you'll need various components of the SOAP messages to make the requests directly to autobahn with your web browser.
Now that the revision I released yesterday or the day before tells you what stream you are using, are you guys actually getting the 3000K stream?
I have my max_bps set to 3000K.
I got the 3000K stream Tuesday night for the Giants-Bums game. It was glorious. On my laptop it was nearly full screen in its window - not in "full screen" mode. The stream info in mlbviewer displayed as 3000K. It kept dropping at the start of the game but by the 2nd or 3rd inning it played continuously without issue until probably the 9th inning. Occasional jumpiness is usually solved by pausing (spacebar) in mplayer for a couple seconds. This seems to allow it to buffer enough to be smooth again.
Last night I got the Giants game at 2200K and that was what mlbviewer displayed. Played for most of the game until I got local network connection issues in the 8th inning - probably my cable modem renewing IP or something. Anyway...once it I got network again and restarted mlbviewer initially I only got 300K stream, which bumped up (on the fly) to 600K and bumped up again (on the fly) to 1200K. Mplayer resized itself when the stream bumped up and mlbviewer updated its display to correspond to the stream. It crapped on me again and then when I restarted again it was back connected as 2200K for the remainder of the game.
I am convinced that MLB.TV isn't always even producing a 3000K stream for every game. I would think if they were I would get that stream every time. More often than not I get a 2200K stream. My belief is 3000K vs 2200K is dependent on the broadcast they get the stream from. And the difference on my end is when I go to full screen. 3000K at full screen looks like full HD...no noticeable change from windowed. 2200K at full screen is a little less sharp, but in its window it is just as sharp as 3000K.
3000K at full screen looks like full HD...no noticeable change from windowed. 2200K at full screen is a little less sharp, but in its window it is just as sharp as 3000K.
Actually, in its window, the 2200k stream should be sharper than the 3000k stream. Since the 3000k stream is full-frame HD, that drives the bits-per-pixel rate down. In actuality, the bpp of the 3000k stream is a respectable 0.109. On the other hand, the bpp of the 2200k stream is an amazing 0.204. That means that when displayed in their native frame sizes, the 2200k stream should be much sharper.
So if you're watching a game on, say, a work computer that you are also using for other things, the 2200k stream is ideal. But if you're comparing the streams by scaling to a larger size (say on an HDTV), then the higher bitrate stream (3000k) would look sharper.
If you got this it means all hope is not lost yet. The web server is running. I'll get you a script later today to make proper requests to autobahn and see how much of it works. You might just try nexdef.py with an event-id from mlblistings.py.
Heck, try this one:
Code:
$ test/nexdef.py 14-244501-2009-04-29 | tee /tmp/nexdefmessages.log
Post that log file to pastebin.com.
Wait, have we done this before?
Do it again anyway, because you'll need various components of the SOAP messages to make the requests directly to autobahn with your web browser.
And fire up mlbviewer. I didn't bother setting max_bps because I'm at work and I probably shouldn't be watching streaming video at 3000K. ;-) I probably shouldn't be watching streaming video at all. Without setting max_bps, I default to 800K. The auto-adjust, surprisingly, tried me first at 1200K (where I had a little heart attack thinking IT would walk in at any minute) but thankfully backed me down to the 600K stream.
It's one time where I actually appreciate the auto-adjust quality code in nexdef.
I will definitely have to try this again from home where I won't have to worry about the IT department.
I think it would be incredibly embarrassing for MLB.TV team if I was able to get 3000K (or even 2200K) without any freezing or stuttering or other issues that plague the flash player on one of their supported platforms. I should probably keep my mouth shut about this on the forums.
Congratulations! Your nexdef is working just fine.
Now you have to figure out why mplayer is unhappy.
Are you using the very latest mplayer built from svn source?
Code:
$ svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
$ cd mplayer
$ sh configure --enable-dynamic-plugins --prefix=/usr
$ make
$ sudo make install
(or do the last step as root without the 'sudo')
The other thing I've observed is that occasionally you have to prime the nexdef pump. In other words, the first try doesn't always produce a stream right away but the second or third will latch on.
But yes, this part here tells me you're connecting to the nexdef plugin and it is responding with the available streams:
1. Do you remove the 14*mp4 file in between retries (you should!)
2. How long does it take to "Core dumped"? Unfortunately, some mplayer developer thought it would be cute to put "Core dumped" as the "download complete" message for dumpstream. To me, this is just bad coding practice because it would a) confuse the user, and b) potentially mask a real core dump (like crying wolf.)
Yeah, I haven't tried any code for requesting them yet. I have some basic code in mlbtv.py (parse_media_grid) to find condensed games content id, but that routine isn't quite ready yet. It's kinda puzzling me how it's over-stuffing the dictionary with duplicate entries. I got a little distracted by the rtmpdump integration but I guess that and session management and whatever else I mentioned above is what I'm going to try to finish for Monday.
You know, I really kind of bungled the whole OOP concept. I probably should have made base classes for GameStream and MLBSchedule and inherited classes for last year, this year's premium, and this year's non-premium.
Oh well, I want to get it all working first and available on Sourceforge. I can fix up the code later. Hopefully they'll stick with this architecture for more than one season in case I don't get to it until the off-season. Still, if they change it up in the off-season again, I'll have to write in yet another inherited class for next season so it would be better to get started on that sooner than later.
You *might* though I'm really not sure be able to take the content url and point your Ubuntu mplayer at it (or even possibly Applian FLVPlayer on the Windows machine) just to see if the streaming works. Because right now, all I can tell you is the web server portion of your nexdef is working.
See what you can do with my other response and I'll test out streaming from another machine's nexdef. If that works, I can write you a test script to get the content url to paste into FLVPlayer (it's the one that doesn't have "describe" in it before the base64: part. (Or the one on the STREAM ASF, URL line in your output.
Run the nexdef.py again, then copy that url to a text editor. Change the local.swarmcast.net to your PS3 IP and point Ubuntu or FLVPlayer at it. I'm not sure if that will work, but if it does, then we need to debug your mplayer and not your nexdef.
with your patch 1.5 seems to work correctly with both last revision and r170 with mlbdvr.py .
Is %f filename expansion still supported? My 'old' mplayer still chokes with the stream and I also would like to watch games where I have no internet ( house in the mountains ), so I'd like to play a bit with -dumpstream, at my own risk obiouvsly.
You *might* though I'm really not sure be able to take the content url and point your Ubuntu mplayer at it (or even possibly Applian FLVPlayer on the Windows machine) just to see if the streaming works. Because right now, all I can tell you is the web server portion of your nexdef is working.
See what you can do with my other response and I'll test out streaming from another machine's nexdef. If that works, I can write you a test script to get the content url to paste into FLVPlayer (it's the one that doesn't have "describe" in it before the base64: part. (Or the one on the STREAM ASF, URL line in your output.
Run the nexdef.py again, then copy that url to a text editor. Change the local.swarmcast.net to your PS3 IP and point Ubuntu or FLVPlayer at it. I'm not sure if that will work, but if it does, then we need to debug your mplayer and not your nexdef.
No, this won't work because the server starts up as 127.0.0.1.
But...
If you enter that url in your YDL browser, you should see a garbage stream pour down the web page as the nexdef attempts to stream to firefox. Again, I'm just guessing here. I won't be able to test this for awhile.
with your patch 1.5 seems to work correctly with both last revision and r170 with mlbdvr.py .
Is %f filename expansion still supported? My 'old' mplayer still chokes with the stream and I also would like to watch games where I have no internet ( house in the mountains ), so I'd like to play a bit with -dumpstream, at my own risk obiouvsly.
This won't work. I haven't removed the %f expansion but there's no "resume" code in mlbviewer. There's still a bug in rtmpdump (one that the developer doesn't seem to want to acknowledge) that if rtmpdump is left to run full speed (and -dumpstream doesn't perform the flow control that running it pipeline with a play command-line does), it will eventually crap out after 30-40% of the file is downloaded. You might want to revert back to revision 170 and rtmpdump 1.4 until I either figure out how to fix rtmpdump or move that mlbdvr.py code into a downloader script. I'm officially not supporting mlbdvr.py anymore and it will probably disappear from future revisions. I've been testing the piped command to mplayer and I'm satisfied with the results. It can and does stay up for a full game which is all that's necessary to get the sourceforge users going starting next week. After next week, I can work on a download script for special cases like yours where playing immediately is not practical.
rjwood...i got your reply. can't seem to email you directly (the email your reply came with bounced) or via forums (you are set to not receive emails from users apparently). i for one would be interested in your forum to talk baseball aside from this forum. obviously people here are passionate enough about baseball to want to jigger a piece of software to watch it in a way better than is offered by MLB. please post the info here.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.