Well.. the good news is, after beating my head against my keyboard for almost 2 hours I finally got the mlbhls to work, right after I finally figured out that the link for it IS NOT in the README file, but rather INSTALL file, and that it is, in fact, NOT THE RIGHT ONE EITHER!! Apparently you need the experimental version, not the trunk version, or you get a -F error when you try to use mlbhls.

Now I can watch my game again, but it is not so seakable. I tried to skip ahead and ended up at the beginning of the game. I miss rtmp working already.

-the geeky girl
Kermi

Ah, yes, there is that little quirk. I usually have to search this thread for "googlecode" in order to find the correct URL whenever I install a new mlbhls...

I think this is an mlbhls bug that I've been meaning to raise with thegryghost but haven't gotten around to it. I find that I can work around it by getting the 64-bit link from the mlbviewer log and then running mlbhls manually using the old -f option instead of -F.

So I go into mlbviewer, select the mlbhls version of the game I want, then quit when the stream starts. Then I do:

I can watch these streams with any player (vlc, mplayer, or mplayer2) and seeking in mplayer and vlc works fine.

(BTW, the reason I'm fairly sure it's an mlbhls bug is that the problem can also be fixed by taking a fragment of a stream downloaded using -f and then using cat to glue a stream downloaded using -F onto the end of it. That plays fine, even if the "starter" fragment is <1M. That suggests to me that -F is writing something screwy into the file header that only mplayer2 can figure out, but with seeking broken.)

HTH. Also, as daftcat has pointed out to me numerous times in the past, the skip-to-innings feature (hit "i" at the listings page) makes life without seeking much more bearable!

*happy exhale*

It's SEEKABLE!! Eureaka! Now I need to figure out how to write a script to do this for me so I can just run a script to make yesterday's game happen.

I think I might have to wait for that, as my brain still hurts from getting mlbhls working right. (Seriously, I have a migraine.)

-Kermi

Can you please post a link to one of those google results you were reading about? It may be less baffling for me.

I believe you are looking for:

That will give you that nexdef base64 string that starts with aHR0 without having to look for it in the log file.

You can use j= parameter to jump to a specific date. i= to jump to a specific inning. The keys mostly mimic the same keys used in mlbviewer and you can get more information in the MLBPLAY readme.

The difference between the -f and -F is that -f was a line number offset in the time codes where each line was roughly 6 s of video. It was a best guess at where the stream playback should start. Often this guess would be wrong with as much as 30 minutes of "This Game Will Begin Shortly" splash screen before you would actually get to the head of the broadcast. -F takes the published start time in one of the XML responses and skips directly to that time code.

I am not sure why the -f streams are seekable and the -F ones are not. This is a question for thegryghost (mlbhls developer.)

URL errors for where to get mlbhls *experimental* code will be fixed in the README/INSTALL. Sorry about that.

1 members found this post helpful.

BTW, I was having the worst time with mlbhls streams until I realized the adaptive streaming part was messing up my version of mplayer2. If you get messages about changing height/width not supported and your stream video stops while the audio keeps going, you can either build a new mplayer2 from source taking the latest Libav from git (instructions in the mplayer2 build guide), or you can turn off adaptive streaming with adaptive_stream=0. Turns out my new internet is much quicker than internet at the old place (new modem and less neighbors) so adaptive streaming really isn't necessary for me anymore.

Well, I guess the seekable mlbhls stream is a workaround for now. Still, working rtmp streams would be awesome . Thanks for the great work (to the other guys here as well).

Thank you TONS, Daftcat! I was able to easily re-write my "yesterday" script with your clues! Now I'm as happy as any Cleveland Indians fan actually can be.

Sorry if I sounded crabby about the miss information previously. I honestly did have a migraine!

-The geeky Girl
Kermi

If there was a "Like" button for LinuxQuestions...

Sure, although I don't think they offer much detail...

Here's the search I did:
https://www.google.co.uk/search?q=ER...equested+close

And here's the links I followed:
http://stream-recorder.com/forum/err...p-t16466.html?
https://github.com/aajanki/yle-dl/issues/13
http://mplayerhq.hu/pipermail/rtmpdu...ay/001434.html
http://forum.xbmc.org/showthread.php?tid=149717

Ooh, that is handy. I knew there'd probably be a way to do that, but I've been too lazy to do the work to find the right options so that I can do less work by using them.

Just to note, if you are adding stuff to the docs, I don't think the innings feature or the nu option are in the current MLBPLAY-HELP (or maybe anywhere), so it might be good to chuck 'em in there to alleviate the need to hunt through the thread...

I think MLBAM have recently cleaned up the video streams to get rid of the long "This game will begin shortly"s. I used to have to do like -f40, but this year I've used -f1 every time and never gotten more than a few seconds of blue screen.

The other big advantage to the -f streams is that they currently work with any player, so there's no need to force users to get mplayer2.

For archived RTMP, there were a lot of the "baffling" bits missing from the rtmpdump command-line because my regular expressions weren't working like they should. I managed to get archived working but now live isn't quite right. It's a lot harder to debug this remotely through an ssh session and I would kind of like to do it correctly than patchwork things together too quickly. I will spend some more time on this over the weekend. As this is a major restoration of core functionality, I want to get it right and clean because I'll have to update Sourceforge release.

So, for now, you can use test/mlbgame.py to access archived RTMP streams which is working. It's working because it is using quick and dirty code that is different (and in this case, a good kind of different) from the core code in MLBviewer.

For example, let's take the first game of the KC-DET doubleheader today (seeing as doubleheaders will give you the most challenge with mlbplay.py and/or test/mlbgame.py). I want to watch the KC broadcast of the first game, so let's get media debug ('z' key) from mlbplay.py:

We can see there are two games (two different event-id's: 14-347039-2013-08-16 and 14-348559-2013-08-16) and preferred media is messing up by selecting the second game. How do I know this?

Event-id for the first game is 14-347039-2013-08-16 so prefer media should be ('FSD-HD', u'116', '29502373', '14-347039-2013-08-16').

No biggie. We already know mlbplay.py isn't going to work until I check in my fixes so we're just interested in getting the content-id (29502373, the third field) and the event-id (14-347039-2013-08-16, the fourth field.)

So the final command to watch the RTMP stream for the KC broadcast of the first game of the doubleheader:

Which incidentally may not work correctly with live games right now but I expect most of you won't see this example until this game is archived anyway.

-----

The '-f' vs. '-F' mlbhls debate:

Not sure I was so adamant about -F other than I think it's absolutely fantastic to start the stream from the real beginning of the stream rather than the guesswork involved with "-f".

However, if "-f 1" is working reliably now at getting the head of the broadcast rather than a half hour of blue screen, I'll add in a config file option to let you guys choose "-f".

----

Mouse support broke copy-paste. Honestly, I really only need mouse support for one machine, and it's kind of getting in the way everywhere else. I will check in a fix to disable mouse support by default.

If you want to disable it right now, change line 89 from:

to

You must preserve original indentation for if statement, and insert 4 more spaces before curses.mousemask(1) to be syntactically correct for Python. This means that if you want to re-enable mouse support, you can add enable_mouse=1 to your config.

---

Documentation

Yep. It needs a lot of updating.

Thanks for trying to fix the RTMP streams! Great that you already know what it is :-).

Ugh! Bugs suck! Looks like I have listings issues with the KC-DET doubleheader showing the second game currently In Progress as Final - Condensed Game Available.

If you're trying to watch it or encounter something similar, just use the jump to innings feature.

Also, back to -f vs -F, I don't believe jump to innings can be supported with -f.

daftcat, that sounds great on the rtmp front, glad you could identify what was going wrong.

As for -f vs -F, I completely agree that -F would be far better if it worked properly, and that innings support won't work without it.

As I mentioned, there is a workaround that can get inning support for -f-header'd streams, but boy is it a hack:

Start a stream with -f and save it to fvid.ts, then cut it off shortly after the stream gets rolling.

Then do this:
(5830 bytes seems to be the minimum that I can get to work.)

Then set the mlbviewer player line to something like this:
That should yield a stream that a stock mplayer installation should be able to play and seek through at least as much as the cache allows. (Of course, there might also be unsupported functionality that might save the stream to disk and make it 100% seekable...)

As I say, it's mighty ugly, but that's how I use the innings feature with a stock version of mplayer.

Maybe I'll send thegryghost an email to see if he can advise on a proper fix for mlbhls -F...