Обложка трека в истории плейлиста на сайт

mixradio

New member
Здравствуйте.
Есть скрипт вывода играющего трека с обложкой и список истории плейлиста для сайта: https://radioboss.ru/community_ru/t...ka-oblozhki-i-spiska-proigrannyx-trekov.4254/ (архив со скриптом прикрепляю).

Подскажите пожалуйста как можно сделать чтобы история плейлиста выводилась с обложкой и временем когда звучала?
Пытаюсь откорректировать данный скрипт но что-то не получается.
Заранее всем спасибо.
 

Вложения

  • nowplaying.zip
    3,5 КБ · Просмотры: 49
Не пойму, чего-то АПИ у меня не отдает через чтение тега artwork, хотя картинка есть на треке, ну то есть результат 01:40:17 [Artwork_Base64] => [HookIn] => - пусто
 
Через какую команду пробуете получить?
А их что несколько, которые возвращаю обложку в таком формате? Я нашел только через readtag. Еще две возвращают не XML, а напрямую картинку - это текущего и следующего трека, а мне нужно получить картинку произвольных треков. Вопрос ваш считаю странным, чисто для затягивания времени..

Вообще я бы очень доработал многие действия в плане добавления больше данных которые они возвращают. В прошлой версии кажется просил вас добавить там по некоторым командам кое-что... Очень все разнообразно по действиям, то один формат, то другой, то названия атрибутов по разному... все это настолько неудобно, что складывается впечатление что сделано все так специально, чтоб по максимуму усложнить работу с АПИ. Никакого желания улучшать АПИ я не вижу, никаких действий навстречу пользователю я не вижу... Почему так, Дмитрий? Вы получаете удовольствие от издевательства над пользователями или что? Я казалось бы уже 100 раз слышал всякие отписки, но все равно не перестаю удивляться такому наплевательскому подходу.. как к своему продукту так и к пользователю.
 
А их что несколько, которые возвращаю обложку в таком формате? Я нашел только через readtag. Еще две возвращают не XML, а напрямую картинку - это текущего и следующего трека, а мне нужно получить картинку произвольных треков. Вопрос ваш считаю странным, чисто для затягивания времени..
Команда имелось в виду, как делается вызов - в обновленная справка еще не опубликована, поэтому уточню здесь. В этой команде было изменение и теперь нужно добавлять параметр ...&artwork=1 чтобы в ответ была включена обложка (это сделано для экономии трафика при массовом чтении тегов, когда обложка не нужна).

Очень все разнообразно по действиям, то один формат, то другой, то названия атрибутов по разному...
Этому есть технические и исторические причины. RadioBOSS создается на протяжении 20 лет, разные люди были, зачастую команды API просто возвращают внутреннюю структуру, автоматически сконвертированную в XML. Названия полей поэтому могут быть разными. Да и сам API тоже "в возрасте", команды добавлялись на протяжении многих лет. Сейчас что-то менять уже нельзя, т.к. нужна обратная совместимость. Тут только уже делать какой-то новый API 2.0. Когда-нибудь это будет, наверное.
 
Команда имелось в виду, как делается вызов - в обновленная справка еще не опубликована, поэтому уточню здесь. В этой команде было изменение и теперь нужно добавлять параметр ...&artwork=1 чтобы в ответ была включена обложка (это сделано для экономии трафика при массовом чтении тегов, когда обложка не нужна).
Понял. Тут однозначно лайк (y)в пользу такого изменения.

Сейчас что-то менять уже нельзя, т.к. нужна обратная совместимость.
На самом деле вы можете даже в этом АПИ многое улучшить и доработать без малейшего ущерба для обратной совместимости, было бы желание.

Можно унифицировать некоторые атрибуты, например FN и FILENAME - тут можно просто там где FN добавить еще FILENAME и уже везде будет FILENAME, а если кто использует FN то все останется у него в норме. Это вообще пару минут и я бы это сделал давным давно.

Еще можно сделать некую эмуляцию нового АПИ очень просто.. добавить какой-то параметр типа newapi=1 во все действия где идет возврат xml и возвращать везде все с идентичными именами атрибутов, регистром и прочим, то есть чисто почти как новый АПИ, в который можно потом постепенно просто перейти и все, тем самым у всех будет возможность и куча времени адаптировать уже свои скрипты уже сейчас.

Но это ладно, допустим можно попыхтеть немного и через условия и т.п. вещи сделать и сейчас. Но вот чего не сделать пока и чего не хватает, так это чтоб такие действия например как получение плейлиста, trackinfo, playinfo возвращали по максимум информация сами по себе... чтоб например можно было вывести предыдущий, текущий и следующий как сейчас одним запросом сразу получив там и картинку (можно даже через доп.параметры вот как вы сделали), получив сразу по ним там рейтинг и прочее.

В общем тут было бы желание и можно подумать как чего и где..

Действие trackinfo так вообще по сути то же что и getplaylist2, при этом tarckinfo возвращает меньше данных. Я бы с него перенес параметр pos в getplaylist2, а сам trackinfo чтоб возвращал абсолютно всю инфу по любому файлу переданному в параметре и это было бы логичнее, на мой взгляд. При этом совместимость не страдает ибо просто надо кто использует действие trackinfo заменить его в скриптах на getplaylist2.
 
В общем тут было бы желание и можно подумать как чего и где..
Смысла в этом нет никакого. Возвращаемые значения известны, для каждой команды все описано, все работает - тратить время на вот такую "полировку" - пустое занятие, от которого никому никакой пользы не будет.
Только уже делать API2.0 но это будет тогда, когда в этом будет нужда, когда текущее API не будет уже решать задачи в полной мере по какой-либо причине (например, устаревший метод авторизации через GET параметр перестанет работать).
 
Назад
Верх