MLB.TV in Linux

daftcat · 03-26-2012, 11:28 AM

Quote:

Originally Posted by fang2415

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:

Code:

mlbhls -B [link] -L -s 1200000 -F 16:00:12 -o mlb/video.ts

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:

Code:

mlbhls -B [link] -L -s 1200000 -f 48 -o mlb/video.ts

works like a charm.

HTH

-F option was added in the most recent mlbhls to support start timecode (e.g. ability to start at the correct time rather than the guess of 48 time slices into the m3u8 file) as well as jump to innings for nexdef support. Given how much more useful both of these are, I will not be removing the -F option.

To fix any seeking issues, file a bug with mplayer2 team.

chrisVV · 03-26-2012, 12:32 PM

Quote:

Originally Posted by thegryghost

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:

Code:

mplayer2 -lavdopts threads=1

else you will get the error:

Code:

Width/height/bit depth/chroma idc changing with threads is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.

I have added -lavdopts threads=1 to the command line and it works OK now in full screen mode. There ought to be some documentation on this (apologies if there is)! The ffmpeg version in use by mplayer2 is the one which is linked to internally by the mplayer2-build-2.0 tarball.

I have not had a recurrence of the lock-out. Maybe there is a lifetime to the cookie from yesterday which causes problems. I deleted the cookie after the lock-out, waited an hour, and since then it has been OK.

daftcat · 03-26-2012, 04:24 PM

I'm not entirely sure if there will be any backfire repercussions of this but I'm trying it anyway.

I implemented a 'R'eload configuration option. Yes, it has to be 'R' (uppercase R) because 'r' (lowercase) is used for refreshing the listings.

With 'R', it recreates the cfg dictionary and refreshes the listings.

This should also put off implementing a speed control for nexdef as you can change your min_bps, max_bps in your config and 'R'eload it.

If you want, I can implement another debug screen to show some config settings and values. I need to implement a better paging mechanism than what bookmarks uses (or just proceduralize that) to handle more lines than CURSES.lines. Until then, I can either dump the raw python representation or just pick and choose which variables to display on this debug screen.

daftcat · 03-26-2012, 04:53 PM

'o'ptions debug screen combined with 'R' should give you power users enough information to edit your config, reload it, and see that mlbviewer is using the new values. The one blind spot to all of this is that login only occurs at mlbviewer startup. If you change anything that affects the login (user= or pass=), you'll need to restart mlbviewer. But that should be very rare.

EDIT: If your *_player line (or any other option) is longer than one line of output, it gets truncated to fit on the screen. This is just a display thing. The program still uses the entire line when it's time to use it.

fang2415 · 03-26-2012, 06:25 PM

Quote:

Originally Posted by thegryghost

Are you using the latest experimental mlbhls?

Code:

svn info
URL: https://mlbtv-hls-nexdef.googlecode.com/svn/branches/experimental
..
..
Revision: 56

Looks like it:

Code:

fang2415@jaw-dell-1:~/mlbhls$ svn info
Path: .
URL: https://mlbtv-hls-nexdef.googlecode.com/svn/branches/experimental
Repository Root: https://mlbtv-hls-nexdef.googlecode.com/svn
Repository UUID: f259b058-16ce-0779-9161-39c490c157d4
Revision: 56
Node Kind: directory
Schedule: normal
Last Changed Author: thegryghost
Last Changed Rev: 55
Last Changed Date: 2012-03-21 06:46:29 +0000 (Wed, 21 Mar 2012)

chrisVV · 03-26-2012, 06:36 PM

I have obtained another sign on restriction.

The pattern I am observing is that this can arise after an attempt to play a stream has failed, say because there was no video for the game in question. Is there something in the login logic which doesn't handle the failure case?

fang2415 · 03-26-2012, 06:36 PM

Quote:

Originally Posted by daftcat

-F option was added in the most recent mlbhls to support start timecode (e.g. ability to start at the correct time rather than the guess of 48 time slices into the m3u8 file) as well as jump to innings for nexdef support. Given how much more useful both of these are, I will not be removing the -F option.

Yep, makes sense to me. But hopefully we can get -F to produce streams that were as easy to view as with -f.

Quote:

To fix any seeking issues, file a bug with mplayer2 team.

Actually, I think the seeking issue only happens with mplayer 1. That was never a big issue given that the speeds rarely change and I rarely seek backwards; but now that I realize that mplayer2 is in the Ubuntu repos, that problem is so easy to workaround that I don't even need to worry about whether I'm smart enough to report the bug helpfully!

Thanks for the options reload, that will cut down significantly on the need to restart! As always, MLBAM should be paying you (and TGG!) shedloads for your work on this.

fang2415 · 03-26-2012, 07:12 PM

Quote:

Originally Posted by chrisVV

I have obtained another sign on restriction.

The pattern I am observing is that this can arise after an attempt to play a stream has failed, say because there was no video for the game in question. Is there something in the login logic which doesn't handle the failure case?

Ah yep, I just got another one. This time I just opened mlbviewer, started to download an archived nexdef stream, hit q to stop it, then repeated three times. Got the sign-on error on the fourth try. Is there still some authentication check that happens when the actual links are accessed?

This is r347 btw. Although I just realized that I didn't try deleting the cookie file though, I'll try that next time. But... I suspect I'll be able to reproduce the problem even if I do get rid of the old cookie file, given that something still seems to be noticing each time a link is accessed.

Again though, the fact that I can always just run mlbhls manually with the link from the log file is an excellent workaround.

daftcat · 03-26-2012, 07:20 PM

Quote:

Originally Posted by chrisVV

I have obtained another sign on restriction.

The pattern I am observing is that this can arise after an attempt to play a stream has failed, say because there was no video for the game in question. Is there something in the login logic which doesn't handle the failure case?

If the stream doesn't exist that has nothing to do with the login logic. Or rather, once you have logged in, that code is never touched again.

Having said that, when you make a request for a stream, you may receive different cookies/session key from the server (you shouldn't, but I suppose it could happen.) Whatever I receive, I replace what I have.

One question for the both of you: are you also logging in via the website? e.g. trying out the flash player when mlbviewer doesn't do what you want?

That might be confusing the servers. I admit this is baffling me because I have not encountered a single sign-on restriction error since I changed the login code. If I can't reproduce it, it's going to be very hard for me to fix it.

fang2415 · 03-26-2012, 07:37 PM

Quote:

Originally Posted by daftcat

If the stream doesn't exist that has nothing to do with the login logic. Or rather, once you have logged in, that code is never touched again.

Having said that, when you make a request for a stream, you may receive different cookies/session key from the server (you shouldn't, but I suppose it could happen.) Whatever I receive, I replace what I have.

One question for the both of you: are you also logging in via the website? e.g. trying out the flash player when mlbviewer doesn't do what you want?

That might be confusing the servers. I admit this is baffling me because I have not encountered a single sign-on restriction error since I changed the login code. If I can't reproduce it, it's going to be very hard for me to fix it.

I tend to login to the website once or twice per season.

So no, I don't think that's what's throwing it for a loop.

It is weird that you can't reproduce it though since I seem to be able to trigger it quite reliably. One thing that occurs to me is that I've mostly been trying to access the same stream several times, rather than several different streams? I can't see why the server would monitor multiple requests for the same stream and not requests for different streams though...

fang2415 · 03-26-2012, 08:30 PM

Just reproduced the sign-on restriction one more time. I removed .mlb/cookie (there was no sessionkey file in ~/ or in .mlb/). Then I opened mlbviewer, went to the listings for 3/25, started downloading the first fixed-rate nexdef video stream, waited until the file size went above 0, then hit q. Went to the next stream down and repeated, and so on. I think this time I got the sign-on error on the fifth stream down, trying a different stream each time.

Let me know if you want me to try something different next time and I'll report back (probably tomorrow). One thing that occurs to me is I can back up the cookie and session files after each stream to see they change at all...

daftcat · 03-26-2012, 08:33 PM

Quote:

Originally Posted by fang2415

I tend to login to the website once or twice per season.

So no, I don't think that's what's throwing it for a loop.

It is weird that you can't reproduce it though since I seem to be able to trigger it quite reliably. One thing that occurs to me is that I've mostly been trying to access the same stream several times, rather than several different streams? I can't see why the server would monitor multiple requests for the same stream and not requests for different streams though...

I just tried the same stream at least half a dozen times with no errors. Have you removed ~/.mlb/cookie and ~/.mlb/sessionkey since this patch and tried again?

metatroll · 03-26-2012, 09:17 PM

Hi Gurus

I am having trouble with mlbhls I am unable to get this to compile on cygwin. I have the latest version:

Code:

$ svn info
Path: .
Working Copy Root Path: /usr/src/mlbhls
URL: https://mlbtv-hls-nexdef.googlecode.com/svn/branches/experimental
Repository Root: https://mlbtv-hls-nexdef.googlecode.com/svn
Repository UUID: f259b058-16ce-0779-9161-39c490c157d4
Revision: 56
Node Kind: directory
Schedule: normal
Last Changed Author: thegryghost
Last Changed Rev: 55
Last Changed Date: 2012-03-21 17:46:29 +1100 (Wed, 21 Mar 2012)

when i run make in the mlbhls directory i get compile error:

Code:

$ make
gcc -O2 mlb.c utils.c output.c -lm -lcrypto -lpthread -lconfig -lcurl -o mlbhls
utils.c: In function ‘get_time_ms’:
utils.c:156:17: error: storage size of ‘tv’ isn’t known
Makefile:11: recipe for target `mlb' failed
make: *** [mlb] Error 1

I suspect this has some problem with some libraries not installed on my cygwin setup but I cant work out how to resolve this. I see in the mlbhls readme that the following packages are required: libcurl4-openssl-dev libconfig8-dev (ubuntu). I am pretty sure i have openssl all functioning as mlbviewer is working fine. Can anyone please point me in the direction to take?

Thanks

daftcat · 03-26-2012, 09:35 PM

Not sure if mlbhls will work under cygwin. I got it to compile by adding:

Code:

#include <sys/time.h>

after all the other #includes in utils.c

However, I'm getting an openssl error when I actually try to run it. Not feeling like looking into this right now.

rtmpdump/mplayer will work under cygwin though so you can watch basic service (up to 2400K this year) for now.

mlbhls is only necessary for nexdef mode.

thegryghost · 03-26-2012, 09:39 PM

Quote:

Originally Posted by metatroll

Hi Gurus

I am having trouble with mlbhls I am unable to get this to compile on cygwin. I have the latest version:

Code:

$ svn info
Path: .
Working Copy Root Path: /usr/src/mlbhls
URL: https://mlbtv-hls-nexdef.googlecode.com/svn/branches/experimental
Repository Root: https://mlbtv-hls-nexdef.googlecode.com/svn
Repository UUID: f259b058-16ce-0779-9161-39c490c157d4
Revision: 56
Node Kind: directory
Schedule: normal
Last Changed Author: thegryghost
Last Changed Rev: 55
Last Changed Date: 2012-03-21 17:46:29 +1100 (Wed, 21 Mar 2012)

when i run make in the mlbhls directory i get compile error:

Code:

$ make
gcc -O2 mlb.c utils.c output.c -lm -lcrypto -lpthread -lconfig -lcurl -o mlbhls
utils.c: In function ‘get_time_ms’:
utils.c:156:17: error: storage size of ‘tv’ isn’t known
Makefile:11: recipe for target `mlb' failed
make: *** [mlb] Error 1

I suspect this has some problem with some libraries not installed on my cygwin setup but I cant work out how to resolve this. I see in the mlbhls readme that the following packages are required: libcurl4-openssl-dev libconfig8-dev (ubuntu). I am pretty sure i have openssl all functioning as mlbviewer is working fine. Can anyone please point me in the direction to take?

Thanks

So it seems that cygwin can't find 'struct timeval'. In linux, you include <sys/time.h> which will include <bits/time.h>. I've updated SVN to implicitly include <sys/time.h>, see if this makes it compile. If not, search through cygwin's include directory and see where they define it, I can add a #ifdef to include it if it's somewhere else.