ProppFrexx ONAIR User-Forum

Dear support,
Is it possible to get access to url encoding or "cleaning" functions in actions like EXEC_SEND_HTTP_GET/POST ? Especially accented characters are not well supported depending on target systems.
The same problems happens when we use the function EXEC_WRITE_PLAYLISTFILE to export a json or xml file. Functions *[STRING are not interpreted in those contexts ?
Thank you in advance. Best regards

ProppFrexx internally always uses unicode (resp.UTF-8) where any character specific encoding is NOT needed.
This includes the EXEC_WRITE_PLAYLISTFILE function as well as the EXEC_SEND_HTTP_GET/POST methods - all is handled in UTF-8 here!
So I doubt, that any encoding or cleaning function will help you here - the unicode/UTF-8 character format already is multi-byte and supports any special characters in any language!

I assume, that the origin issue already happens when reading the metadata. eg. when reading from the audio file!
Many formats, like WAV RIFF or even MP3s often use/require the Latin1 character encoding. Latin1 however only supports a limited character set, i.e. no special characters accented characters.
However, you have various options (default is strict handling), see the general settings, section Meta Data/WaveForm, e.g. Use UTF-8 for Riff Info (.wav) or Use Broken Latin1 (.mp3).
These options will allow to read the meta data content in a multi-byte format and don't handle the data fully according the specifications - as some tools do write incorrect meta data to the files.

Please try this or send me a sample audio file where you have issues with - after you have tried the above.

Dear Bernd,
We have seen that the json file resulting from EXEC_WRITE_PLAYLISTFILE begins with a BOM (Byte-order-mark) : EFBBBF. Is it possible to remove it to get a 100% valid json file ?
Here is the command we use :
EXEC_WRITE_PLAYLISTFILE now.json|template.json
Thank you in advance. Best regards

The EXEC_WRITE_PLAYLISTFILE currently always writes its content in UTF-8 format, which also (by default) always contains the BOM at the beginning of a file, as that function is not tailored to write specifically JSON files, but any. And by default (in .Net) all UTF-8 files does contain a BOM.

However, I'll take a look of what can be done instead...e.g. for certain html or json file extensions I might explicitly omit the BOM.

Thank you, yes I think it could be a good solution. Do you know when it could be available please ?

Yes, now
A v4.2.7.7-beta is available for you. Please select "Check for Beta-Versions..." to install. This beta only contains that BOM issue fix and is as such only as a beta. But that fix will also make its way into the next update...

Dear Bernd, I have tested the new version but now all special characters are encoded in HTML in our json files. Is it due to the last update (BOM) or other change ? Is it possible to choose between UTF-8 encoding or HTML special chars encoding ?
Thank you in advance. Best regards

Example here (unicode decimal code "é" instead of "é") :
{"artist":"Claudio Capéo","title":"Ta Main","starttime":"2022-07-06 17:55:14","duration":"217.004","cover":"","coverUrl":""}

Only the BOM has been removed. Nothing else was changed. But I can check again.

…update. You are right. I will provide a new version soon.

OK perfect, thank you !

A new v4.3.1.0 has just been released. JSON files are not encoded any longer (was a bug), and doesn't contain any BOM.