Hmm... I've done quite a bit of quitting and restarting as well as using multiple windows. Basically single sign-on logins only when you start mlbviewer. It doesn't logout when you quit mlbviewer. But each time you restart mlbviewer, it's going to login again. For starters, I'd verify you actually have the patch by checking for the existence of MLBviewer/mlblogin.py and also verifying that the splash screen says, "Logging into mlb.com..."

If you have the patch, then I'm not sure what's going on because I've done enough quit/restarts and simultaneous sessions that I should have been flagged by now. But I haven't been locked out all day since I implemented the change.

As for seeking, well, that's pretty much an mplayer/ffmpeg problem and not really anything to do with mlbviewer. There's nothing I can do in my code to help with that.

As I said before, if it's something you want, I'd recommend either trying a new build of mplayer2 or logging a bug with mplayer2 team and including a sample file. They have fixed bugs for us in the past.

Yep, I've got mlblogin.py and that's what I see at the splash screen. I just reproduced the problem by running mlbviewer, downloading part of a (nexdef) stream, hitting q to stop the download, then q again to quit mlbviewer. Repeat this once, then again. On the third time through, trying to download a stream gives me the sign-in error.

Yeah, I doubt it's an mlbviewer issue since it seems to be fetching the links fine. But given that mlbhls r36 grabbed streams that anything could play, my hope is that it'll be easier to get a workaround in mlbhls than to wait for upstream changes in the video players...

Aha... I just tried running mlbhls manually with the last link from my .mlb/log (these links seem to work forever in spite of sign-on restrictions!). I tried both the adaptive and the fixed-rate and mplayer can play both with no problems -- sound and scanning both work just fine. I even downgraded back to mplayer 1 and it plays everything fine, except for the crashes when seeking back through a speed change. So this makes me wonder if there's something funny about the options that mlbviewer is passing to mlbhls.

Here's what I ran manually:
Adding -L to lock the speed also gave me a viewable file, although for some reason it looked like the speed was 500K even though I tried it with -b 1200000 and -m 1200000 (and both).

It's way past my bedtime here so that's all I can do today, but hopefully that'll help make sense of whatever's going on...

No problem. My patches are located here:

http://theebuilds.googlecode.com/svn...player2/files/

You'll probably want to apply:

fix_ts.patch
<version>/demux_ts_h264.patch
<version>/mp2_new_live_seek.patch

Depending on the version of mplayer2 you're using will determine which patch to use. A couple months ago the ffmpeg guys changed their API's and broken everything that linked against it. So, depending on which ffmpeg you have installed will determine which version of mplayer2 to use. If you're using mplayer2 from svn, try the patches from "2.0_p20111126", if they don't apply I can update them. You can ignore the other patches, I use mplayer2 to drive my HTPC so they aren't relevant to playing mlb.tv streams.

My mplayer2 cmd:

If you're not using vdpau, you can omit the "-vc" and "-vo" params.

Let me know if you have any problems.

Single sign-on is not really supposed to save you from multiple mlbviewer restarts.

I'm not sure why you are restarting mlbviewer so many times. Is there something missing from the interface that would save you the restarts?

That said, I have tested the following without encountering sign-on restriction:

1. Multiple mlbviewer restarts in a short period of time.
2. Multiple instances of mlbviewer.
3. Multiple start/restart of streams without quitting mlbviewer.
4. Multiple start/restart of streams separated by hours of time without restarting mlbviewer (this is mostly just to prove that session information received in the morning is still valid later in the afternoon.)

One suggestion I might have is to remove ~/.mlb/cookie and ~/.sessionkey

Do this ONCE after your restriction has been lifted. Clearing these files on a regular basis is a surefire way to reproduce this issue as the server is, in essence, saying, "I already gave you cookies and session keys. Why do you keep asking for new ones?"

I think your "then quitting mlbviewer" is the issue here. The login is lost (by design) when mlbviewer is exited.

Daftcat, I have one further suggestion relating to this, which seems to work well. I normally watch in full-screen mode, and I have found that vlc and mplayer hang if mlbhls changes speeds when they are showing in full-screen mode rather than as a windowed display, so if I use mlbhls I use it in fixed bitrate mode. You can of course do this perfectly well with the standard stream, but the standard stream drops out once or twice a game, whereas mlbhls seems fault resistant. This can be important if you are, say, watching an archived game in extra innings which you can't select to get back into. mlbhls also of course allows you to change audio streams.

What would be useful when mlbviwer is using nexdef with a fixed bitrate is to be able to use the P key to cycle through max_bps speeds, say at 400k increments. This would mean using a key other than P to switch between adaptive mode and fixed bitrate mode, but would avoid having to exit mlbviewer and amend the config file in order to change speeds.

Ah sorry, I see this has been answered. I hadn't spotted that this thread has now moved onto page 236!

As a work-around, I have applied this patch which sets mlbhls, when in fixed bitrate mode, by reference to the speed value and not the max_bps value. This means I can toggle to standard stream mode with the 'n' key, pick the fixed speed Iwant with the 'p' key, and then toggle back to nexdef mode with the 'n' key.

This works for my needs, but a more sophisticated approach is to display the speed instead of [--] when in nexdef fixed bitrate mode, and to be able to toggle that with the 'p' key in the same way as when using the standard streams. That would require using a different key (say the 'f' key) to toggle between fixed and adaptive modes.

As the 'n' option isn't documented by the help key, I attach a patch for that also.

Attached Files

	speed.txt (540 Bytes, 13 views)
	documentation.txt (883 Bytes, 6 views)

Hmmm, I just got a sign-on restriction error after choosing different innings in one game and switching between standard and nexdef modes. I did not close down mlbviewer between switching innings and modes, so something else still seems to prompt MLB.TV's lock-out mechanism sometimes.

I will do more playing around. When I tried it last night the new login was working fine.

I usually do it when I change something in the config file and need to reload it; these days that's usually to switch between nexdef and basic streams, although sometimes I'll also change my preferred teams or the player command. I seem to recall there was some hotkey to reload the config, but if so I forgot what it is and it doesn't seem to be on the "h" screen...

I'll try to avoid re-opening mlbviewer excessively, although from Chris's comment it seems like there may still be some issues... I'll test later if I can.

I'm headed out now but just one more note before I go: I do think that the issue I'm having with the players is due to the options that mlbviewer passes to mlbhls. It looks like mlbviewer runs the following mlbhls command, and when I run it manually from the command line, I get the same behavior where my players can't play the file properly:

After a quick look through the mlbhls help screen, I can't see anything about a "-F" option; when I replace it with the "-f" option I was using before, I get a stream that mplayer handles just fine. That is:

works like a charm.

HTH

I'm pretty sure that mplayer2 can/does handle the bitrate/resolution change (that's how I tested). Make sure that you're limiting mplayer2 (and possibly vlc) to a single thread:

else you will get the error:

Are you using the latest experimental mlbhls?

You can switch between nexdef and basic streams within the application using the 'n' key.

At the moment, there is no hotkey to reload the configuration. Might be easy enough to add though. I'll look into that.