The problem, I think, is that you're not resolving the URLs.

I get the same errors, if I type in gobbledygook urls:

And the same error you got on urllib as well.


So here's one last experiment (though you'll probably have to reinstall python anyway).

First, try this:

That's google. Now if that doesn't work, I'm out of ideas. But if it does work, try this:

I get an IP as a response. What do you get?

General question: How much better is 800 compared to 400? Is it worth the extra couple of bucks?

daftcat

Well, still no luck after re-installing python. Perhaps I'll have to resort to waiting until the new version of Ubuntu is out this month and try that. Thanks again.

For me, definitely. Not mainly for the picture quality, but because the pans are *much* smoother. I found 400 really jerky when I watched it fullscreen.

jkr

Sorry I didn't see your post until just now. This is what I get:

I'll keep googling. Thanks for your time and help.

I just noticed that time_offset isn't listed as a config option in the README, I assume this is just an oversight, so here's a little reminder to add it when you get the chance.

You're right.

I'll let jkr update that one since he knows better what it does. I've got a vague idea.

By the way, time_offset is a feature we implemented post release of the last official release, e.g. it's an svn revision. As per my post a few pages back, you'll get the good, the bad, and the ugly pulling from our svn but we'll make sure that gets fixed by the next release.

Anything else? Looking good? Working good?

Maybe it's Friday and people have better things to do (I know I do in about 30 minutes), but so far, my stream problems seemed to have settled down since I added -user-agent NSPlayer. Again, it could just be coincidental. But I'm not complaining.

I used to think 400k was all I needed. I grew up through the PC revolution. The Internet as we know it was being born when I was in college. In high school, our first modem to connect to Prodigy was a 1400, I think. Not 14400. In college, my remote access was 14.4, then 28.8, and it remained there a long time before I went to 56k. It was right around the 28.8/56k days that internet video first showed up. It was pretty damn cool even if it was a grainy, choppy postage stamp. Back then I had the imagination and vision to say, "in the future, you'll be able to download any book, any movie, any tv show, any piece of music, any piece of art, any piece of information to your computer. The Internet will be an information commodity, a utility like power and gas. Every home will have a fat pipe of hot and cold running Internet." (It would have been nice if I wasn't a starving college student but had some investment capital at the time to make some money off that vision.) And now we have TV shows online and iTunes, Netflix, Youtube, eBooks, radio stations, etc.

The difference between 400k and 800k is like the quantum leap between the grainy, choppy video of yesteryear, and virtually indistinguishable from broadcast quality of television. I am totally sold on 800k as being worth every penny. I thought because 400k was choppy, my system wouldn't like 800k but it's so smooth, I can hardly believe I'm streaming this over the net. I've seen Digital Cable have more hiccups than this. I'm never wasting my money on Cable again. :-)

I should mention that my particular setup is a laptop connected to a wall mounted LCD. I used to have the laptop just there for playing digital music and the LCD connects to my DVD player (regular DVD player, not the laptop's.) But ever since I got mlbviewer working, I've been watching nothing but "all-you-can-eat" baseball whenever I'm home.

From across the room, 800k looks just as sharp as some of my DVD's. Up close it might look a little more synthetic, but I'm never that close to notice.

I can't watch 1200k on my Windows laptop. The Mosaic app takes up too much resources and the picture lags. You're not missing anything by not having the 1200k stream on Linux.

I've been looking at the network layer for mlbviewer. The good news is that we're already doing it exactly how the browser does it except we do it in as few requests as possible. To actually look like Firefox, we'd have to make a lot more useless requests. I don't think they are checking logs at that level so we're going to keep it lean underneath the hood. The one thing I can still do is make sure all our headers are correct. I know we're not building a correct Referrer string but that should be trivial to fix.

The even better news is that virtually every aspect of the MLB website is represented in xml format available on their servers. I've found everything from box scores, line scores, and TV schedules to Gameday information such as inning summaries, play by play, at bats, and pitchFx. I even found xml's for game time weather. The only thing I haven't found (yet) is the standings. I will find this eventually.

What does this mean for mlbviewer? Not much. Not yet.

I coded up a proof of concept scoreboard screen that was so code ugly, I didn't even commit it into svn. But, I've learned quite a bit about Python and XML since then (in the last 24-48 hours, heh.)

I will initially develop a scoreboard application as a standalone script that will be packaged with mlbviewer. Like mlbviewer, it will contain two parts: the libraries (the engine) and the interface. The interface will also be curses based. As the libraries mature (with testing from you all, I hope), we'll consider including the scoreboard into the mlbviewer interface. I'll make it pluggable from the get go, but I'll keep it separate until both mlbviewer and mlbscores are ready for marriage.

Gameday (not the audio but that cool app that shows all the play by play and box score information and updated in pseudo real time) is also a possibility if there is enough interest.

I'd actually like to see a meta structure where mlbviewer, mlbscores, mlbgameday, and whatever else are siblings rather than have mlbviewer trying to be the parent to all of them. It could mean that the libraries achieve a state of maturity (or popularity) that other open source projects spring up to use them. Perhaps a gtk application is better suited for implementing all these features under one application.

Anyway, let me know what you're interested in, not just for the viewer, but as a fan of baseball and a user of the mlb.com website. Also let me know if you're interested in becoming an early tester for mlbscores.

Cheers!
daftcat

I just wanted to report that I decided to upgrade to Ubuntu Hardy Heron - though it's not quite in official release yet - on a much older laptop and the mlbviewer script worked without a hitch! Not sure why I didn't think of that before. I'm only able to watch live games at 400 but archived games at 800 for now. Something must have gotten hooped with the python on my primary laptop, and I'll upgrade that one soon too.

Thanks for all your excellent work and help, jkr and daftcat. It's incredibly satisfying to watch a product I've paid for on an OS of my choosing. Keep up the good work!
oneil72

In an earlier post I asked if I could fast forward an archived game...Well, I switched over to VLC player for both audio and video feeds. You can go forward or backward in VLC with ease, since it does have a "time line bar" (Sorry if that isn't the technical term). Just pointing that out...I also found that VLC on my machine is more stable than mplayer...just my 2 cents...go tigers!

Any tricks to get VLC to fast forward or 'seek' or whatever you want to call it? Silly question being the video has been garbled beyond recognition (so it is useless to me) since the change that was the catalyst for creating mlbviewer.py but even as late as spring training when I could still use VLC for video and all of last year, whenever I tried to move the slider, it killed the connection.

Excellent!

That was a real head scratcher. I'm glad you found a resolution.

I think I mentioned this in an earlier post, but I can get VLC to seek only for about a minute or so after firing up a stream; after that, any seek kills the stream. My guess is that it's somehow related to the authentication -- if VLC "seeks" by simply re-starting the stream at a new position, this would make sense, since the auth tokens for each stream URL only last about a minute.

As I mentioned before, I would love to get the same behavior for mplayer since it allows me to skip pregames and VLC is a major pain to install on my OLPC... Anybody know anything more about how VLC seeks and how to get mplayer to do the same thing?

Incidentally, VLC sometimes shows garbled video for me but usually sorts itself out after a minute or so. Although I can't remember whether I had to install a special codec at some point in the past to get it to even work that well?...

Also, daftcat, did you say that you had / were going to implement a "play game when it starts" feature?