Added disable_favorite_follow= option in r623. If present and set to 1 in your config, it will override the favorite follow code but does not disable highlighting or focus on favorite.

Seems to work, thanks!

Excellent!

So I did the following:

1. When starting up, I effectively convert your local time to US/Eastern before fetching the schedule.

2. For game times, I have implemented my own class to convert US/Eastern to UTC. This conversion was failing in the old code because it was using local time DST rules to determine whether US/Eastern was DST or not.

This should also fix a long standing issue where US goes on DST before the rest of the world and Spring Training times are off by an hour until local timezone goes to DST.

So the whole intent of media detail screen was to give a prettier face to the 'z' debug screen. The 'z' screen has been very useful to me over the years because it is the raw object debug of the listings screen. Since all the media-related commands are derived from the listings, there's actually a lot more contained in each line of the listings than what is displayed. Try the 'z' key on the default listings view. Lot of information. Kind of ugly. Of particular interest in this screen is the "prefer" line at the bottom. The "prefer" dictionary is built based on a combination of the coverage (home or away), the follow settings (video_follow, audio_follow, alt_audio_follow), and the general availability of media (sometimes only one stream is available so that's obviously preferred over the missing stream even though it may not be the coverage selected (e.g. a game forcing home coverage even though away is selected because there is no away stream available.)

In revision 624, I have replaced the redundant game status in the status line with the media that is preferred based on the settings and the availability. Also, for anyone interested in alternate audio, it is clear in this status line when the alternate audio is available given the settings and media availability.

It's a minor enhancement, but I hope you guys like it.

So my team is actually not in last place. You know what that means? That means I am looking for results from the teams in my team's division in the master scoreboard. Not always easy.

You know what would be easier? Highlight all the games in which a division team played in a separate color in master scoreboard view.

Here's how this works:

1. You must have a favorite team specified in favorite= option. Without it, the rest of this is skipped.

2. Open master scoreboard view ('m' key.)

3. Enable division highlighting with the 'D' key. (Remember lowercase 'd' is for DEBUG.)

4. The default division highlighting color is red. Assuming default colors, you'll see your favorite team in cyan and the cursor should jump right to it. The free game of the day will be green (yep! I finally added this to master scoreboard to match listings and media detail behavior.) The other games in your team's division will be highlighted in red. To turn off the highlighting, press the 'D' key again.

5. If you want to make this permanent (always highlight division teams in master scoreboard view), set highlight_division=1 in your config.

6. To change the colors, there are three color settings: free_color, favorite_color, and division_color. The possible choices are: black, red, green, yellow, blue, magenta, cyan, and white.

7. Colors are processed in this order: favorite, free, division. They are mutually exclusive: if your favorite team is colored, it won't also be colored with free or division color. If a division team is playing in the free game, it won't also show up in the division color.


This should be a disabled-by-default feature so I am not forcing you guys to use it. However, it solved a problem I had which means someone else might like it too. If you do find it useful, let me know. I like feedback.

Is there any possibility of a fix for the sign-on restriction problem? I don't know a ton about the internals of the MLB sign-on process, but with other authentication mechanisms, you can usually save the session cookie or whatever the site gives you to identify yourself between requests to disk (or a database, or whatever) and simply re-use those cached credentials until they expire and you have to re-authenticate. Any possibility of doing this with mlbviewer / mlbhls?

I'm a C and Python developer, so if someone can explain to me how the authentication handshake works, maybe I could work on a fix myself.

I believe I am already re-using session key but I want to redo the logging in mlbLogin.py to be certain.

I am out of town this weekend and the wifi here is pretty crappy. Give me a week to get back and recover from this weekend.

Just for info:
I always use mlbplay.py to start my games. When the game isn't available yet or the stream doesn't start but craps out, I have to try multiple times. After a few tries (I believe something between 5 and 10) I get the sign-on restriction error.

If I set favorite= then it seems to force video_follow on the same team. How can I highlight my favorite team but not force the away feed when they're on the road?

I figured it out, I had to update mlbviewer to the latest SVN and then set disable_favorite_follow=1 (don't ask me how I figured that out).

Anyways, that should be documented better for those of us who have a basic subscription so can't video_follow our team on the road (yes I should really just stop pinching pennies and fork out the extra $5/month for a premium sub).

Back home from being on the road for the better part of the last two weeks. My main development laptop needs some surgery tonight (replace the LCD hinge) and I could definitely use more sleep than I got this past weekend. I will have a look at the session/authentication code in the next few days. It looks like it's doing everything right in mlbviewer but I cannot say the same about mlbplay. Also, it could take awhile to fix if I get Sign-On Restriction errors since I generally don't have very many development hours available each day.

If you're encountering frequent Sign-On Restriction errors and you are also using mlbplay primarily, switching to mlbviewer won't make an SOR error go away but it may make them appear less frequently.

Just in case it helps anyone: in my experience, game links already retrieved by mlbplay or mlbviewer will still work even after a sign-on restriction (it's only discovery of new links that is blocked). So if the stream crashes a few times and you get blocked, you can fish the link out of the .mlb/log file and use it to run mlbhls or rtmpdump manually.

mlbhls, yes. This is true. rtmpdump links expire. Not super quickly, but they do seem to have a limited lifetime (unless they have changed that in recent years.)

Found a rather big bug in MLBSession.readSessionKey() that was being masked by incorrect error checking. Basically, the stored session key was never being re-used because readSessionKey() routine was broken.

I added "k=1" as an option to mlbplay which is session-key debugging. It will display the value read from MLBSession.readSessionKey() in init() (stored session-key) and the value returned from MLBMediaStream.locateMedia() (media requests.) You should see two extra lines at the top of the output, e.g.

Depending on how long it's been since you last ran mlbplay, these values may not be the same. However, within several hours (not sure how long the session-key is good for), this value should not change.

If you just want to beat up the new readSessionKey fix, try running this many times in succession:

That will request the video for Dodgers, print the nexdef base64 URL and exit without starting a player. The new k=1 will how the session key being re-used for as long as the key is good on the server.

The reason why mlbplay was a lot more susceptible to SOR errors than mlbviewer is that mlbviewer will re-use the session key for the lifetime of that mlbviewer session even if the stored value was missing (buggy readSessionKey routine.) On the other hand, mlbplay was always starting without a session key because readSessionKey was broken and even if it stored the correct key from the media response, it was unable to read it and use it the next time it ran due to the bug this revision fixes.

I can't guarantee that this will resolve any or all SOR errors but it will certainly get us closer to the desired functionality.

Didn't want to annoy MLB too much but I did just run the command above in a while loop for at least 10 iterations without an SOR error. I even got to see the session key change to a new value and that new value getting used the very next time.

For those who still prefer mlbviewer to mlbplay, you can watch session key actions in ~/.mlb/cookielog.