[Possibly OT] I saw that note about 1 May while watching a Dodgers game on the website recently. I sure hope it turns out I can watch via mlbviewer because the new viewer doesn't work on my system for some reason. I've been able to watch games in mlbviewer but didn't check what speed/version I was seeing. I'm looking hard at getting a monthly subscription now that my free subscription to MLB.TV has spoiled me for watching Dodgers games.

Just so you know this is my first post. I am a complete newbie (<--- or should that read Idiot ) to linux. Just dumped Windows for Ubuntu 14.04 LTS.

I followed the install instructions and for the most part it worked, as it will run. But I'm getting an error in the terminal window when trying to watch a game. The only way to see the error was to take a screen shot, as it rapidly scrolls in the window...

ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleMetadata, error decoding meta data packet

Also see this in the mix

A: 33.2 V: 33.2 A-V: 0.00

Any suggestions or help is greatly appreciated.
Thanks.

With the latest changes, after changing speed to 2500, I'm getting this:

Traceback (most recent call last):
File "/Users/tonyc/dev/mlbviewer/mlbviewer.py", line 1395, in <module>
curses.wrapper(mainloop, mycfg, mykeys)
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
File "/Users/tonyc/dev/mlbviewer/mlbviewer.py", line 200, in mainloop
mycfg.get('blackout'))
File "/Users/tonyc/dev/mlbviewer/MLBviewer/mlbSchedule.py", line 497, in getListings
return self.getXmlListings(myspeed, blackout)
File "/Users/tonyc/dev/mlbviewer/MLBviewer/mlbSchedule.py", line 632, in getXmlListings
for elem in listings]
KeyError: '2500'

You got stream. Be patient. How long did you give this?

Depending on the buffer size you selected in your mplayer command, it could take several seconds for the picture to appear. That could seem like an eternity when you are getting a wall of "ERROR" messages. Those are coming from mplayer which is why/how I can say you got the stream. The A: V: stuff is also from mplayer. Neither should be cause for concern alone.

1. Try waiting longer.
2. Try a different speed or stream (home vs away or another game)
3. If you still don't get picture, read the TOOLS file and create a small download using mlbgamedl.py or nexdefdl.py. When you have a downloaded file, you can isolate the video playback problem (as it would seem to be if stream is there but no picture) to the mplayer command or your driver setup and consult Google on "mplayer no video".

You got Linux up and running and my program and its dependencies installed correctly. That's more than most can say. You did get stream. You're almost there. You can do this.

1 members found this post helpful.

From this code location, it would seem this was in the listings code. Was this a splash and crash?

I don't see the error myself. Can you give me more details about what you did to get that error?

In the meantime, you can revert this change using "svn -r 658 revert" if this update isn't working at all for you.

I found a few more 2400's lurking throughout the code. (I thought I had isolated constants to MLBviewer/mlbConstants.py)

Try an svn up to 661.

I don't like the speed switching. Even in full screen mode it causes some flickering. To emulate speed locking I have set min_bps to 2400 and max_bps to 3000, and that will start at 500k and then about 20 seconds later switch directly to 2400K and stay there. Likewise setting min_bps to 1800 and max_bps to 2400 will cause it to start at 500k and then lock to 1800k, and so on with similar adjacent speed pairs. That seems a reasonably OK workaround.

If that isn't possible the work-around works OK for me.

Seems it was more than a two line change. Also, I had a lot of speed literals throughout the code so I consolidated them into mlbConstants.py like I thought I had already done.

This may be moot though. RTMP archive streams work from yesterday but I'm not able to play any live streams today. HLS (nexdef) still works with adaptive streaming.

C is not my strong suit.

Here's what I see in mlbhls/mlb.c

In the old files, e.g. prior to a few days ago, a (partial) master_wired.m3u8 looked like this:

and now they look like this:

So follow the HLS_BANDWIDTH_MARKER logic further in mlb.c, it looks like previously the marker was used to facilitate seeking in the playlist file as well as some memory size calculation (again, C is not my language) to store what's really important, "path" or the playlist location, e.g. 1800K/1800_complete.m3u8. The bw should be parsed correctly but none of that other line is needed and it's creating malformed curl requests when we try to lock to a speed.

To test, you can use this command to test old style:

and this command to test new style:


I'm thinking this would be a really easy fix for someone who actually knows C. I stumbled into Python by hacking a feature or two into someone else's mlbviewer.py code 8 years ago and I've been winging it ever since.

Okay, I'm pretty sure I know what's going on with mlbhls's streams. I haven't found a fix yet, but maybe somebody who reads this can translate the logic into a fix (or maybe I'll have time to figure it out later).

In short, it looks like mlbhls is getting confused by two things:

1) The new speeds (which seem to be real new speeds, not just garbage -- they're very similar to the old round numbers and they stay consistent from game to game). This can be fixed by simply giving mlbhls the correct number (using, for example, -s 1425340); and sometimes mlbhls seems to successfully default to the lowest speed anyway (this is the case for me with the Cubs feed from 3/31)

2) The new iframe lines in the master file. It looks like mlbhls first looks for a line with a bandwidth number in it and then builds a url using the line that comes next in the file. With the old files, that next line was always a filename (like "1200K/1200_complete-trimmed.m3u8"). Within the last week or so, those files started including extra lines beginning with "#EXT-X-I-FRAME-STREAM-INF:", which screw up mlbhls's sequential logic.

Using the adaptive streaming option gets around both of these problems since it causes mlbhls to simply switch between whatever stream urls it can parse correctly. But it's still missing the ones it can't read, so now the jumps are even more jarring than they were back when mlbhls could read every stream link.

Problem 1 looks like it might be fixable within mlbviewer -- we'd simply need to feed mlbhls different speed numbers. But problem 2 does seem like it'd need an mlbhls patch (unless someone can think of a better workaround?). If so then maybe now is the time to fork mlbhls so we can apply the necessary changes?

Incidentally, I also noticed that mlbviewer downloads the links to the master_wired_web.m3u8 files, while mlbplay downloads links to the master_wired.m3u8 files. These files sometimes contain different iframe lines, so the results of what mlbhls can download varies between the two methods.

I hope this is helpful and that somebody can use it to find an easy way to implement a fix!

...and my post overlapped daftcat's. But luckily you were looking at the code while I was looking at the debug output, so both are useful! That bandwidth marker is a promising clue -- hopefully we can use that to get to the section that manages this logic. I'll try to jump into the code soon if I have time. But yes, it would be even better if one of those actually-good-at-C people can see the best way to do this before then!

I am on revision 659 and the live SF v Oakland RTMP feed works for me.

Revision 662 also works on live streams for me.

OK, I see what you guys are talking about with the error parsing the m3u8. That should be an easy fix -- not sure I'll get to it over the weekend but I'll take a look ASAP.

It is kind of disappointing to see that the max bandwidth available on the web has dropped from 4500 to 3500 even as they're selling the notion of 60fps video on some devices. Part of me wants to get ahold of one of those devices and try to reverse engineer where they're pulling those higher-quality streams from.

I have put some instrumentation in mlbhls, and entry parsed by the 'do' loop in the function mlb_master_url_handler() with the old streams was in the form you mention, namely:

This would be repeated for each speed. All that the 'do' loop did was:

1. First find the marker "BANDWIDTH=", so identifying the first character in the line beginning with that marker (so here identifying the string "BANDWIDTH=1800000"), and then advancing to the beginning of the string "1800000" (bw += strlen(HLS_BANDWIDTH_MARKER)), which it would then pass as the third argument of the call to mlb_master_add_stream() via a call to atoi() (which just converts the string number to its integer value).

2. Secondly, extract the whole of the second line, comprising the path and name of the media file, which it would pass as the second argument of the call to mlb_master_add_stream().

The formatting of the new streams is different. The ones I have tested goes like this:
Note that the lines beginning #EXT-X-STREAM-INF: are still followed by a line giving a media file path, but they are interspersed, apparently randomly, by lines beginning #EXT-X-I-FRAME-STREAM-INF: which are not followed by a line giving a media file path (instead the URI is given in the same line), and which are probably the new high frame rate streams. To enable those lines to be identified more clearly I have inserted a blank line before and after them above which are not actually in the text which is streamed.

Adjusting the parsing in mlb_master_url_handler() to omit the lines beginning #EXT-X-I-FRAME-STREAM-INF:, and then extracting the bandwidth numbers 2121091, 559938, 985571, 1425340, 2908735, 4023049, and passing them with the respective media file paths to mlb_master_add_stream() brings up a stream, but unfortunately it is not the correct one. It always brings up the 450K stream. However, associating these bandwidth numbers with the actual bandwidth of the stream, by translating 2121091 to 1800000, 559938 to 450000, and so on in a switch table in mlb_master_url_handler() seems to work (it works for me with at 800k, 1200k, 1800k and 2500k which I have tested).

I will do some further testing and then clean up the code, and try and post a patch before first pitch today. If not, then tomorrow.

This also seems to show that the HLS stream speeds have changed: they are now 450K, 800K, 1200K, 1800K, 2500K and 3500K. That may require separate patches to mlbviewer (I do not know what the NEXDEF_SPEEDS variable actually does).

Attached is a patch which Works For Me (TM). Self-evidently it has not been tested against live streams, but I have tested it on yesterday's archive at 800K, 1200K, 1800K and 2500K. I have not yet tested at 3500K, and my internet connection might not be adequate to do so.

One thing I found is that the full audio stream selection (AKA "overlaying") now seem to be available on the low speed HLS streams as well as the lower speed streams.

Attached Files

mlb2016.txt (1.6 KB, 44 views)