LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Fedora
User Name
Password
Fedora This forum is for the discussion of the Fedora Project.

Notices

Reply
 
Search this Thread
Old 03-27-2012, 10:30 PM   #3571
fang2415
Member
 
Registered: Jan 2007
Posts: 159

Rep: Reputation: 15

I still get the restriction after three or four tries at a stream with r350. I didn't try removing the old cookie file though, I can try that next time.

It does occur to me that this may not be all that high a priority, since what's actually most important to me is to ensure that *you* don't get sign-on errors that slow down development! But the restriction can be annoying, especially when I'm trying to fix something on my end, so I do appreciate your work to try to figure out what the fsck is going on here.

It is somewhat maddening that this is only reproduceable on my end... Is there some debug information or a log or something that I could give you that could help you track it down?
 
Old 03-28-2012, 01:45 AM   #3572
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Totally strange. I finally got my first sign-on restriction since re-doing the code by telling my code to not ignore the 'discard' setting on certain cookies. The 'discard' flag, if set, is supposed to tell the client not to save that cookie morsel. Anyway, I have gone back to ignoring the 'discard' flag and I'm not seeing sign-on restrictions again even after running mlbplay.py in a loop for 10 times with 10 seconds between requests.

One thing I added to rev 351 is a cookielog. Please do the following:

Code:
$ rm ~/.mlb/cookie
$ rm ~/.mlb/sessionkey
Then use mlbviewer/mlbplay however you use it. If you encounter sign-on restrictions, please post ~/.mlb/cookielog to paste.bin and post the resulting url here.

I will also add in writing the negative response ('sign-on restriction' xml reply) to a log file when it comes in to see if that contains anything meaningful. I'll make this change in the next day or two.

EDIT: I already have this code in. Don't remember when I added that. For any error code, I write the xml reply to /tmp/unsuccessful.xml. I checked mine after the sign-on error earlier and there is nothing useful in that log.

Last edited by daftcat; 03-28-2012 at 01:48 AM.
 
Old 03-28-2012, 02:22 PM   #3573
chrisVV
Member
 
Registered: Aug 2010
Posts: 110

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
EDIT: I already have this code in. Don't remember when I added that. For any error code, I write the xml reply to /tmp/unsuccessful.xml. I checked mine after the sign-on error earlier and there is nothing useful in that log.
I was wondering whether to mention that. The effect unfortunately is that it doesn't work with more than one user on the system, because the file is first written with 0644 permissions, so only the first user to write it can write it again. There are three solutions: give it 0666 permissions, or (better) name the file /tmp/$USER-unsuccessful.xml or write it to $HOME.
 
Old 03-28-2012, 03:42 PM   #3574
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
I was wondering whether to mention that. The effect unfortunately is that it doesn't work with more than one user on the system, because the file is first written with 0644 permissions, so only the first user to write it can write it again. There are three solutions: give it 0666 permissions, or (better) name the file /tmp/$USER-unsuccessful.xml or write it to $HOME.
How many users are you using mlbviewer with? Maybe that's the cause of your sign-on restrictions? I mean it shouldn't matter since presumably your only using one set of login credentials for mlb.com. However, you are presenting two different cookies and this could make it look like your sharing your account....

Even though there's nothing useful in this particular "Sign-on Restriction" response page, I have taken the third approach and moved the location of the file to $HOME/.mlb/unsuccessful.xml.

Last edited by daftcat; 03-28-2012 at 04:32 PM.
 
Old 03-28-2012, 04:47 PM   #3575
fang2415
Member
 
Registered: Jan 2007
Posts: 159

Rep: Reputation: 15
Removed ~/.mlb/cookie, started mlbviewer, started to load a stream, then quit, got the restriction on the fourth try. No multiple users, logins to website, or any other fancy stuff that I'm aware of. I never see any sessionkey files whenever I look. ~/.mlb/cookielog is as follows:

Code:
LOGIN> No cookie filepre-login:
Printing relevant cookie morsels...
post-login: (this gets saved to file)
Printing relevant cookie morsels...
ipid = 5973850
fprt = RmlsNGpvdEdYY016YWFocTdnUk5PczRyL0pnPXwxMzMyOTcwMDQ0OTcxfGlwdD1lbWFpbC1wYXNzd29yZA %3D%3D
Logged in successfully!
getSessionData:
Printing relevant cookie morsels...
ipid = 5973850
fprt = RmlsNGpvdEdYY016YWFocTdnUk5PczRyL0pnPXwxMzMyOTcwMDQ0OTcxfGlwdD1lbWFpbC1wYXNzd29yZA%3D%3D
Doesn't look all that helpful to me, but maybe you can see something useful there...

One thing that occurred to me is that I believe I'm on the non-premium service plan, which could be different to your setup. Still wouldn't make much sense for that to cause this, but it's one possible difference anyway.

Is there a way that I could produce some useful debug output every time I try to fetch a link? It seems like whatever is going wrong must be happening at that point, and from your description it sounds like none of that code is supposed to be accessing anything that could trigger a restriction; so it seems sensible to look there for something unexpected.
 
Old 03-28-2012, 04:55 PM   #3576
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Quote:
Originally Posted by fang2415 View Post
Removed ~/.mlb/cookie, started mlbviewer, started to load a stream, then quit, got the restriction on the fourth try. No multiple users, logins to website, or any other fancy stuff that I'm aware of. I never see any sessionkey files whenever I look. ~/.mlb/cookielog is as follows:

Code:
LOGIN> No cookie filepre-login:
Printing relevant cookie morsels...
post-login: (this gets saved to file)
Printing relevant cookie morsels...
ipid = 5973850
fprt = RmlsNGpvdEdYY016YWFocTdnUk5PczRyL0pnPXwxMzMyOTcwMDQ0OTcxfGlwdD1lbWFpbC1wYXNzd29yZA %3D%3D
Logged in successfully!
getSessionData:
Printing relevant cookie morsels...
ipid = 5973850
fprt = RmlsNGpvdEdYY016YWFocTdnUk5PczRyL0pnPXwxMzMyOTcwMDQ0OTcxfGlwdD1lbWFpbC1wYXNzd29yZA%3D%3D
Doesn't look all that helpful to me, but maybe you can see something useful there...

One thing that occurred to me is that I believe I'm on the non-premium service plan, which could be different to your setup. Still wouldn't make much sense for that to cause this, but it's one possible difference anyway.

Is there a way that I could produce some useful debug output every time I try to fetch a link? It seems like whatever is going wrong must be happening at that point, and from your description it sounds like none of that code is supposed to be accessing anything that could trigger a restriction; so it seems sensible to look there for something unexpected.
Is this all that was in cookielog? I don't see ftmu which is the session key. I don't think I write the sessionkey file anymore since ftmu should be part of the cookie file. If you are not seeing ftmu at all, this could be a cause of the sign-on restrictions. I'll add response logging for the messages which I am expecting to parse ftmu from.
 
Old 03-28-2012, 05:37 PM   #3577
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Revision 353: Parse session-key from media location response

I thought I was already doing this but it must have been a leftover from a different algorithm.

I am now looking for the <session-key> element in the media location responses and re-using those in future requests.

If you have any problems, please paste log, cookielog, and session.xml to http://pastebin.com Please post it to there as it is easier to read and longer pastes don't get shuttered into a tiny scrollbox like they do on this site. Please post the session.xml after each request. It will get overwritten. I want to see whether the session key returned in the response is the same from one request to the next. It should be. But it could get autogenerated if we aren't presenting our own cached sessionkey (ftmu in the cookie.)

Last edited by daftcat; 03-28-2012 at 06:20 PM.
 
Old 03-28-2012, 06:16 PM   #3578
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Revision 355: This should solve the sign-on restriction errors

Instead of simply passing the cookie data from the MLBSession object, I am passing the object itself to GameStream. So now when I get a session-key in the media reply, I can update the MLBSession object so the next GameStream object will get that session-key. I am also writing the cookie file again after I have parsed out the session-key from the media reply and copied that session key back into the ftmu cookie in the MLBSession object.

I tested this by purposely not extracting the ftmu cookie in extractCookies method used in MLBSession. Instead, I parsed it from the reply and updated the MLBSession object. The next GameStream object should receive that session-key.

Please test away with this revision and post the log, cookielog, and session.xml to http://pastebin.com only if you continue to have sign-on restriction errors.

Last edited by daftcat; 03-28-2012 at 06:21 PM.
 
Old 03-28-2012, 06:38 PM   #3579
chrisVV
Member
 
Registered: Aug 2010
Posts: 110

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
How many users are you using mlbviewer with? Maybe that's the cause of your sign-on restrictions? I mean it shouldn't matter since presumably your only using one set of login credentials for mlb.com. However, you are presenting two different cookies and this could make it look like your sharing your account....
Formally, two user names. The first is me on a compositing (gnome-shell) desktop on my netbook, when I use it as a free-standing computer when out and about. The second is me (albeit with a different user name) on my netbook with a non-compositing desktop, which gives better results when I feed it into my HD wide-screen TV. Having two user names happens to be a convenient way of switching between compositing and non-compositing desktops.

That is not I think the cause of the login restrictions. I use it nearly always with the non-compositing desktop, connected to the TV, and have been doing so for the last week. But I noticed it a week or so ago when I briefly tried it in compositing mode, to see what it was like. I didn't mention it as a bug because it seemed a pretty trivial point (and because chmod 0666 corrected the problem).
 
Old 03-28-2012, 07:00 PM   #3580
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
Formally, two user names. The first is me on a compositing (gnome-shell) desktop on my netbook, when I use it as a free-standing computer when out and about. The second is me (albeit with a different user name) on my netbook with a non-compositing desktop, which gives better results when I feed it into my HD wide-screen TV. Having two user names happens to be a convenient way of switching between compositing and non-compositing desktops.

That is not I think the cause of the login restrictions. I use it nearly always with the non-compositing desktop, connected to the TV, and have been doing so for the last week. But I noticed it a week or so ago when I briefly tried it in compositing mode, to see what it was like. I didn't mention it as a bug because it seemed a pretty trivial point (and because chmod 0666 corrected the problem).
Yeah, I don't think that's an issue either since I use at least three different machines. I think you and fang have been missing session-key (ftmu) in your cookie and I wasn't parsing it from media replies like I used to. This recent revision should fix that and possibly put this problem to rest once and for all.

Fingers crossed waiting for the verdict...
 
Old 03-28-2012, 08:20 PM   #3581
fang2415
Member
 
Registered: Jan 2007
Posts: 159

Rep: Reputation: 15
Quote:
Originally Posted by daftcat View Post
Instead of simply passing the cookie data from the MLBSession object, I am passing the object itself to GameStream. So now when I get a session-key in the media reply, I can update the MLBSession object so the next GameStream object will get that session-key. I am also writing the cookie file again after I have parsed out the session-key from the media reply and copied that session key back into the ftmu cookie in the MLBSession object.

I tested this by purposely not extracting the ftmu cookie in extractCookies method used in MLBSession. Instead, I parsed it from the reply and updated the MLBSession object. The next GameStream object should receive that session-key.

Please test away with this revision and post the log, cookielog, and session.xml to http://pastebin.com only if you continue to have sign-on restriction errors.
Hmm, not sure I quite follow all of this... but it seems to have worked! I just start-stopped about a dozen streams with no restriction!

It now occurs to me that maybe there was a permissions problem trying to write the sessionkey or session.xml files? I never saw any of those files, despite watching ~/.mlb/, /tmp/, and ~/ like a hawk at all points during and after running mlbviewer. I do run mlbviewer from a folder in ~ (i.e., I do "python ~/mlbviewer/trunk/mlbviewer.py"), rather than doing a system-wide install -- maybe that somehow prevents the session file from getting written to the proper place? It might also account for the fact that it's now working, since it sounds like you're passing the session info between objects directly rather than reading it from a file?

Anyway, the thing works. Thanks a million for all your patient work through a frustrating bug. Fingers crossed that MLBAM doesn't now completely change the login procedure for the regular season!...
 
Old 03-28-2012, 08:38 PM   #3582
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Quote:
Originally Posted by fang2415 View Post
Hmm, not sure I quite follow all of this... but it seems to have worked! I just start-stopped about a dozen streams with no restriction!

It now occurs to me that maybe there was a permissions problem trying to write the sessionkey or session.xml files? I never saw any of those files, despite watching ~/.mlb/, /tmp/, and ~/ like a hawk at all points during and after running mlbviewer. I do run mlbviewer from a folder in ~ (i.e., I do "python ~/mlbviewer/trunk/mlbviewer.py"), rather than doing a system-wide install -- maybe that somehow prevents the session file from getting written to the proper place? It might also account for the fact that it's now working, since it sounds like you're passing the session info between objects directly rather than reading it from a file?

Anyway, the thing works. Thanks a million for all your patient work through a frustrating bug. Fingers crossed that MLBAM doesn't now completely change the login procedure for the regular season!...
/tmp/unsucessful.xml was written whenever we receive a statuscode other than successful from the media request. In the case of this particular bug, there was nothing really useful in that file.

In the $HOME/.mlb directory,

sessionkey used to be the old location to store the sessionkey ; not sure when or why I did away with this file
session.xml is only being written when debug is enabled and it is the media reply in the xml format returned to us (that would be helpful for checking that we are receiving a <session-key> element.
cookie and cookielog are being written with or without debug enabled. I added a COOKIE_DEBUG variable to the top of MLBviewer/mlblogin.py to override whatever debug setting is in the main configuration file (maybe I should do this for session.xml above?)

In any case, I'm glad it's finally working. Seeing your cookielog without 'ftmu' tipped me off to where I needed to look to make this all work.

In case you're curious to what changed, in easy terms, even before moving login code to its own class, I was expecting to get the session key ('ftmu' cookie) from the workflow page but I was also looking to parse it from the media location response. You guys were not getting an 'ftmu' from workflow page and the code to look for it in the media location response was incorrect. The last few revisions was just getting that information from the current game request (which is disposable data) back to the main session object (which remains alive from game request to game request.) Since 'ftmu' (session key) doesn't change from request to request within a session, and we only login once, all requests should now look like they came from the same session. Since I am now correctly parsing from the reply, if the server decides that session key is no longer valid and wants to give us a new session key, this can get passed back to the session object so that future requests will use the current key.

Last edited by daftcat; 03-28-2012 at 09:06 PM.
 
Old 03-28-2012, 09:18 PM   #3583
fang2415
Member
 
Registered: Jan 2007
Posts: 159

Rep: Reputation: 15
Quote:
Originally Posted by daftcat View Post
/tmp/unsucessful.xml was written whenever we receive a statuscode other than successful from the media request. In the case of this particular bug, there was nothing really useful in that file.

In the $HOME/.mlb directory,

sessionkey used to be the old location to store the sessionkey ; not sure when or why I did away with this file
session.xml is only being written when debug is enabled and it is the media reply in the xml format returned to us (that would be helpful for checking that we are receiving a <session-key> element.
cookie and cookielog are being written with or without debug enabled. I added a COOKIE_DEBUG variable to the top of MLBviewer/mlblogin.py to override whatever debug setting is in the main configuration file (maybe I should do this for session.xml above?)

In any case, I'm glad it's finally working. Seeing your cookielog without 'ftmu' tipped me off to where I needed to look to make this all work.

In case you're curious to what changed, in easy terms, even before moving login code to its own class, I was expecting to get the session key ('ftmu' cookie) from the workflow page but I was also looking to parse it from the media location response. You guys were not getting an 'ftmu' from workflow page and the code to look for it in the media location response was incorrect. The last few revisions was just getting that information from the current game request (which is disposable data) back to the main session object (which remains alive from game request to game request.) Since 'ftmu' (session key) doesn't change from request to request within a session, and we only login once, all requests should now look like they came from the same session. Since I am now correctly parsing from the reply, if the server decides that session key is no longer valid and wants to give us a new session key, this can get passed back to the session object so that future requests will use the current key.
Hmm, I may have understood a bit more of that this time... But it made me curious about something, which seems to have allowed me to reproduce the bug again, albeit in a different and slightly less important use case.

I still don't see any ftmu info in my cookie file, which made me wonder if mlbviewer would handle session info properly even after restarts. So I went back to quitting mlbviewer after start-stopping each stream, and I got the sign-on restriction after the third try again. Obviously that's not nearly so big of a deal now that I can keep trying forever as long as I don't close the mlbviewer; but it seems like something still may being going wrong with writing ftmu to the cookie file. Text of my .mlb/cookie is at http://pastebin.com/DrqMYjhY if it helps.

Mind you, feel free to ignore this issue at this point -- it may be easier to simply tell users to avoid restarting mlbviewer than to track this bug to the end of the earth!...

Many thanks again.

Last edited by fang2415; 03-28-2012 at 09:19 PM.
 
Old 03-28-2012, 10:02 PM   #3584
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,766

Rep: Reputation: 76
Quote:
Originally Posted by fang2415 View Post
Hmm, I may have understood a bit more of that this time... But it made me curious about something, which seems to have allowed me to reproduce the bug again, albeit in a different and slightly less important use case.

I still don't see any ftmu info in my cookie file, which made me wonder if mlbviewer would handle session info properly even after restarts. So I went back to quitting mlbviewer after start-stopping each stream, and I got the sign-on restriction after the third try again. Obviously that's not nearly so big of a deal now that I can keep trying forever as long as I don't close the mlbviewer; but it seems like something still may being going wrong with writing ftmu to the cookie file. Text of my .mlb/cookie is at http://pastebin.com/DrqMYjhY if it helps.

Mind you, feel free to ignore this issue at this point -- it may be easier to simply tell users to avoid restarting mlbviewer than to track this bug to the end of the earth!...

Many thanks again.
Yeah. Now I remember why I had a separate sessionkey file. Just putting that value back into the cookies array is not the same as creating a new cookie value that can be written when I call the save. Now that I know the problem, I can go back to using the sessionkey file which, honestly, may or may not fix the problem anyway. Strange that I get a ftmu cookie from workflow and that you don't. Well, the upside to this is that except for new revisions, you shouldn't have to restart mlbviewer anymore with the config reload and the options debug.
 
Old 03-29-2012, 12:34 AM   #3585
rmbellovin
LQ Newbie
 
Registered: Apr 2010
Posts: 21

Rep: Reputation: 0
Hi, I'm getting a new error (new since this afternoon). I try to run mlbviewer.py, and it says it's logging in, then dies with the following message:

Quote:
Traceback (most recent call last):
File "mlbviewer.py", line 1596, in <module>
curses.wrapper(mainloop, mycfg.data)
File "/usr/pkg/lib/python2.7/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
File "mlbviewer.py", line 491, in mainloop
+ len(coveragetoggle.get(cfg['coverage'])) + 2
TypeError: object of type 'NoneType' has no len()
This is with revision 356. I tried reverting to 350 (which is what I had this afternoon, but I got the same result. Maybe it's because there are no games going on at the moment? mlblistings.py works fine, and mlbplay.py worked fine for the archived audio from today I tried (although it said it couldn't find the stream for the condensed was-nym game).
 
  


Reply

Tags
help, install, installation, instructions, seek, vlc, windows


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
mlb.com gameday audio stream statmobile Linux - Newbie 6 05-06-2008 10:16 PM
link dies intermittently-seemingly at random- between win<->linux not linux<->linux?? takahaya Linux - Networking 10 03-09-2007 10:37 PM
triple boot linux/linux/linux No Windows involved toastermaker Linux - Newbie 12 03-02-2006 10:40 PM
Redhat (rhel v2.1) bootup problem with linux (linux vs linux-up) namgor Linux - Software 2 06-24-2004 02:49 PM


All times are GMT -5. The time now is 08:53 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration