[mythtv] [mythtv-commits] Ticket #4381: Using a Miscellaneous Status Information (see ticket #4049) makes mythbackend segfault occasionnally...

Nicolas Riendeau knightr at istop.com
Sun Jan 20 04:09:35 UTC 2008


Hi!

Michael T. Dean wrote:

> Yeah.  I realized when I wrote that example script that there were 
> character set issues (same holds true of myth_upcoming_recordings.pl and 
> myth_recent_recordings.pl), but I didn't have a way to test and figured 
> they're a good start.

Yes...

I tried the two scripts you mentionned and when they are called by mythbackend they 
do have some character set problems...

> I think Otto K. recently put in a patch to fix some other shell script 
> recently (and possibly some Perl scripts) and I had marked it in my mail 
> client for follow-up so I could use it as a template for fixing the 
> myth_sensors.sh script (and possibly the Perl ones), but unfortunately I 
> lost my mythtv-commits and tickets folders due to a freak combination of 
> mouse movement and clicks when I dropped the mouse connected to my 
> laptop :( and I haven't attempted to find it again, yet.

For the myth_sensors.sh changing the locale before calling sensors works though it 
would probably be preferable to find a regex that works regardless of the locale.

For the Perl scripts, it looks like they are actually producing the right output 
(they are outputting UTF-8 and that page is in UTF-8).

What actually seems to be happening is that the script produce UTF-8 but the code 
that calls them doesn't know it and tried to re-encode them a second time in UTF-8 so 
a character that took 2 bytes in UTF-8 gets these two characters re-encoded a second 
time in UTF-8... At least it's what it looks like visually...

Assuming this was the case I replaced the "input.append(buffer);"

where you read the output of the script by "input.append(QString::fromUtf8(buffer));"

re:

while (fgets(buffer, sizeof(buffer), fp))
{
     input.append(QString::fromUtf8(buffer));
}

and this seems to have done the trick, the output appears to be correct now...

[If I understood the usage of QString::fromUtf8(something) what it does it that it 
knows that something is in UTF-8 and, more importantly, that the output is also in 
UTF-8 and it keeps that information so it doesn`t try to remap the characters a 
second time... BTW, QString::fromUtf8(something) actually seems to be a special case 
of QString::fromUtf8(something, lenght)]

That modification shouldn't cause any problem with scripts that produce US-ASCII or 
UTF-8 since UTF-8 is actually a superset of US-ASCII...

Can anybody confirm my interpretation and if the modification mentionned above does 
indeed correct the problem?

(I've attached to this message an updated version of your patch in which I manually 
edited the above-mentionned line... If that does indeed correct the problem we could 
possibly replace the patch in the ticket with this one before it gets committed even 
though that's a different issue...)

> If anyone out there with more knowledge of shell/Perl scripting than me 
> knows how to fix them properly, patches would be much appreciated.  If I 
> don't hear back from anyone, I'll probably take a look at fixing them 
> next week.

Believe me your knowledge of shell/Perl scripting is a lot better than mine... I just 
happen to have the possibility to easily test this since I live in a place where the 
local programming is in more than one language...

Thank you and have a nice day!

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mythtv-misc_status_info_popen_v2.patch
Type: text/x-patch
Size: 4603 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20080119/09459de7/attachment.bin 


More information about the mythtv-dev mailing list