Print

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

[avid]

I have found two significant problems with MCWS Television/GetGuidePrograms.

Firstly, MCWS claims to return "XML formatted EPG program info". But the format returned is not valid XML.  So, for example I am getting:

Code: [Select]

<Response Status="OK">
<Item Name="Programs">
<Prog Key="393275">
<Name>Killer Contractor</Name>
<TV Channel>350799< TV Channel>
<Date Recorded>45138.5833333333284827< Date Recorded>
<Duration>3300</Duration>
<Season>2019</Season>
<Program ID>MV01558159.0000< Program ID>
<Keywords>Movie;TV Movie;Thriller</Keywords>
<Rerun>1</Rerun>
<Media Sub Type>Movie< Media Sub Type>
</Prog>
<Prog Key="393276">
                     ......

Note that several of the tags contain spaces, rendering the XML invalid and unparseable. Maybe these spaces can be replaced with underscore??

Secondly, I have so far failed to get the StartDate and EndDate parameters to work. All I can get is the next 24 hours. It may be that I have not discovered the correct encoding for these parameters, but my first assumption was the (Python?) floating-point dates, representing days since 12/30/1899, as is returned in the EPG. And that doesn't work. Is there a different encoding for StartDate and EndDate? Or is that broken too?

[avid]

For the benefit of future readers, just to clarify something I glossed over in the XML snippet above. The XML pretty-printer hides an important detail:

The content of the <Item> tags is not the sub-elements (in this case <Prog>). Instead it is XML escaped as text. So this text contents of the <Item> must be re-parsed as XML in order to get to those sub-elements. This appears to be true for any <Item> response to an MCWS call. It took me a while to work this out.

However, this does not explain the fact that the embedded XML (when re-parsed) is not valid. That is a real bug.

[Yaobing]

The content of the <Item> tags is not the sub-elements (in this case <Prog>). Instead it is XML escaped as text. So this text contents of the <Item> must be re-parsed as XML in order to get to those sub-elements. This appears to be true for any <Item> response to an MCWS call. It took me a while to work this out.

You got it.  The MCWS returns are always xml text.  If some specific items are also xml formatted, it is escaped in the outer xml doc and must be reparsed.

However, this does not explain the fact that the embedded XML (when re-parsed) is not valid. That is a real bug.

Can you elaborate with examples?  It works for me and other users.

[Yaobing]

Secondly, I have so far failed to get the StartDate and EndDate parameters to work. All I can get is the next 24 hours. It may be that I have not discovered the correct encoding for these parameters, but my first assumption was the (Python?) floating-point dates, representing days since 12/30/1899, as is returned in the EPG. And that doesn't work. Is there a different encoding for StartDate and EndDate? Or is that broken too?

It most likely is just an issue of what format is expected for these parameters.  Our date time parsing code can parse a variety of date time formats, but there are those that we don't parse correctly.  I thought floating point format might work, but it does not seem to on second look.  I can fix that.  You can try some human readable format and see how it works.

[avid]

Can you elaborate with examples?  It works for me and other users.

When I call Television/GetGuidePrograms I get a long XML response starting:

Code: [Select]

<Response Status="OK">
  <Item Name="Programs">&lt;Prog Key="393406"&gt;
&lt;Name&gt;Fatal Performance&lt;/Name&gt;
&lt;TV Channel&gt;350799&lt;/TV Channel&gt;
&lt;Date Recorded&gt;45142.5&lt;/Date Recorded&gt;
&lt;Duration&gt;3300&lt;/Duration&gt;
&lt;Season&gt;2012&lt;/Season&gt;
&lt;Program ID&gt;MV00793408.0000&lt;/Program ID&gt;
If you look at the inner XML, and particularly the tags "&lt;TV Channel&gt" and &lt;Date Recorded&gt;, this is not valid XML. I am having to run the inner text though a mangler which replaces  spaces with underscores between angle brackets (unless there is an equals sign) before I can parse it. The snippet in the original posting shows this pretty-printed

[avid]

It most likely is just an issue of what format is expected for these parameters.  Our date time parsing code can parse a variety of date time formats, but there are those that we don't parse correctly.  I thought floating point format might work, but it does not seem to on second look.  I can fix that.  You can try some human readable format and see how it works.

Thank you. I never even thought to try a human-readable string. The first one I tried (.Net's DateTime default format) works perfectly.

[Yaobing]

I have changed the output format of this function so that each program returned is in the format of

<Prog Key="3831329">
<Tag Name="Name">PBS NewsHour</Tag>
<Tag Name="TV Channel">33493</Tag>
<Tag Name="Date Recorded">45190.75</Tag>
<Tag Name="Duration">3600</Tag>
<Tag Name="Series">PBS NewsHour</Tag>
<Tag Name="Season">50</Tag>
<Tag Name="Episode">59</Tag>
<Tag Name="Program ID">EP01196307.3618</Tag>
<Tag Name="Keywords">News;Series;HDTV</Tag>
<Tag Name="Rerun">0</Tag>
<Tag Name="Media Sub Type">TV Show</Tag>
<Tag Name="To be recorded">1</Tag>
</Prog>

In other words, the field name is no longer the xml element name.  The element name is always <Tag>, and each element gets a Name attribute:

<Tag Name="Field Name">field value</Tag>

instead of <Field Name>field value</Field Name>.

This way we avoid having space characters in the element name.

[avid]

Thanks for this.

Is it too late, before it is released in a build, to change <Tag> to <Item>, which seems to be the convention in all other MCWS XML data??

Either way, I can handle it.

[Yaobing]

OK, "Item" it will be.

[avid]

Having proposed that change, I realise that this may be just as confusing. I see now that the response is already an <Item> which contains the <Prog> encoded as text - see my thread responses above from August 04, 2023, 12:33:04 and July 31, 2023, 08:39:03 pm.

So your <Tag Name="xxx"> idea is different as it is not further encoded as text (I presume). So my suggestion for naming that as "<Item>" could be just as inconsistent. And it may be confused with the existing top-level <Item>

So .. just take your pick. Maybe leave it as <Tag>. Either way, someone is going to end up confused in the future. Sorry to be throwing spanners in the works. I was just trying (and failing) to get some consistency in the XML returned from different MCWS calls.

[Yaobing]

 
I picked "Tag" in the first place because it is short and conveys enough information (as each of them is a "field" or a "tag" of an EPG program).

[JimH]

Tag it is then.

[avid]

Tested on the latest Windows and Linux releases and this works fine now. I've removed my code to "repair" the broken XML.

Thanks again