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.
Interesting about the errors. What version of ClientForm are you using? And where is it from -- you're using Etch, right? Or unstable?
I wonder if the author made ClientForm more tolerant, or if there are certain distro specific patches. If it's necessary, I'll look into having the script tidy up the HTML itself. I might ask you to test it out using whatever your original config was, though, if that's okay.
Speaking of ClientForm, a general note for folks who are annoyed by that deprecation warning that appears each time you select a game. I have gotten rid of it in the new version, but if you want to get rid of it now, find the following line:
forms = ClientForm.ParseResponse(fp)
and change it to
forms = ClientForm.ParseResponse(fp, backwards_compat=False)
Finally, a question for folks here: another feature that wouldn't be too hard to implement would be to have a few playback options on each line (video, audio, condensed if archived). Up-down would switch games, right-left would switch options, and then some other controls would switch days. Each playback could have its own default player (mplayer, xmms, etc).
So, the question -- is that something that people would use, or would it just clutter up the interface?
I think it would be a worthwhile addition. Using mplayer for video is probably what most people would choose, but you need a player with a GUI for audio-only, otherwise you'd have to kill it from the command line. So if video and audio feeds will be integrated into the same interface, I do think you'd need to have the ability to use different players for each.
Traceback (most recent call last):
File "./mlbviewer.py", line 342, in <module>
curses.wrapper(mainloop,datadct['user'],datadct['pass'])
File "curses/wrapper.py", line 44, in wrapper
File "./mlbviewer.py", line 303, in mainloop
available = getListings(mysched)
File "./mlbviewer.py", line 233, in getListings
('I','W', 'F')]
KeyError: '1200'
Interesting about the errors. What version of ClientForm are you using? And where is it from -- you're using Etch, right? Or unstable?
I wonder if the author made ClientForm more tolerant, or if there are certain distro specific patches. If it's necessary, I'll look into having the script tidy up the HTML itself. I might ask you to test it out using whatever your original config was, though, if that's okay.
Speaking of ClientForm, a general note for folks who are annoyed by that deprecation warning that appears each time you select a game. I have gotten rid of it in the new version, but if you want to get rid of it now, find the following line:
forms = ClientForm.ParseResponse(fp)
and change it to
forms = ClientForm.ParseResponse(fp, backwards_compat=False)
Finally, a question for folks here: another feature that wouldn't be too hard to implement would be to have a few playback options on each line (video, audio, condensed if archived). Up-down would switch games, right-left would switch options, and then some other controls would switch days. Each playback could have its own default player (mplayer, xmms, etc).
So, the question -- is that something that people would use, or would it just clutter up the interface?
I'm using Etch but I think some testing packages might have sneaked onto my system. ;-) I forget what it was for, but I know I had to move to testing for something. Then one day I selected something simple and it wanted to upgrade about 40 packages and I reverted back to etch in my sources.list.
I'd be happy to test whatever you come up with. That's what I do for a living. ;-)
Here's what dpkg says about clientform:
Code:
matthew@tango:~$ dpkg --status python-clientform
Package: python-clientform
Status: install ok installed
Priority: extra
Section: python
Installed-Size: 280
Maintainer: Debian/Ubuntu Zope Team <pkg-zope-developers@lists.alioth.debian.org>
Architecture: all
Version: 0.2.2-3
Replaces: python2.3-clientform (<< 0.2.2), python2.4-clientform (<< 0.2.2)
Provides: python2.4-clientform
Depends: python, python-central (>= 0.5.8)
Conflicts: python2.3-clientform (<< 0.2.2), python2.4-clientform (<< 0.2.2)
Description: module for handling HTML forms on the client side
ClientForm is a Python module for handling HTML forms on the client side,
useful for parsing HTML forms, filling them in and returning the completed
forms to the server. It developed from a port of Gisle Aas' Perl module
HTML::Form, from the libwww-perl library, but the interface is not the same.
.
Homepage: http://wwwsearch.sourceforge.net/ClientForm/
Python-Version: all
matthew@tango:~$
I think it would be a worthwhile addition. Using mplayer for video is probably what most people would choose, but you need a player with a GUI for audio-only, otherwise you'd have to kill it from the command line. So if video and audio feeds will be integrated into the same interface, I do think you'd need to have the ability to use different players for each.
I never just listen to the audio but I imagine if I did, I'd want to use mpd since I use a php/mpd solution for all my audio needs. My Linux box is more an appliance than a desktop.
Speaking of which, jkr, is there a way to add DISPLAY env variable to mlbviewer? I guess I could wrap it up in my original mlbplay script since that also tweaks my screensaver settings. I'll give that a try tonight.
For my specific setup, I use the local display from a remote machine. I like watching a game (or having it on in the background) from across the room while still having my primary laptop free to do whatever it is I do (which is usually hacking away at some project or another.)
T
Finally, a question for folks here: another feature that wouldn't be too hard to implement would be to have a few playback options on each line (video, audio, condensed if archived). Up-down would switch games, right-left would switch options, and then some other controls would switch days. Each playback could have its own default player (mplayer, xmms, etc).
So, the question -- is that something that people would use, or would it just clutter up the interface?
I'm sure there are a lot of people out there that would appreciate being able to select audio-only streams (myself included), so I think it would be a very useful addition.
Using the Firebug method, I tried to open an audio stream using my MPD client. I got this in the mpd error log: "Input does not appear to be a mp3 bit stream"
Using the Firebug method, I tried to open an audio stream using my MPD client. I got this in the mpd error log: "Input does not appear to be a mp3 bit stream"
It sounds like you can configure mplayer to decode formats mpd doesn't natively support.
As long as I'm going to that trouble, I'd probably use mplayer directly. The only advantage I can see to using mpd would be if I wanted to hack mlbviewer to trade curses output for a web page interface instead. That's not a bad idea, actually, but I'm not sure how many other users would find this useful.
As I'd rather blow my bandwidth on the audio and video even if I'm not always watching the video, I'd rather figure out now to download the games and watch them locally. I'm sure mplayer has some kind of filesystem output plugin. I just haven't tried really hard to find out about it. If it's not too difficult, I might trade the curses for a web interface so I can select games to "record" from work so they'll be ready for me when I get home.
Of course, this is probably mlb.com's worst fear of supporting Linux. ;-) At least I'm not a torrent user.
Is anyone else having a problem with a concurrent connection error on live games? I can't tell if it's their fault, the script's fault, or if they just don't like me all of a sudden.
Is anyone else having a problem with a concurrent connection error on live games? I can't tell if it's their fault, the script's fault, or if they just don't like me all of a sudden.
I haven't watched any live games with your script yet. I got the record functionality hacked in. I'll let you know if I have problems recording a live game just as soon as the KC game starts.
I haven't watched any live games with your script yet. I got the record functionality hacked in. I'll let you know if I have problems recording a live game just as soon as the KC game starts.
I'm thinking more about this, and recording a game is really only useful if I can schedule the task. Otherwise, I'd have to be right there when the game starts. Does python have an ability to schedule tasks?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
