[mythtv-users] uPnP - new problems in 0.27.2

[Ludvik Tesar]

Jean-Yves Avenard <jyavenard at gmail.com> wrote ..
> On 4 July 2014 08:58, Ludvik Tesar <ludvik.tesar at gmail.com> wrote:
> 
> > It seems the problem is that instead of correct port (which is 6544) there
> > is unicode character U+0090 in the soap response for UPnP. For example :
> > http://10.0.0.12:<U+0090>/Content/GetRecording?ChanId=1001&amp;StartTime=2014-07-03T21:20:00Z
> 
> ...
> 
> First a typo that would cause GetBackendStatusPort to return not the
> status port (6544) but the control port(6543)
> 
> And then, the function would return an int. The old code expected a
> string. The default QString constructor has a QChar paramater, which
> would convert the int into a UTF-16 char instead..

Hi Jean-Yves,

It seems that in my case GetBackendStatusPort have not returned the control port 6543 but the status port 6544 = 0x1990, because in the XML file it was U+0090 and not U+008F. I am assuming that there must have been some conversion like this : int->char->QChar->QString that would remove the high byte : 6544=0x1990 --> 0x90 --> U+0090

Anyway, thank you very much for the fix. I think it is very appreciated, how quickly you have produced it.

Maybe this might help for testing : For quick verification of what is mythtv upnp soap request returning, I am using this small script(in attachment), that only uses standard utilities wget and xmlstarlet. I am not sure, whether there is some better way to get the response from mythtv, but with little bit of fiddling, this could be easily amended for other upnp or dlna servers and used for comparison. Or it can be used for some kind of unit testing the upnp in mythtv.

Ludvik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fetch-mythtv-upnp.sh
Type: application/octet-stream
Size: 1303 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140704/79c0d73a/attachment.obj>