[WIP] MLB.TV Boxee App port (developers needed!)

thegryghost Wrote:Sure.

Patch for mplayer Here.

Patch for mplayer2 Here.

I use mplayer2 since it properly handles seeking the mlb.tv mpegts better than regular mplayer. My cmd line is:

mplayer2 -really-quiet -livepause 5 -demuxer lavf -mc 2 <mlb.ts>

the "livepause" option will enable file growing support, along with the ability to pause/rew/ffwd without seeking past the end (DVR capabilities). The number after livepause is the number of seconds to be behind "real-time". So when I fast forward and reach "live", it'll always be 5 seconds (roughly) behind.

The mplayer2 patch will also pause and wait for the file to grow (throwing up a "Buffering..." msg) instead of exiting.

Perfect, thanks. I'll play around with it and see what happens.

I've had a little success with this default.py - http://ubuntuone.com/p/12zl/ but very little testing. I was able to watch the last 30 min or so of the free game, didn't have any issues other than it buffering a couple of times.

This creates a dir in /temp and writes to a fifo file.

I'll give it a whirl.

I think I figured out what my problem was. I forgot that downloading segments via HTTP and stitching them together does not necessarily build the stream in real time. I was assuming that if I let the "recording" get 60 seconds ahead, there would always be a ~60-second buffer. Not so. I was able to smooth things out by grabbing the 3000k stream instead. This is why the stream-switching ability becomes important.

And BTW, the patched mplayer2 worked well for keeping the stream alive. That said, seeking seemed completely broken. No matter where I was in the stream, seeking back always took me to the exact same frame, about a minute or two into the stream. Seeking forward took me to another frame, shortly after that. So after watching about an hour, I paused it. When I came back, I tried to fast-forward over the commercial break, but seeking ahead caused me to jump all the way back to that frame near the beginning. I even quit and restarted mplayer with the -ss 00:57:00 flag, but it still wouldn't seek past that one frame a little over a minute in.

KennethC Wrote:It's working for me, mostly...

I can navigate around the plugin fine, but as soon as I selected a game (either yesterday's or today's), it hangs for about 2-3 minutes before it brings up the available home or away feeds.

The debug log doesn't show too much... the delay occurred between 16:03:11 and 16:05:52 below:

http://pastebin.com/sgDFidaF

Another pastebin... delay is between: 16:09:08 and 16:12:14

http://pastebin.com/1kLGJ8Xc

This is still occurring for me, but I have some other info now...

I have a Windows 7 HTPC (Acer RevoAspire 3700 - 3GB RAM, Windows 7) that takes anywhere from 1 to 5 minutes to gather the feeds for a particular game. There really isn't anything special with this PC. It's got an Atom CPU, so it's not a big performer. It's got a very base Windows install with few applications. It's primary role is for XBMC.

With another PC, I have a very powerful Windows 7 desktop PC upstairs that has 6GB of RAM, 8 cores (I believe it's an Intel i7 930, slightly overclocked). The game feeds take about 1 second to be fetched.

Can someone explain what happens exactly (pointing to the routine in the code might help) when I select a particular game to fetch the feeds until the feeds are presented via the plug-in? It seems like it could be a resource issue.

theophile Wrote:And BTW, the patched mplayer2 worked well for keeping the stream alive. That said, seeking seemed completely broken. No matter where I was in the stream, seeking back always took me to the exact same frame, about a minute or two into the stream. Seeking forward took me to another frame, shortly after that. So after watching about an hour, I paused it. When I came back, I tried to fast-forward over the commercial break, but seeking ahead caused me to jump all the way back to that frame near the beginning. I even quit and restarted mplayer with the -ss 00:57:00 flag, but it still wouldn't seek past that one frame a little over a minute in.

Hmm, can you try with:

-livepause 5 -demuxer lavf -mc 2

And see if it seeks? I get the behavior you described when I'm trying to seek with regular mplayer. Using mplayer2 lets me seek in 7 second intervals (forwards and back) no matter how much I tell it to seek.

thegryghost Wrote:Hmm, can you try with:

-livepause 5 -demuxer lavf -mc 2

And see if it seeks? I get the behavior you described when I'm trying to seek with regular mplayer. Using mplayer2 lets me seek in 7 second intervals (forwards and back) no matter how much I tell it to seek.

I *think* I did that. I copied your mplayer2 line verbatim out of the mlb.cfg file included with the player. That said, the mplayer2 patch didn't apply entirely cleanly. The first couple of hunks failed, but the rest succeeded. Could be because I grabbed the source from git rather than using a tarball. Should I try again with the source tarball? Or is there a convenient way to determine after the fact what actually happened when I applied the patch?

theophile Wrote:I *think* I did that. I copied your mplayer2 line verbatim out of the mlb.cfg file included with the player. That said, the mplayer2 patch didn't apply entirely cleanly. The first couple of hunks failed, but the rest succeeded. Could be because I grabbed the source from git rather than using a tarball. Should I try again with the source tarball? Or is there a convenient way to determine after the fact what actually happened when I applied the patch?

Ah, I use the "release" tarball to make the patch from. Try that and see if applies cleanly and if seeking works properly. If there's some feature or fix that's in git but not the source release, I can easily update the patch.

KennethC Wrote:This is still occurring for me, but I have some other info now...

I have a Windows 7 HTPC (Acer RevoAspire 3700 - 3GB RAM, Windows 7) that takes anywhere from 1 to 5 minutes to gather the feeds for a particular game. There really isn't anything special with this PC. It's got an Atom CPU, so it's not a big performer. It's got a very base Windows install with few applications. It's primary role is for XBMC.

With another PC, I have a very powerful Windows 7 desktop PC upstairs that has 6GB of RAM, 8 cores (I believe it's an Intel i7 930, slightly overclocked). The game feeds take about 1 second to be fetched.

Can someone explain what happens exactly (pointing to the routine in the code might help) when I select a particular game to fetch the feeds until the feeds are presented via the plug-in? It seems like it could be a resource issue.

This happens to me also. I think this is some sort of xbmc's old python, windows and https issue The good news is, I tried with a nightly that has the new python and it seemed pretty quick. If you want, try a nightly (eden-pre) version of xbmc and install this - http://divingmules-repo.googlecode.com/f...en-pre.zip

After calling MLB and getting my IP un-blacked-out I was able to watch the Diamondbacks @ Brewers without any issues. Seeking was a no-go but I was able to pause without issue. Around mid-game there was buffering several times but that seemed to clear up and the player never once stopped.

divingmule Wrote:After calling MLB and getting my IP un-blacked-out I was able to watch the Diamondbacks @ Brewers without any issues. Seeking was a no-go but I was able to pause without issue. Around mid-game there was buffering several times but that seemed to clear up and the player never once stopped.

Using the fifo?