(2012-05-31, 14:14)divingmule Wrote: That is really strange. I'm not sure what to think

If your up for editing the add-ons default.py, you may try changing these lines near the top of the file from -

Code:

try:
    import json
except:
    import simplejson as json

to -

Code:

import simplejson as json

In the future, please use a site like http://pastebin.com to copy your log to, then post the link.

(2012-05-31, 20:35)sdsnyr94 Wrote: I asked because I tried on a FAT32 flash drive and bumped against what I thought was the 4GB limit..... but now I will need to watch the file size to see if I stop ~2.5 also.... I'll let you know later.

(2012-06-01, 01:52)divingmule Wrote: If you want to test further you might try commenting the os. calls in the mlb_hls_check function of the default.py and see if the file continues to download when the player stops.

Code:

def mlb_hls_check(filename):
        addon_log( '--> playback started' )
        while (True):
            filename == get_file()
            xbmc.sleep(2000)
            if filename != get_file():
                # os.system('pkill mlbhls')
                # os.remove(filename)
                # os.rmdir(tmpdir)
                addon_log( '--> broke out of loop' )
                break

(2012-06-01, 03:16)sdsnyr94 Wrote: OK, so I created a folder called MLBTemp in the /storage folder in Openelec.... then mounted an NFS share to the folder.... MLBMC-HLS can now use this folder as the Temp location. Has not affected performance...but I have only let it run for about 1/2 hr.

(2012-06-01, 03:16)sdsnyr94 Wrote: tmoe - I have had archived games play flawlessly in the non-HLS version of MLBMC...

(2012-06-01, 03:16)sdsnyr94 Wrote: yet Live games stop to buffer every now and then. I had the same results with my aTV2's native MLB app... could it be something in their transmission during live games?

(2012-06-03, 16:47)divingmule Wrote: Yeah, something is causing mlbhls to pause, it's status switches to "pipe_wait". When using the file-in/file-out method, you would see this when pausing the player or if there were network issues.

(2012-06-04, 18:38)sdsnyr94 Wrote: Could we just be burning through that little buffer (I set mine at 45 seconds) due to changes in transmission speeds on their end?

I may try setting the buffer at 5 minutes just to see if the file gets past the 2.4 GB "limit".

(2012-06-05, 05:02)gnrtool82 Wrote: Just made a post about something not working.

(2012-06-05, 05:02)gnrtool82 Wrote: Best add-on there is!

(2012-06-04, 19:45)tmoe Wrote: Yupp, my guess is that something causes the communication between the mlbhls child process and the calling process to drop out when dealing with such huge files. Maybe we could play around with the Popen() call to see if it makes a difference, e.g alter i/o streams (sdin, stdout, stderr) parameters.

(2012-06-06, 18:43)divingmule Wrote:

(2012-06-04, 19:45)tmoe Wrote: Yupp, my guess is that something causes the communication between the mlbhls child process and the calling process to drop out when dealing with such huge files. Maybe we could play around with the Popen() call to see if it makes a difference, e.g alter i/o streams (sdin, stdout, stderr) parameters.

That's what I was thinking also, tried a few things but haven't had any luck...

(2012-06-06, 20:07)sdsnyr94 Wrote: Can you get the start time of each inning on the fly (while video is playing), and is there a stop time for the end of each inning? Is there a way, using this information, that you could stop/start mlbhls so that it creates a new file every inning (or every couple of innings) to prevent the file size from getting so large?

(2012-06-06, 21:35)tmoe Wrote: maybe I find time to do some testing... i was thinking about calling some other function to fire up mlbhls; so in a way that these two processes arent linked and run independently/asynchronous (fire-and-forget)?! something like shell_exec(), exec(), whatsoever. Does that make sense?!