I am also seeing this. Not as badly as that; but perhaps 2 out of 3 times the download fails without any error messages. It just doesn't happen. Since I can eventually get it going, this does not bother me too much.

I do see another issue that bothers me more.

I have a long standing problem that the rtmpdump download will fail halfway through the game perhaps half the time. I attribute this to either the mlb servers being heavily loaded or to my ISP throttling my bandwith by time slicing the download.

My workaround had been as follows:

1) I only watch archived games.
2) I grab the rtmpdump command from the log file, replace the - after the -o parameter with a filename, add a -e parameter to the command string, and submit the rtmpdump command from the command line.
3) It may take several iterations, but eventually I will have the game cached to my hard drive and I can enjoy the game without internet speed issues getting in the way.

This no longer works.

Yeah, I checked the XML but it didn't seem to contain any actual error message, I assume it was a glitch on MLB's side as it started working about 45 minutes into the game (and no, located in France, so not a blackout thing.)

On a sidenote, I've also been experiencing the issues with rtmpdump and the MLB.TV streams (it's hit-or-miss to get them started). Once they're started, they seem to work fine, but it can take up to 6-7 tries sometimes.

From my experience, you must very quickly start the rtmpdump command, if you wait longer than 10-15 seconds I'm assuming the auth token or something expires and you are unable to start the stream.

@thegryghost: I have made two sample clips from the game you mentioned.
-f 1:
https://dl.dropboxusercontent.com/u/.../testsmallf.ts
-F "20:32:04"
https://dl.dropboxusercontent.com/u/...05/testbigf.ts

The first one can be played by any player and seeking is working fine.
The second one I got working by using VLC or mplayer, yet seeking is horrible.

Your mplayer can seek through the second file perfectly (= playback continues at the right location under one second, showing the full picture with correct sound)?

Anyway, even if you say that everything is correct and the other video players are at fault, maybe you can add support for other video players as well? Or tell us how to configure our mplayer to work like yours? Thanks!

Downloading is not supported by daftcat, so you're pretty much on your own with that one, I guess.

For me, rtmpdump is automatically resuming after timing out. It still works now. My player command is the default one, piping to mplayer2. I can only assume that it works the same way when saving the stream? You could try piping to mplayer and using mplayer to save the stream. For me, rtmpdump has always resumed automatically...

Sometimes it can't reestablish a connection and then I have to restart the stream, but that rarely ever happens for me.

In the past, I have been able to get it going so long as the interval is less than several minutes. Now it will not work at all.

I am sure that you are right...but I can always hope.

For me, sometimes the connection can be reestablished, but since my ISP sometimes interrupts the d/l for as long as 40 seconds this does not happen all the time.

And yes, I know that this is poor behaviour for an ISP, but I live in a fairly rural community and I have to take what I can get.

I sometimes get rtmp streams cutting out as well, usually due to wifi signal disappearing temporarily (presumably because of all the interference in my urban community, lol).

Have you tried just using the jump-to-inning feature to resume? That way if you get cut off, worst case is you have to re-watch a couple outs, and if your connection is fast enough you may even be able to seek through that...

On downloading, it's not a feature of the MLB.TV service so I'm not interested in supporting it in mlbviewer. I consider it a grey area of the Terms of Service. It's not really supported especially with rtmpdump because rtmpdump, for an archived game, will attempt to stream faster than actual playback. Historically, this has always caused the stream to get interrupted at some point (like maybe 33% of the way through.) This could be a bug in rtmpdump, it could be a throttle from MLB.com, or who knows what. You could resume the stream, but it would take about three retries to get a full game. This has always seemed too hackish for me to ever want to either work around or try to support. So basically, you're on your own. That said, there are ways to manipulate the mplayer command-line to get mlbviewer to do the download without having to copy from the log file. Read the mplayer man page.

On rtmpdump command-lines, I might, no guarantees, be able to tweak the command-lines a bit further. I'm really stabbing in the dark based on what used to work and the few bits I have been able to figure out from wireshark. If I sit down and build a way to break down the URL returned from the media request combined with the components in the FMS cloud response into a language of % substitutions, that might help you guys to tweak the URLs. That would actually require me to spend some time trying to understand all the "baffling" bits of those URLs and what they really mean, or at least take a wild guess at what they mean, and pack them into chunks that you can arrange or rearrange.

Honestly, there's still enough "getting settled in" left to do at the new apartment before I can really dive into potentially large new chunks of code.

I find LinSSID to be an awesome tool for debugging wifi issues. If you're living in an apartment or in a tightly packed neighborhood where you can routinely see your neighbors' networks, it may pay to put some time into finding the right channel. Don't worry about avoiding overlapping channels. What you really want is a channel where your signal is significantly stronger than any of your neighbors' signals so that any neighbors you might be overlapping with can be filtered out as noise. Put another way, in a noisy cafe, you will filter out the conversation of your friend because the signal is that much louder than the background noise. Wifi hardware works much the same way. Loudest signal wins even with many overlapping "conversations" as long as there is a significant enough difference between your signal and the background noise of your neighbors' signals.

mplayer2 (git from 20130428): Both those samples play/seek perfectly. I can seek forwards and backwards using the up/down/left/right arrow keys and it's always in sync, instant, and with a perfect picture.

mplayer (v1.1):
- testsmallf.ts: plays/seeks without issue
- testbigf.ts: only plays when I specify "-demuxer lavf", seeking results in a incomplete picture for 1-2 seconds before going back to normal


vlc (2.0.6): Both play/seek. Seeking isn't as good as it is with mplayer2, I can select a position with the scrubber and I'll hear audio about 2-3 seconds before the video syncs up. But I can seek/jump within both of those files without any problems.

The only thing I can think of is upgrading ffmpeg, this would probably fix most of the issues that everyone is having with seeking. Not quite sure how to do it on your distro since vlc and mplayer comes with a version of ffmpeg bundled in. I use gentoo in where vlc and mplayer2 are forced to build using the system-wide ffmpeg.

thegryghost, do you have any idea why -f and -F would yield different streams? I've had a look through what looks like the bit of the code that parses the -F option, and it looks like it just finds a nearby line to start the download, so I can't understand why the stream would be any different to what -f at the same line grabs.

I don't think I've found the code that handles -f yet; is it possible that one of them throws in some extra output somehow?

Well, I'm stumped for now. I did notice that -f being set triggers an extra loop which checks the start position against the IV count, but I'm not sure what that is or how it would change the output; the only other thing I can see that -f does is to set the stream position. It still seems to me that streams grabbed with those two options should be identical, but obviously based on how they make the players behave, they're not. Strange.

I had quick try of mplayer(1) with the -demuxer lavf option and it did look promising, although the seeking seemed a little awkward; I'll try to do some further tests tomorrow.

fang2415:
I have used it occasionally. I guess that is what I will have to do.

daftcat:

I understand and agree with your reasons not to support downloading. I did not really expect that you would want to invest any time in this problem; but I did want you to be aware of the changed behavior. I am only using the program in the way that I do because the poor quality of my internet connection makes live streaming a poor quality experience.

Regardless of this, I thank you for all the work that you have done on this product.

The only thing I can think of is that -F might be 1 segment before or after the actual segment. But the -F code only sets the variable that -f uses, so I don't know why it would be different.

So just for reference, it looks like seeking still isn't working properly for me using mplayer -demuxer=lavf with a -F stream. Initially I get the incomplete picture behavior described above, but after a few minutes of watching, subsequent seeks always set the video to one point early in the stream. So this may not be a solution for mplayer(1) users yet (unless I'm missing something!).

Mind you, I'm happy to keep using the -f hacks above, but when I have a chance I'll try to have another bash at pinning down why -f and -F yield different streams even when starting at the same line number...

I've been getting this quite a bit lately, on TOR/NYY, I am in France, not a blackout area, the NYY feed results in this error (TOR works):