Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[avid]

When I have a scheduled recording and get its info via http://localhost:52199/MCWS/v1/Television/GetRecordingScheduleXML, I get two different encodings for the start date and time.

So on Windows (which has been working for a while now) I get a response of

Code: [Select]

<Item Name="Recordings">
<Rec>
<ProgKey>585202</ProgKey>
<ChannelKey>350828</ChannelKey>
<RecordingID>543143068</RecordingID>
<StartTime>11/09/2023 20:55</StartTime>
<Duration>4499</Duration>
<ProgName>The Inheritance</ProgName>
<Description>While the police investigate Dennis' death, the Watson siblings hunt for their father's previous will as they try to show his original intentions, and that his death was not accidental.</Description>
<Status>Scheduled to be recorded.</Status>
<TypeOfRecording>One time recording based on programming guide</TypeOfRecording>
<IsRecordingNow>0</IsRecordingNow>
</Rec>
</Item>
But in my new Linux port I get

Code: [Select]

<Item Name="Recordings">
<Rec>
<ProgKey>74770</ProgKey>
<ChannelKey>44845</ChannelKey>
<RecordingID>2137823542</RecordingID>
<StartTime>11/09/23 08:55 pm</StartTime>
<Duration>4499</Duration>
<ProgName>The Inheritance</ProgName>
<Description>While the police investigate Dennis' death, the Watson siblings hunt for their father's previous will as they try to show his original intentions, and that his death was not accidental.</Description>
<Status>Scheduled to be recorded.</Status>
<TypeOfRecording>One time recording based on programming guide</TypeOfRecording>
<IsRecordingNow>0</IsRecordingNow>
</Rec>
</Item>
The StartTime values are just so weirdly different and make porting a real hassle! No only does the Linux version use an AM/PM 12-hour time, but it only has a 2-digit year.

Are these (different) fixed formats or are they culture-specific in any way?

[Yaobing]

I don't think we have two-track coding for Linux and Windows, not with regard to TV recording schedules and MCWS.  I would guess it is the default date format setting of each OS that determines the output format, but I am not sure, as I don't know how we handle date time format for Linux.

[avid]

OK Thanks.

I am now handling either/both of the DateTime formats I have seen used, in the hope that it is only OS-dependent and not culture-dependent.

If it turns out to be culture-dependent as well, then the code will not work except in the UK!

And there is actually only that single instance where I need to parse a formatted DateTime string which I have not written myself. All other TV DateTime values returned by MCWS (e.g. in the EPG) are encoded as fractional days since 30-dec-1899

[Yaobing]

I took another look.  Our FormatDate() function is implemented differently for different OS.  Since I don't quite know how it works in Linux, I am going to add a parameter in GetRecordingScheduleXML function so the datetime can be in either formatted form, or "number of days since..."

[Yaobing]

It's done (for build 55 - not built yet).

Changed: Added a parameter FormatDateTime to MCWS function GetRecordingScheduleXML to specify whether to format the StartTime returned value.

Add a parameter FormatDateTime=0 to get StartTime returned as a string of decimal numbers.

[avid]

Thanks for this.

I'll update my code to use it once I upgrade my test and live machines to that latest version.

[avid]

The new parameter works as it should. I consider this issue as solved.

[Yaobing]

Thanks for the update.