Форум » » Интеграция Bluesound » Ответить

Интеграция Bluesound

Paul_T: Имеем устрйство Bluesound (сейчас довольно распространено, даже NAD делает свои плееры Blueos). Есть "родной модуль" для Crestron. Все бы ничего, крме пресловутых кириллических символов. При чем устройство, видимо, автоматически выбирает язык на основе тех установок устройства, на котором запущено приложение плеер (windows, android итд). И начинает Crestron'у возвращать смесь из ASCII (латиница) + UTF-8 (кириллица) в вормате \x04\xXX Я поправил всем известный Simpl+ модуль UTF-8 to ASCII, чтобы он декодировал UTF-8, начинающийся с первого байта \x04, а латиницу пропускал, как есть. Все работает, если в терминале непосредсвенно задать строку вида \xXX\xXX ... итд. Декодируются как киррилические символы, так и смесь латиницы и кириллицы. Но не работает, если эта строка приходит от плеера. Кириллические символы частично пропускаются. Почему- загадка. При этом, если скопировать строку, что пришла от плеера и заново ее задать в терминале, то все ОК. Пример входящей строки \x31\x38\x31\x2E\x46\x4D\x20\x54\x68\x65\x20\x45\x61\x67\x6C\x65\x20\x28\x43\x6C\x61\x73\x73\x69\x63\x29\x20\x28\x04\x1A\x04\x3B\x04\x30\x04\x41\x04\x41\x04\x38\x04\x47\x04\x35\x04\x41\x04\x3A\x04\x38\x04\x39\x20\x04\x40\x04\x3E\x04\x3A\x29 Отсюда 2 вопроса: 1. Где искать ошибку в декодировании 2. Можно ли как-то принудительно задать язык тегов, которые он возвращает или задать транслитерацию? И забыть про кириллицу. UPD И еще вопрос - каким образом Crestron смобирает строку из входящих данных? Должен быть какой-то таймаут, при привышении которого считается, что строка пришла. Этот параметр как-то можно узнать или поменять? Например, с некоторых устройств, что работают по Modbus ответы приходят отдельными символами (так крестрон их определяет) и приходится самому собирать их в строку... По теме... разкомментил WaitForInitializationComplete(); Других мыслей пока нет.

Ответов - 14

Chikalov: Есть уверенность что данные приходят целыми, а не множеством строк, кропнутых посреди UTF-8 символа?

Paul_T: Chikalov пишет: Да, вроде одной строкой приходят.

Chikalov: Может поможет, работу не проверял. string_function ToASCII (string data){ string tmp[2048]; integer BT; BT=GetC(data); // Читаем первый байт While (BT <= 0xFF) {//Читать буфер, пока он не опустеет if (BT==0x04) {// Читаем символ UTF-16BE BT=GetC(data); // Читаем следующий байт if (BT <= 0x4F) { tmp=tmp+chr(BT+0xB0); } else { return ("Это не UTF-16BE"); } }else{ tmp=tmp+chr(BT); } BT=GetC(data); // Читаем следующий байт } return (tmp); }


DmitriiP: добавьте #ENCODING_UTF16 в модуль .usp если его там нет или попробуйте пропустить текст через Mark As ASCII/UTF-16

Paul_T: Chikalov пишет: Спасибо. Так примерно и сделал, но проблема то не в декодировке, а в том, что если я сам шлю строку из терминала или по Serial_Send, то проблем нет. Проблема - когда строка приходит от модуля Bluesound...

Paul_T: DmitriiP пишет: #ENCODING_UTF16 нужен, если я пытаюсь UTF отправлять из Simpl+. ИМХО в данном случае это не поможет. ASCII/UTF-16 я делаю после преобразования в ASCII Проблема не в транскодировании, а в том, как строка приходит от модуля Bluesound...

Вячеслав: Что вы понимаете под "терминал"? Дебагер? Отступление: Бывали случаи, что дебагер отображает не так как оно есть на самом деле. Две одинаковые строки в дебагере панелью воспринимались по разному. У Вас строки в дебагере можно посмотреть (в HEX представлении)? Они одинаковые принятые от Bluesound и набитые в качестве теста руками в дебагере? (serial send для этого лучше не используйте, не поленитесь немного набить руками, в том числе незаконченные чтоб убедиться в работоспособности конвертора, serial send может и обмануть).По тексту похоже так, но уточните для уверенности. Таймаут буфера приема уже обсуждали, но никто не знает можно ли его где то настроить. Чтоб отмести лукавство дебагера, можно взглянуть на дамп перехвата wireshark-ом подсмотреть. Входную винегрет строку с "родного" модуля получаете или там клиент TCP используется? "Кириллические символы частично пропускаются." - т.е. конвертор все таки работает но не совсем правильно в случае реальной строки от модуля устройства?

Paul_T: Эм... Терминал не верно, согласен. Simpl Debugger. В HEX строки абсолютно одинаковые, в том то и дело. Входную строку получаю от родного модуля. Он запаролен. Да, конвертер работает корректно, если ему отдавать строку SerialSend или в debugger. Но не работает от "родного" модуля. Сегодня возвращаюсь к этой проблеме, попробую разные варианты.

Вячеслав: Гляньте тему click here, там пользователь eoulianov описал особенности отображения дебагером строк. Быть может Вам поможет "волшебство" штатного модуля ANSI-UTF16

Paul_T: Вячеслав пишет: Спасибо. Вопрос решился с помощью DmitriiP. Огромное спасибо всем!

VSolov: Здравствуйте! Подскажите, каким образом решили проблему? DmitriiP пишет: добавьте #ENCODING_UTF16 в модуль .usp если его там нет или попробуйте пропустить текст через Mark As ASCII/UTF-16 Mark As ASCII/UTF-16 это какой-то модуль? Можете поделиться?

DmitriiP: "исрпаленный" BluOS Device Processor v2.0.0.usp в лс ;)

Kaveckiy: DmitriiP пишет: "исрпаленный" BluOS Device Processor v2.0.0.usp в лс ;) А можно и мне?

4ertjaga_88: v2.4.0 получает url картинки радио, но не получает с airplay. и нет возможности программно переключить источники...есть варианты другие?



полная версия страницы