[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