Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Have they fixed the problem with the streams having way too much "This Game Will Start Shortly" at the beginning of the stream ? (e.g. the reason why -F was created in the first place?) Also, this doesn't fix the jump to innings issue. I can implement a short-term config file option to use this until we can get the real issue sorted. Look for a patch tonight/tomorrow morning.
It looks like the HLS playlist files and the innings.xml are now all in GMT. Using the Orioles at Rays for testing (content id: 25902727, event-id: 14-346754-2013-04-02):
The HLS playlist starts at 2013-04-02T18:10:55+00:00.
I don't understand C well enough to create the patch myself, but it looks like mlbhls is inserting a GMT offset on top of the -F timecode already given. That or it is doing an extra conversion or something. For me, localtime is PDT or GMT-7. EDT is GMT-4. For yesterday's BOS@NYY game, I am expecting an EDT start time of 13:01:07 but the innings file shows 17:01:07. A four hour difference which would suggest that inning times are now in GMT (EDT+4 hours = GMT.) On top of that, when I request 17:01:07 using mlbhls -F, I see it requesting 21/01/07.ts (an additional four hours!) This is why archived nexdef streams jump to the end of the game. What's really odd is that when I try to adjust this manually to request 13:01:07, I also see the stream starting from 21/01/07.ts.
I can add a temporary option to revert back to -f 1 which will at least get archived games starting from the beginning. But this does not fix jump to innings. I will contact thegryghost to see if we can get a fix in mlbhls. If someone who knows C wants to take a look at it, I wouldn't mind testing a private patch before we ask for an official one.
[snip]
Somewhat discouragingly, I was able to download nexdefinstall.dmg and get the nexdef stream to play through the browser using the old java -jar nexdef.jar trick. They may have intended to change the stream times to GMT. I will have to look further into this another time.
Out of interest, did you download v2011_125 or have you got an updated URL? A new version, v2013_129 came out a day or two ago and I have yet to find the URL for a download of the jar file (it is not in the equivalent location to the 2011/12 one), and I don't have a Mac to help me on my way. The old one still seems to work though. Let's hope it won't be needed for long!
It looks like the HLS playlist files and the innings.xml are now all in GMT. Using the Orioles at Rays for testing (content id: 25902727, event-id: 14-346754-2013-04-02):
The HLS playlist starts at 2013-04-02T18:10:55+00:00.
You should be able to pass the SCAST number to mlbhls and it'll start at the proper time. The following started me at the top of the 2nd:
Code:
mlbhls -B <b64_url> -F 19:32:38 -o tmp
You may need to keep everything in GMT and only convert to local when the it's displayed in the UI.
I tried this and it seems to work correctly with in progress games. But using yesterday's NYY-BOS game as an example, whether using a start time of 17:01:07 or even trying to account for a mysterious 4 hour jump, using 13:01:07, I am still seeing the Get's starting at 21/11/01.ts. Interesting. I would expect, if it was a time conversion problem, to see the stream start at 21/01/06.ts. What's so special about 21/11/01? It is after the last #EXT-X-KEY: entry in the file. Were the previous key's ignored or rejected? or somehow unintentionally skipped over?
I tried this and it seems to work correctly with in progress games. But using yesterday's NYY-BOS game as an example, whether using a start time of 17:01:07 or even trying to account for a mysterious 4 hour jump, using 13:01:07, I am still seeing the Get's starting at 21/11/01.ts. Interesting. I would expect, if it was a time conversion problem, to see the stream start at 21/01/06.ts. What's so special about 21/11/01? It is after the last #EXT-X-KEY: entry in the file. Were the previous key's ignored or rejected? or somehow unintentionally skipped over?
This looks like it's a bug in mlbhls. I'll take a look at it and get it fixed ASAP.
Out of interest, did you download v2011_125 or have you got an updated URL? A new version, v2013_129 came out a day or two ago and I have yet to find the URL for a download of the jar file (it is not in the equivalent location to the 2011/12 one), and I don't have a Mac to help me on my way. The old one still seems to work though. Let's hope it won't be needed for long!
I reverse engineered the download url from the hover over the popup link. The popup link itself did not work. I kind of got lucky that when you remove the popup.html bit and add nexdefinstall.dmg, I was able to wget it. Then I had to follow some archived thread on ubuntuforums to remind myself how to unpack the dmg and find the jar. Hint: it's no longer Resources.pax.gz nor autobahn.jar but there is a nexdef.tar which contains a nexdef.jar. I want to get this fixed more than I want to support this hack which is why I'm not giving a detailed howto.
I tried this and it seems to work correctly with in progress games. But using yesterday's NYY-BOS game as an example, whether using a start time of 17:01:07 or even trying to account for a mysterious 4 hour jump, using 13:01:07, I am still seeing the Get's starting at 21/11/01.ts. Interesting. I would expect, if it was a time conversion problem, to see the stream start at 21/01/06.ts. What's so special about 21/11/01? It is after the last #EXT-X-KEY: entry in the file. Were the previous key's ignored or rejected? or somehow unintentionally skipped over?
Ok, this is now fixed in rev 62 of mlbhls experimental. The problem was lazy/sloppy coding on my part. I always assumed that the "#EXT-X-PROGRAM-DATE-TIME" marker would also be on a certain line in the playlist file, it's not. I just tested with the Red Sox at Yankees game from yesterday and it works.
I reverse engineered the download url from the hover over the popup link. The popup link itself did not work. I kind of got lucky that when you remove the popup.html bit and add nexdefinstall.dmg, I was able to wget it. Then I had to follow some archived thread on ubuntuforums to remind myself how to unpack the dmg and find the jar. Hint: it's no longer Resources.pax.gz nor autobahn.jar but there is a nexdef.tar which contains a nexdef.jar. I want to get this fixed more than I want to support this hack which is why I'm not giving a detailed howto.
Ah, there's a change of name. The thing which fooled me is that the 2012 nexdef.jar was in a HFS+ filesystem comprised in v2011_125/mlbnexdefinstall.dmg, whereas the 2013 version is in v2013_129/nexdefinstall.dmg.
I much prefer mlbhls. I get proper video acceleration with mplayer rather than the rubbish flashplayer attempt at it (4 to 5% CPU as opposed to 50% CPU). And the game interface is much, much more convenient.
Ok, this is now fixed in rev 62 of mlbhls experimental. The problem was lazy/sloppy coding on my part. I always assumed that the "#EXT-X-PROGRAM-DATE-TIME" marker would also be on a certain line in the playlist file, it's not. I just tested with the Red Sox at Yankees game from yesterday and it works.
Let me know if you have any other problems.
Jump to innings works correctly. Start of game is same buggy behavior.
Using yesterday's BOS-NYY game, requesting the published start time of 17:01:07 or the start ts in the m3u8 of 17:01:06 does results in 21/01/01. However, requesting a start time of 17:01:11 (the next ts in the file) works as expected. Stream Get's start from 17/0/06.
Is it possible that the fix is unintentionally off by one line missing the first ts in the file? If I request a start after that first ts, why does the stream pick up that first ts anyway? (not a big deal really except to help narrow down why start of game is not working correctly)
Yes, the change is in rev 62 (just tested). Can you send me your full URL except for the base64? This works for me...
Code:
./mlbhls -B aHR...RA== -F 17:19:26 -o tmp
[MLB] Reading cfg file: mlb.cfg
[MLB] Output file: tmp
[MLB] Segment Avg. Count: 3
[MLB] Max Bandwidth: 0 (bps)
[MLB] Min Bandwidth: 0 (bps)
[MLB] Bandwidth Locking: 0
[MLB] Fetching Master URL: http://mlblive-akc.mlb.com/ls04/mlbam/2013/04/01/MLB_GAME_VIDEO_BOSNYA_HOME_20130401/master_wired.m3u8
[MLB] Current Priority: 1 (bw: 128000)
[MLB] Master URL: http://mlblive-akc.mlb.com/ls04/mlbam/2013/04/01/MLB_GAME_VIDEO_BOSNYA_HOME_20130401/master_wired.m3u8
[MLB] Base URL: http://mlblive-akc.mlb.com/ls04/mlbam/2013/04/01/MLB_GAME_VIDEO_BOSNYA_HOME_20130401/
[MLB] Decryption Key:
[MLB] Params: playback=HTTP_CLOUD_WIRED&contentId=25901969&appAccountName=mlb&eventId=14-346755-2013-04-01&ipid=...&sessionKey=...%3D
[MLB] Stream #0 - rate: 800000 - path: [800K/] - playlist: 800K/800_complete-trimmed.m3u8
[MLB] Stream #1 - rate: 128000 - path: [200K/] - playlist: 200K/200_complete-trimmed.m3u8
[MLB] Stream #2 - rate: 500000 - path: [500K/] - playlist: 500K/500_complete-trimmed.m3u8
[MLB] Stream #3 - rate: 1200000 - path: [1200K/] - playlist: 1200K/1200_complete-trimmed.m3u8
[MLB] Stream #4 - rate: 1800000 - path: [1800K/] - playlist: 1800K/1800_complete-trimmed.m3u8
[MLB] Stream #5 - rate: 2400000 - path: [2400K/] - playlist: 2400K/2400_complete-trimmed.m3u8
[MLB] Stream #6 - rate: 3000000 - path: [3000K/] - playlist: 3000K/3000_complete-trimmed.m3u8
[MLB] Stream #7 - rate: 4500000 - path: [4500K/] - playlist: 4500K/4500_complete-trimmed.m3u8
[MLB] Playlist refresh time: 12 (s)
[MLB] Playlist start: 61265
[MLB] END OF PLAYLIST! (rate: 800000)
[MLB] Setting stream start time to (epoch): 1364853665
[MLB] END OF PLAYLIST! (rate: 128000)
[MLB] END OF PLAYLIST! (rate: 500000)
[MLB] END OF PLAYLIST! (rate: 1200000)
[MLB] END OF PLAYLIST! (rate: 1800000)
[MLB] END OF PLAYLIST! (rate: 2400000)
[MLB] END OF PLAYLIST! (rate: 3000000)
[MLB] END OF PLAYLIST! (rate: 4500000)
[MLB] Get (466): 17/19/22.ts (bw: 128000, time: 0.11s) [Avg. D/L Rate of last 3 chunks: 8.81 Mbps]
[MLB] Get (468): 17/19/27.ts (bw: 128000, time: 0.10s) [Avg. D/L Rate of last 3 chunks: 8.44 Mbps]
The epoch time doesn't do anything, just for (useless) information.
I updated my comment. Jump to inning now works great. Jump to start of game using -F 17:01:07 does not work. Jump to start of game plus one timestamp, e.g. -F 17:01:11 starts the stream from 17:01:06. Looks like there may be an off-by-one line error?
Since it is only start of game that is now affected, I could change my getStartOfGame routine to add 5s, but I'd rather have it correct in mlbhls.
I updated my comment. Jump to inning now works great. Jump to start of game using -F 17:01:07 does not work. Jump to start of game plus one timestamp, e.g. -F 17:01:11 starts the stream from 17:01:06. Looks like there may be an off-by-one line error?
Since it is only start of game that is now affected, I could change my getStartOfGame routine to add 5s, but I'd rather have it correct in mlbhls.
Short version:
I've found the issue and it's fixed in rev 63.
Long Version:
The problem here is that the HLS playlist defines the start as:
#EXT-X-PROGRAM-DATE-TIME:2013-04-01T17:01:05+00:00
or
17:01:05
To figure out where to start in the HLS playlist with -F, I subtract the time that's specified with -F with the actual start time in the HLS playlist and divide by the segment time. Specifying a start of 17:01:07 is only a 2 second difference, the segment time is 5 seconds. When doing int division, the start time is effectively 0. Which tells mlbhls to start from the end. That explains why when you add 5 seconds, it works. Since the division is no longer zero. "Live" HLS playlists start at least 30 mins before, so the difference is much bigger but the archives appeared to be "trimmed" to remove all that.
I now check to see if the difference is less than the segment time and if it is, just set it to 1.
Please test and let me know if anything else is still broken.
Short version:
I've found the issue and it's fixed in rev 63.
Long Version:
The problem here is that the HLS playlist defines the start as:
#EXT-X-PROGRAM-DATE-TIME:2013-04-01T17:01:05+00:00
or
17:01:05
To figure out where to start in the HLS playlist with -F, I subtract the time that's specified with -F with the actual start time in the HLS playlist and divide by the segment time. Specifying a start of 17:01:07 is only a 2 second difference, the segment time is 5 seconds. When doing int division, the start time is effectively 0. Which tells mlbhls to start from the end. That explains why when you add 5 seconds, it works. Since the division is no longer zero. "Live" HLS playlists start at least 30 mins before, so the difference is much bigger but the archives appeared to be "trimmed" to remove all that.
I now check to see if the difference is less than the segment time and if it is, just set it to 1.
Please test and let me know if anything else is still broken.
Thanks for the awesome support!
Bos@NYY and Mia@Was yesterday work from start with 63.
Now to a game I actually care about. KC@Cws still seems to be affected.
X-PROGRAM-DATE-TIME is 2013-04-01T20:00:06+00:00 and innings start_time is 20:00:06. So the date-time minus the -F is 0. Since that's less than 5 seconds, that gets set to 1. Correct? The first timestamp in the file is 20/00/07. This seems like it should be a perfect match to your algorithm. But instead it starts playing from the end (a 23/../...ts something timestamp.) I realize my "fix" for getStartOfGame would not be so easy as I will need to convert the string to a time structure before adding the five seconds to make sure a published start time of hh:mm:56 does not become a nonsense value of hh:mm:61. Still something I might do, but just not right now.
I am guessing that your coverage setting is wrong. At least that is how I am able to reproduce that exact error. I either get different errors or no errors at all for invalid or absent values of speed and adaptive_stream.
coverage= should be either home or away, e.g.
Thanks! I was missing the coverage setting in my config file.
Thanks! I was missing the coverage setting in my config file.
Weird. Default config file writes a coverage= setting. I suppose you could have removed it. Not sure how to defend against that in the code. Maybe in the loads() routine, I can do a check of mandatory parameters? I'll have to think that one over to see how to fix it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
KC@Cws still seems to be affected. 
