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.
I would like to watch an old game. Seattle Mariners at home Aug 15, 2012.
Tried the following but just go the 'game will begin shortly' screen. Is it possible to watch this game from mlbviewer?
python mlbplay.py v=sea j=08/15/12
Looks like it was archived with too much lead-in. If you don't want to wait for the actual broadcast to begin, you can start from the top of the first inning. You'll miss pre-game but that's probably okay, right? Just add i=t1.
playback_scenario in the listings XML file contained unnecessary whitespace:
" HTTP_CLOUD_WIRED " vs. "HTTP_CLOUD_WIRED"
This was causing everything to show up as "(No media)" even though media is finally available starting today.
Spring Training Status:
- [NEXDF] and audio seem to be working, though no games have actually started yet
- Non-nexdef mode seems to be working for 2400 speed, other speeds may not be working yet
Truth be told, I have to remind myself how all this works. Thankfully, the code is easier to follow since the rewrite last year.
Question for you, when using mlbplay instead of mlbviewer, does it actually log in every time rather than using the existing session/cookie? I keep getting a sign-on restriction error after trying to restart it 2 times (I'm the only user on the account)
I'm pretty stuck here, never had this kind of a problem with sign-on restrictions before.
Last edited by charlie460; 02-26-2014 at 12:27 PM.
Question for you, when using mlbplay instead of mlbviewer, does it actually log in every time rather than using the existing session/cookie? I keep getting a sign-on restriction error after trying to restart it 2 times (I'm the only user on the account)
I'm pretty stuck here, never had this kind of a problem with sign-on restrictions before.
It logs in every time just like mlbviewer logs in when you first start. However, just like mlbviewer, it saves the cookie and the session-key whenever either one of those is present, either in a login transaction or in a media request. From my experience, the session key is what is really important from one transaction to the next. Even though it does log in every time, if the session-key is not changing, it will re-use the session-key.
All that said, I am finding even with mlbviewer, I was getting Sign-On Restriction errors this morning. After all these years, I still don't understand the logic or rules behind Sign-On Restrictions and the only thing I can recommend is to wait it out (usually an hour) or try the web player (which also may trigger the Sign-On Restriction error.)
I would like to think these SOR errors are mostly Spring time issues that will get resolved as the Spring and Regular season progress. In the meantime, the only thing I can say is to be patient.
In case the MLB has made a permanent change to the behavior, would it be possible to keep a persistent login session, same as when viewing normally through the site? Rather than sending a login request upon each launch of the program?
It is possible that not every response which may contain a sessionkey is properly updating the sessionkey file. I have seen at least one instance today where a session-key was present in a reply but the sessionkey file hasn't been updated since Oct. I will look more closely into all the code surrounding media location replies and see if I am missing some calls to update the sessionkey file.
It's frustrating because I can now get SOR's just by performing several media requests within the same mlbviewer session.
In case the MLB has made a permanent change to the behavior, would it be possible to keep a persistent login session, same as when viewing normally through the site? Rather than sending a login request upon each launch of the program?
As near as I can tell, the whole point of logging in is to get current cookie and session-key values. Once logged in, it is not expected that these values should change until the session expires on the server. Although I can and do save the session-key and the cookie, the login code is a "head check" to allow MLB servers to reply with new values (e.g. if the session expired at the server.) I won't say "never" but it's probably not a good idea to skip the login step and rest upon saved values.
In the case of mlbplay (as opposed to the scripts in the test directory), all the code for mlbplay comes directly from the MLBviewer library. Besides being useful to simply jump directly to the desired media, it is also meant to be a demonstration of how someone might go about writing their own GUI for the MLBviewer library, e.g. "this is the program flow with the curses code stripped away." It would be a disservice to the MLBviewer library to make mlbplay use different procedures, classes, method calls, etc.
Because I can reproduce the SOR's in mlbviewer which does, as you suggest, login once and maintain/update a persistent session, I will focus my efforts on making sure that code is sane and doing the right thing. I expect that when I eliminate the SOR's from mlbviewer, mlbplay should also be rid of them too.
As near as I can tell, the whole point of logging in is to get current cookie and session-key values. Once logged in, it is not expected that these values should change until the session expires on the server. Although I can and do save the session-key and the cookie, the login code is a "head check" to allow MLB servers to reply with new values (e.g. if the session expired at the server.) I won't say "never" but it's probably not a good idea to skip the login step and rest upon saved values.
Isn't this what the site does? I.e., you log in, a cookie with an expiration date is set, if the cookies expires or the login fails for whatever reason, you'll get dumped back to the login screen?
Isn't this what the site does? I.e., you log in, a cookie with an expiration date is set, if the cookies expires or the login fails for whatever reason, you'll get dumped back to the login screen?
Let me fix mlbviewer first; if there really is a problem. It could be Spring Training jitters. Once I have SOR's under control in mlbviewer, I can look at whether it's possible to emulate web browser behavior in mlbplay. I'm actually pleased that mlbplay is getting more use, but I still believe the majority of users use mlbviewer.
FWIW, before I patched the -F option in mlbhls I used to have to run it manually after getting the 64-bit url out of the mlbviewer log file (so I'd go into mlbviewer, select a game, then quit and look at the log and get the link).
The interesting thing was that the 64-bit url wouldn't expire even if I did get an SOR from mlbviewer/mlbplay; I could go on running mlbhls to download the game as many times as I liked. I think I did this a few times with the non-nexdef link as well -- the link wouldn't expire even if I got an SOR.
Not sure whether that helps but I figured I'd post in case it helps clarify the (old) sign-in logic...
I found a couple of places where I was incorrectly initializing sessionKey = None rather than pulling it from the mlbSession object. I also found a couple of places where I was pulling sessionKey from a media reply but not writing the new sessionKey to the ~/.mlb/sessionkey file. So I guess you can say, I wasn't always using the cached value and I wasn't always caching the new value when I received it. I requested several different media this morning and have not received an SOR yet. I am not going to say it's completely fixed yet, but I haven't received an SOR with the new code revision (SVN rev 587.)
Please update to 587 and continue testing. Let me know if you are getting SOR's from 587 and I'll add some additional logging to figure it out.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.