Recording program to a recgroup containing ä/ö characters, corrupts the recording group name

[otto at kolsi dot fi]

If recording group name contains e.g. characters 'ä', or 'ö', when you schedule and record a program to this recording group the group name gets corrupted in DB (table 'recorded', column 'recgroup'.

End result is that if you scheduled a recording to 'Metsästys' group, when it is recorded, there is a group like 'MetsŤstys'. There's probably just one .toUtf8() / .fromUtf8() type of call missing somewhere where recording info is stored to DB.

Other than this, recgroups containing other than plain ASCII characters seem to work fine (in playback, in MythWeb etc.).

[otto at kolsi dot fi]

Attached a patch that fixes the issue by removing one .utf8() call.

I've tried to verify that this doesn't brake anything by recording various shows to recgroups with names containing non-ascii and just ascii characters.

[stuartm]

My concern is that we have obviously pulled the recgroup name from the database somewhere without converting it to unicode - which goes against what we do with every other text string. Although it might mean more changes, the correct way to handle the problem would be to find where we've missed .fromUTF8()

I'm wondering why we are passing around recgroup as a string anyway - using a numeric id is much safer and makes changing things like the recgroup name much easier. Perhaps we need to setup a recgroup table indexing the recgroups by an id, storing the name and password (replacing recgrouppassword).

[otto at kolsi dot fi]

Replying to stuartm:

My concern is that we have obviously pulled the recgroup name from the database somewhere without converting it to unicode - which goes against what we do with every other text string. Although it might mean more changes, the correct way to handle the problem would be to find where we've missed .fromUTF8()

I thought exactly the same, should have mentioned that in the ticket. I very briefly tried to find the place where we pull out the recgroup from the database and that seemed to have the correct .fromUTF8() call in place. But I could have (and obviously did) missed something.

If anyone else is having this problem, original patch can be used as a workaround but as you said, it's better to fix the initial cause of the problem.

[stuartm]

Otto could you try the patch I've attached? I don't have time right now to convert everywhere that uses recgroup to use a numeric id and even if I started, I'd then have to do the same for the playgroup, storagegroups and a dozen other things. So I've just made sure that we are converting recgroup to unicode when pulling it from the database.

[stuartm]

(In [14119]) Make sure recgroup is converted to unicode after being loaded from the database.

Fixes #3539

[otto at kolsi dot fi]

This issue in fact has not been fixed, I somehow wrongly tested it earlier. Here is additional steps to reproduce this problem:

• take existing recording and assign it to a new recgroup named e.g. TEST-ü (containing any non-ascii character)
• verify that so far recgroup is shown correctly
• go and schedule recording and set it to record to this new test group
• when recording starts, go to Watch Recordings -> there's an additional recgroup with corrupted name: TEST-Ã1/4

[stuartm]

(In [16032]) A few Utf8 fixes for storagegroups, recgroups and playgroups.

Refs #3539

[stuartm]

(In [16051]) More UTF8() fixes on recgroup, storagegroup and playgroup names.

Refs #3539

[stuartm]

Otto, can you update and see if any of the fixes I've committed help? I'd also appreciate it if someone can test storage and playgroup handling of non-ascii characters or report any other areas which fail to work.