[WIP] New Confluence Skin for XNEWA

[mvallevand]

Yea, I just figured out basically the same thing.

I looked at a recording in the NextPVR client, and it shows The Last Ship recorded from 5:59pm - 7:03pm on 22 June 2014. The same show when queried using the RecordingSummary reports back it started recording at 03:59:04 on June 23, 2014. So that's exactly 10 hours off.

Is that what you are seeing with after the change I suggested from sum2dict_json?

Martin

[pkscout]

Is that what you are seeing with after the change I suggested from sum2dict_json?

I think so. Here's what I changed in sum2dict

Code:

theDict['start'] = summary.StartTime

to:

Code:

theDict['start'] = datetime.datetime.fromtimestamp(time.mktime(time.strptime(str(summary.StartTime),'%Y-%m-%d %H:%M:%S')))

I had to wrap summary.StartTime in str() because without it strptime complained that it wasn't a string object. I also removed the 'T' from the middle of the datetime format, as summary.StartTime didn't include that (with the 'T' XNEWA generated an exception error).

Even with that change, I still get the time/date without the 10 hour offset for my timezone. It feels like NEWA isn't adjusting properly for timezone when it sends back the response.

[mvallevand]

I've suggested a change to UJB. I consider it largely cosmetic anyway as the sort order is correct.

Martin

[pkscout]

I've suggested a change to UJB. I consider it largely cosmetic anyway as the sort order is correct.

Thanks. When your the guy working on the skinning, it's all cosmetic, but it's all important to you.

[mvallevand]

Thanks. When your the guy working on the skinning, it's all cosmetic, but it's all important to you.

Fair enough. Kind of like your "cosmetic" change to take the date time format from XBMC. Not only does XBMC not give Canadians a 24h time option, they think we use American-style short format. A pain in the butt to have to edit a UAC controlled file langinfo.xml to get around this.

Martin

[mvallevand]

all times will be in 24 hour format (like 17:04). If you chose US(12h), you'll get something like 5:04 PM. If you choose a non-US region, your date will match the date format for your region.

There is a problem stripping too many leading zeroes between midnight and 1am in 24 hr format the following might be better

Code:

def xnewa_time( dt, withsecs=False, leadzero=False ):
    if leadzero:
        return dt.strftime( _timeformat( withsecs ) )
    else:
        newTime = dt.strftime( _timeformat( withsecs ) ).lstrip('0')
        if newTime[0].isdigit():
          return newTime
        else:
          return '0' + newTime

Martin

[pkscout]

There is a problem stripping too many leading zeroes between midnight and 1am in 24 hr format the following might be better

Code:

def xnewa_time( dt, withsecs=False, leadzero=False ):
    if leadzero:
        return dt.strftime( _timeformat( withsecs ) )
    else:
        newTime = dt.strftime( _timeformat( withsecs ) ).lstrip('0')
        if newTime[0].isdigit():
          return newTime
        else:
          return '0' + newTime

I was trying to match the display exactly in XBMC. In both 12 and 24 hour format, XBMC (Well Gotham Confluence at least) doesn't show the leading zero. So if you want the leading zero by default, you could just change the code in that function to:

Code:

def xnewa_time( dt, withsecs=False, leadzero=True ):
    if leadzero:
        return dt.strftime( _timeformat( withsecs ) )
    else:
        return dt.strftime( _timeformat( withsecs ) ).lstrip('0')

BTW, if you don't want XNEWA to format the time/date any differently than it does now, that's fine. I'll probably just modify the date/time format codes on my local system as updates come out.

[mvallevand]

I was trying to match the display exactly in XBMC. In both 12 and 24 hour format, XBMC (Well Gotham Confluence at least) doesn't show the leading zero. So if you want the leading zero by default, you could just change the code in that function to:
BTW, if you don't want XNEWA to format the time/date any differently than it does now, that's fine. I'll probably just modify the date/time format codes on my local system as updates come out.

I have no problem with using XBMC to decide, but XBMC doesn't truncate the zero hour which the current code does.

Martin

[pkscout]

OK, now I see what you were talking about. My bad. Here's a fix for the leading zeros and a fix for the lack of timezone offset in the RecordingSummary. The zip just has xnewa_datetime.py and recent.py. The changes are really all in the xnewa_datetime library. recent.py only needed a small change to call the GMT offset when needed.

[mvallevand]

I like your fix for midnight but not keen on moving time fixes out of xnewa_connect. I want it to be the glue to newa having it do all the data normalization. I might move it to lib but I definitel want it to b e a lib any future xbmc addon could use. I still have to move player out of details to isolate things better but web client and x-newa should in theory be able to work as two addons with proper planning.

Martin