UTF-8 hack for Vomp client

[JTe]

Because the new 1.7.x VDR works well only with UTF-8 I made up a UTF-8 hack for Vomp client (0.3.1-2-Yaris).

This is really just a hack and the idea is to change the UTF-8 codec to ISO-8859-1 only just before printing the text on the screen. All the string handling except printing (and justifying) is in UTF-8 and just when the characters are placed on the screen they are converted to Latin characters of vomp client. The characters that cannot be converted (are not part of the ISO-8859-1) are replaced by [space], because that looks best on the screen (there is a small 'feature' in my code that it sometimes leaves one byte of a multibyte utf8 character at the end of the string, so this kind of fixes it the dirty way...)

You have to patch the client with attached patch, and also remember to convert the translation files to utf8 in l10n by running:

iconv -f iso-8859-1 -t utf-8 main-xx > newfile;cp newfile main-xx

where you replace xx with your language code.

The patch adds to a "Advanced" configuration menu a item "Use UTF-8 conversion" where you can select the utf-8 encoding (just for backwards compatibility). The default will be the old ISO-8859-1.

And of course you have to enable utf-8 on the vdr side and have the recordings directory in utf-8, etc.

I really hope the attached patch is complete as I just upgraded my development server to 64 bit squeeze and I do not manage to compile a client dongle anymore... I am not getting any error messages, but the dongle file is 4064 bytes shorter than before and will not load, so I guess there is something with the 64 bit environment that brakes the scripts. I have to investigate that more.

Anyway I have been testing this now for 4 weeks and I have had no crashes, nor other problems!

[odin4242]

Hi JTe,

since i don't get the build environment for the dongle to run on my VDR, could you please post a new dongle including the UTF-8 patch? Version 0.3.1-3-Yaris would be cool

Thanks in advance

[JTe]

My current client version is vomp-dongle-0.3.1-2.2 which is based on version 0.3.1-2-Yaris with the following patches:

- Display and timing improvements while playing some recordings. (Thanks to MartenR) / from 0.3.1-3-Yaris
- Set teletext updates to a higher value that it works more responsive.  / from 0.3.1-3-Yaris
- My subtitle patch
- My utf8 hack
- added few missing tr() -calls to make the translations to work better

As there is the 2M limit to attachments I am trying to upload the client split in two parts, so download attached file "vomp-dongle-xaa" and the one attached to my next message "vomp-dongle-xab" and cat them together with the following command:

cat vomp-dongle-xaa vomp-dongle-xab > vomp-dongle

[JTe]

The second part is here...

[4ndreas]

Hi JTe,

thank you very much for your work! Your Dongle solves a small problem I had with vomp-dongle-0.3.1-3-Yaris: I can use all fast forward speeds now (with 0.3.1-3 16x and 32x don't work).

But I can't get the UTF8 encoding work. I have vompserver 0.3.1-3-Yaris (I can't find version 0.3.1-2-Yaris) which I leave untouched. I changed the configuration to use your dongle file and I converted the file main-de in /video/plugins/vompserver/l10n (no changes made in vdr-1.7.27/PLUGINS/src/vompserver-0.3.1-3-Yaris/l10n).  I restarted the MVP and it shows the correct version on the screen. All functions work as before but the texts are still shown with no conversion of the UTF8 characters (I see two "ugly" characters instead of one Umlaut).

What am I doing wrong?

regards,
4ndreas

OS: opensuse 12.1
VDR: 1.7.27
vompserver: 0.3.1-3-Yaris
vompclient: as posted by JTe on May 02, 2012

[4ndreas]

Hi JTe,

just forget my posting 
I looked at the setup but did not change anything as it looked fine. Now I switched the UTF8 conversion from On to Off to On again and now it's working as expected! Sorry for the confusion.

regards,
4ndreas

[JTe]

I guess I have a small bug on the default value of the UTF8 encoding selection if you had to do that... I will check it. And thanks for pointing it out as I never tested the dongle on a fresh install!

-Jussi

[Chris]

Hi all..

Marten sent me a UTF8 patch and urged me to apply it to the server code. It all works server side and sends ISO-8859 to clients by default unless it is asked by the client to send UTF8. I believe this is different to the way your patch works? I'm glad there's still interest in making vomp better!

[JTe]

Yes, it is a different and most likely better approach as you do not need to compile client side dongle, which is difficult for many people. My patch makes the UTF8 - ISO8859 conversion on the fly on the client side. I made the patch on the client side because at the same time I needed to make a hack to get the subtitles to work (to erase the subtitle area page_time_out).  See: http://forum.loggytronic.com/index.php?topic=503.0

But that subtitle patch, even it is working is not very well coded and should not be applied to git repo without some serious tiding up...!

[MartenR]

Chis, thanks for applying the patch.
Now the protocoll of the server in git is compatible to old 0.3.1 and the experimental raspberry branch.
Altough the raspberry branch can not do anything  useful at the moment.

Marten

[odin4242]

Thanks guys, we'll use that server for the upcoming easyvdr 1.0

[JTe]

I finally managed update my server to the "git" version to test the Raspberry PI client. Meanwhile I noticed that the server side UTF8 patch is not working for "Timers" menu. Could you fix that Marten, when you have time for it...

[MartenR]

Well, I am currently away from my vdr. But looking in the code, it seems like the problem is coming from the filename of the recording.
Which has to stay untouched from the conversion routine, this can only be solved by a major change in protocoll.
Anyway I will soon convert the raspberry gui to utf-8, then at least for them the problem will go away on UTF-8 systems.

Marten

[JTe]

Ok, Now I remember it. That was the reason I did finally decide to make my UTF8 hack on the client side. I guess it could be resolved on the server side by the server sending in addition to a file name a "printable file name" field to a client... That of course requires changes to client code too.

[MartenR]

Yes, that is the way to do it. But I think this should wait until a new release is closer on all platforms in order to not cause too much hassle for the tester in the current development branches.

Marten