[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.
|
Questions
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' |
Quote:
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. |
Quote:
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. |
Quote:
Quote:
|
SVN revision 662: More complete implementation of 2500K RTMP
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. |
Quote:
Here's what I see in mlbhls/mlb.c Code:
#define HLS_BANDWIDTH_MARKER "BANDWIDTH=" Quote:
Quote:
To test, you can use this command to test old style: Code:
mlbhls -d -B $(./mlbplay.py nu=1 n=1 v=stl j=03/25/16) -o /dev/null Code:
mlbhls -B $(./mlbplay.py nu=1 n=1 v=tex j=04/02/16) -d -o /dev/null 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! :D
|
Quote:
|
Quote:
|
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. |
Quote:
Quote:
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: Quote:
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). |
1 Attachment(s)
Quote:
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. |
All times are GMT -5. The time now is 05:22 PM. |