[avens19]

I can confirm that running an external webserver works great!

[juggie]

I can confirm that running an external webserver works great!

What?

[avens19]

Apparently I didn't test for long enough. This definitely looks like a file locking issue. What I did was set up a Mongoose server pointing to the m3u8 directory. It works only for the first 10 seconds but then breaks.

EDIT: Debug log: http://pastebin.com/b2dff54S

[juggie]

What exactly needs to change in the m3u8 file once its downloaded?

[avens19]

The m3u8 file is continuously updated with the URL's to the 10 second segments of video

[juggie]

The m3u8 file is continuously updated with the URL's to the 10 second segments of video

Yes I know that, but I think Carb0 is intentionally rewriting it and pointing at a local .key file or something?

[avens19]

The whole point of this is that normally, the m3u8 file comes down from the server with a link to the key file (also on the server) inside. XBMC tries to retrieve that key file but instead of using the custom User-Agent specified in the m3u8 request, it uses the default XBMC UA. neulion rejects the request from that UA. So what carb0 did was create (and update) the m3u8 as a local file so that he could embed the key file link as a link to a local file which he got by using his own request with a custom UA. But now XBMC is trying to read the file during playback while it is being updated and so it breaks XBMC.

[juggie]

Right.

Solution 1: Write file as .tmp then mv .tmp on top of old file. This will work on linux, not sure about windows.

Solution 2: Use http proxy (eg built into python), when .m3u8 file is requested, modify the url to be proxy running on python, when key is requested it will be against python proxy which will then connect to neulion with proper user agent and return it.

Solution 3: Fix xbmc

[Hyperium]

Ok, wait a minute. Carb0 is not downloading the .m3u8 file every 10 seconds. The .ts files are predictable therefore he creates only ONE file. He just fills the entire file full of what it already expects. Check out the newest GCL and as soon as it asks for the home or away feed, go to your plugin.video.GCL etc.. and check for yourself. Look in the home.m3u8 file and you'll see what I mean.

Edit: I see now, this is super easy. You can download this mongoose server temporarily, until carb0 adds a HTTP server through XBMC. What you do is just add your folder path to the document_root path in mongoose ( C:\Users\Hyperium\AppData\Roaming\XBMC\addons\plugin.video.nhl-gamecenter\m3u8 )

Replace this string in gamecenter.py * Not sure if it's exactly right, but it should be close -- pathToKey.append(os.path.join("http://localhost:8080/" + filename + str(i) + ".m3u8.key"))

And that should do it temporarily for Windows users.

[juggie]

Ok, wait a minute. Carb0 is not downloading the .m3u8 file every 10 seconds. The .ts files are predictable therefore he creates only ONE file. He just fills the entire file full of what it already expects. Check out the newest GCL and as soon as it asks for the home or away feed, go to your plugin.video.GCL etc.. and check for yourself. Look in the home.m3u8 file and you'll see what I mean.

Edit: I see now, this is super easy. You can download this mongoose server temporarily, until carb0 adds a HTTP server through XBMC. What you do is just add your folder path to the document_root path in mongoose ( C:\Users\Hyperium\AppData\Roaming\XBMC\addons\plugin.video.nhl-gamecenter\m3u8 )

Replace this string in gamecenter.py * Not sure if it's exactly right, but it should be close -- pathToKey.append(os.path.join("http://localhost:8080/" + filename + str(i) + ".m3u8.key"))

And that should do it temporarily for Windows users.

Not necessarily downloading no, but he writes the file on a python threading.timer() every 10 seconds. I have no idea how often the xbmc player requests it. But ultimately it does result in a collision when the file is being written at the same time as xbmc player is reading it.

I was going to add the the micro http server into the old version of the addon but I only found it on the svn server right before I went to bed. I may give it a shot tonight during the games when I can test it. I did however write the http proxy in python last night before going to sleep. It already rewrites the .m3u8 file when requested to include the new key location (essentially to point back at the proxy). I just need to modify the old version of GCL to point at the proxy and see if it works. if that works then I'll integrate it into the addon and test it.

What I don't know (not being familiar with XBMC addons) is what the life of a python addon is. Eg, do components of the addon run the entire time you are within the addon (initial observation is no) or does the whole thing refresh on each new page. Eg going from Main screen -> Live games page would reload the whole thing. Based on my initial observations this appears to be the case. Obviously things keep running while in the playback as Carb0 was able to use that to keep updating the m3u8 file. I know python well but the within xbmc is new to me.

In any case time permitting I will work on this during the live games tonight.

[Seismic Wave]

Not necessarily downloading no, but he writes the file on a python threading.timer() every 10 seconds. I have no idea how often the xbmc player requests it. But ultimately it does result in a collision when the file is being written at the same time as xbmc player is reading it.

Is this the reason for the occasional stutter?

I'm running a RPi on OpenElec and every so often the live stream stops for a second and then starts again.

[Hyperium]

Ok, wait a minute. Carb0 is not downloading the .m3u8 file every 10 seconds. The .ts files are predictable therefore he creates only ONE file. He just fills the entire file full of what it already expects. Check out the newest GCL and as soon as it asks for the home or away feed, go to your plugin.video.GCL etc.. and check for yourself. Look in the home.m3u8 file and you'll see what I mean.

Edit: I see now, this is super easy. You can download this mongoose server temporarily, until carb0 adds a HTTP server through XBMC. What you do is just add your folder path to the document_root path in mongoose ( C:\Users\Hyperium\AppData\Roaming\XBMC\addons\plugin.video.nhl-gamecenter\m3u8 )

Replace this string in gamecenter.py * Not sure if it's exactly right, but it should be close -- pathToKey.append(os.path.join("http://localhost:8080/" + filename + str(i) + ".m3u8.key"))

And that should do it temporarily for Windows users.

Not necessarily downloading no, but he writes the file on a python threading.timer() every 10 seconds. I have no idea how often the xbmc player requests it. But ultimately it does result in a collision when the file is being written at the same time as xbmc player is reading it.

I was going to add the the micro http server into the old version of the addon but I only found it on the svn server right before I went to bed. I may give it a shot tonight during the games when I can test it. I did however write the http proxy in python last night before going to sleep. It already rewrites the .m3u8 file when requested to include the new key location (essentially to point back at the proxy). I just need to modify the old version of GCL to point at the proxy and see if it works. if that works then I'll integrate it into the addon and test it.

What I don't know (not being familiar with XBMC addons) is what the life of a python addon is. Eg, do components of the addon run the entire time you are within the addon (initial observation is no) or does the whole thing refresh on each new page. Eg going from Main screen -> Live games page would reload the whole thing. Based on my initial observations this appears to be the case. Obviously things keep running while in the playback as Carb0 was able to use that to keep updating the m3u8 file. I know python well but the within xbmc is new to me.

In any case time permitting I will work on this during the live games tonight.

Interesting, I must've missed that part. Although, I'm also not a python coder so I don't know 100% of what I'm looking at. And to the guy who has the stutter, I would guess if the stopping and starting follows an exact pattern, for example every 'x's amount of time, I would assume that would be the cause.

[juggie]

Interesting, I must've missed that part. Although, I'm also not a python coder so I don't know 100% of what I'm looking at. And to the guy who has the stutter, I would guess if the stopping and starting follows an exact pattern, for example every 'x's amount of time, I would assume that would be the cause.

If you take a look at def LIVELINKS(..) you can see the m3u8 file is downloaded using the download function, then a timer is started to expire in 10 seconds. Inside that function there is logic to write the m3u8 and then set the time for another 10 seconds. This loop of every 10 seconds continues as long as video is being played back and will stop when you are not.

I'd rather let the far end server do what it is supposed to do and provide the m3u8 when ever xbmc chooses to request it. All we have to do to fix the unfortunate issue is act as a middle man so that we can ensure the proper User-Agent is passed on the request for the .key file.

Has anyone submitted a bug to the bug tracker for this? The exact issue is that while you can pass |User-Agent=foo on to the xbmc player. It does not pass User-Agent=foo when it does the request for the key which it reads from the m3u8.

[Carb0]

Not necessarily downloading no, but he writes the file on a python threading.timer() every 10 seconds. I have no idea how often the xbmc player requests it. But ultimately it does result in a collision when the file is being written at the same time as xbmc player is reading it.

I was going to add the the micro http server into the old version of the addon but I only found it on the svn server right before I went to bed. I may give it a shot tonight during the games when I can test it. I did however write the http proxy in python last night before going to sleep. It already rewrites the .m3u8 file when requested to include the new key location (essentially to point back at the proxy). I just need to modify the old version of GCL to point at the proxy and see if it works. if that works then I'll integrate it into the addon and test it.

What I don't know (not being familiar with XBMC addons) is what the life of a python addon is. Eg, do components of the addon run the entire time you are within the addon (initial observation is no) or does the whole thing refresh on each new page. Eg going from Main screen -> Live games page would reload the whole thing. Based on my initial observations this appears to be the case. Obviously things keep running while in the playback as Carb0 was able to use that to keep updating the m3u8 file. I know python well but the within xbmc is new to me.

In any case time permitting I will work on this during the live games tonight.

As far as I know the player downloads the last 3 ts files (30 seconds buffer) and then starts to play the stream. To be 'sure' that a new ts file exists I have to wait at least 10 seconds until I can update the m3u8 file. And the XBMC player probably requests the m3u8 file even more frequently to keep the buffer constantly at 3 ts files.

It got the server working inside of the add-on but I don't know how to stop it when you leave the add-on and restart the server when you open the add-on again. I always get a sockets error.

Yes, the whole thing refreshes when you click on a category. If you could work on this that would be nice. I live in Europe and can't stay up every night just to test the add-on and the streams from last night already stopped working.

If you take a look at def LIVELINKS(..) you can see the m3u8 file is downloaded using the download function, then a timer is started to expire in 10 seconds. Inside that function there is logic to write the m3u8 and then set the time for another 10 seconds. This loop of every 10 seconds continues as long as video is being played back and will stop when you are not.

I'd rather let the far end server do what it is supposed to do and provide the m3u8 when ever xbmc chooses to request it. All we have to do to fix the unfortunate issue is act as a middle man so that we can ensure the proper User-Agent is passed on the request for the .key file.

Has anyone submitted a bug to the bug tracker for this? The exact issue is that while you can pass |User-Agent=foo on to the xbmc player. It does not pass User-Agent=foo when it does the request for the key which it reads from the m3u8.

It would definitely be a nicer solution to use the server. Apok said that he's working on a fix.

[juggie]

As far as I know the player downloads the last 3 ts files (30 seconds buffer) and then starts to play the stream. To be 'sure' that a new ts file exists I have to wait at least 10 seconds until I can update the m3u8 file. And the XBMC player probably requests the m3u8 file even more frequently to keep the buffer constantly at 3 ts files.

It got the server working inside of the add-on but I don't know how to stop it when you leave the add-on and restart the server when you open the add-on again. I always get a sockets error.

Yes, the whole thing refreshes when you click on a category. If you could work on this that would be nice. I live in Europe and can't stay up every night just to test the add-on and the streams from last night already stopped working.

It would definitely be a nicer solution to use the server. Apok said that he's working on a fix.

How are you doing your loop to keep asyncore running? You should be doing like:
while not xbmc.abortRequested:
asyncore.loop(timeout=1)

when xbmc tries to close the addon, this loop should exit. I have not tested this, that is just what I found in various places.

If you could send me a link to what you have so far, I will debug it more tonight.