LINUX.ORG.RU

Сообщения SkyMaverick

 

DEADBEEF добавление нового плагина в builder с кастомными библиотеками

Форум — Talks

cast @waker

Появилось время, допилил плагин SNI (ссылку даю на свою репу, потом запатчу оригинальную). Т.к., как я понял, добавлять в static-deps библиотеку libdbusmenu считается проблематичным и нецелесообразным, то я сделал небольшой манёвр

  • сделал с ней бандл (в репе каталог bundle)
  • в процессе сборки он там же распаковывается и пути добавляются пути сборки линковки для GCC
  • (!пункт к которому у меня вопрос) на завершающем этапе сборки информации о библиотеке, как я понял, LD_LIBRARY_PATH не подставишь, поэтому я делаю симлинк прямо в каталог static-deps
PATH_BUNDLE ?= bundle
FILE_BUNDLE ?= $(PATH_BUNDLE)/bundle.tar.xz
FILE_DBUS_LIBRARY = $(PATH_BUNDLE)/libdbusmenu-glib.so.4
PATH_STATIC_DEPS = $(LIBDIR)/gtk-3.10.8/lib

all: deps gtk3
deps: $(abspath $(FILE_BUNDLE))
	@tar -xvf $^ -C $(abspath $(PATH_BUNDLE)) && ln -s $(abspath $(FILE_DBUS_LIBRARY)) $(PATH_STATIC_DEPS)

Вопрос: так можно делать, или это не считается правильным?

В остальном всё нормально собирается (gtk3-версия). Вроде-бы нормально работает (проверял последнюю Plasma, GNOME3/40, XFCE, Cinnamon) и как добавлять в DPB, в целом, понятно. Я попробую это сделать, если такой подход не является проблемой. Сейчас собирается так (docker): manifest.json, make.patch.

Собрать gtk2 версию в билдере не получится, потому что нужен GVariant, который ЕМНИП только с glib >=2.24, а в билдере для gtk2 только 2.16.

 

SkyMaverick ()

Как в DeaDBeeF надёжно отследить статус воспроизведеия при запуске

Форум — Talks

cast @waker

Допиливаю по-немногу SNI-плагин. Более-менее всё починил, но возник один затык, который не могу придумать, как решить (туплю) - как гарантированно отследить статус плеера при его запуске.

В данный момент отслеживаются ссобщения DB_EV_PAUSED и DB_EV_SONGCHANGED (если to == NULL - это стоп, иначе - плей) и это замечательно работает в обычном режиме. Проблема заключается в том что:

  • StatusNotifier инициализируется независимо от плеера и может проинициализироваться в произвольное время при запуске (для этого есть ожидание в отдельном потоке callback_wait_notifier_register (здесь), пока просто активное ожидание playback-а)
  • определение состояния через
DB_output_t* out = deadbeef->get_output();
switch (out->state()) {
    ...
}

сопряжено с трудностями, т.к. StatusNotifier может загрузиться слишком рано и получается мусор в out->state() (мусор - частично решено функцией playback_state_active_waiting) или при вызове в момент загрузки трека (подгрузки coverart или ещё чего) получается DDB_PLAYBACK_STATUS_STOP, а сообщения о готовности трека не предусмотрено.

  • определение через таймер, как делаю сейчас, в принципе, работает хорошо (пока ещё код на уровне идеи, но работает), но тут возникает проблема, что при запуске порядок сообщений выглядит таким образом (лог при помощи моего простенького отладочного плагина)
[MSG (16:21:23.495064159)] DB_EV_SONGCHANGED (1000) <0x7ffae8000c20,0,0> | from: [(nil)], to: [0x14b7360], sec: [0.000]
[MSG (16:21:23.495077924)] DB_EV_SONGSTARTED (1001) <0x7ffae8000c50,0,0> | from: [0x14b7360]
[MSG (16:21:23.495086305)] DB_EV_PAUSED (14) <(nil),1,0> | сhange: [paused]
[MSG (16:21:23.495123667)] DB_EV_CONFIGCHANGED (11) <(nil),0,0>
[MSG (16:21:23.497253534)] DB_EV_SONGCHANGED (1000) <0x7ffae8011e50,0,0> | from: [(nil)], to: [0x14b7360], sec: [0.000]
[MSG (16:21:23.497287863)] DB_EV_SONGSTARTED (1001) <0x7ffae8011e80,0,0> | from: [0x14b7360]
[MSG (16:21:23.497303655)] DB_EV_SEEKED (1005) <0x7ffae8011eb0,0,0> | from: [0x14b7360], position: [41.982]

т.е. сообщение DB_EV_SONGCHANGED приходит почему-то два раза (почему???) и после паузы тоже. Поэтому, по логике обработки сообщений, которая на данный момент используется, получается что после PAUSED пришло сразу сообщение SONGCHANGED и воспроизведение запущено.

Пока больше не могу придумать, как правильно при запуске notifier-а понять в каком состоянии его запускать, т.е. отследить в каком состоянии находится плеер на момент загрузки notifier-a (возможно, что воспроизведение уже запустили вручную, пока notifier грузился). Как я понимаю, в случае, например, больших coverart-ов состояние DDB_PLAYBACK_STATUS_STOP может продлиться довольно долго и условный sleep(какое-то время) не поможет.

Каким более правильным образом можете посоветовать решить проблему? Потому что у меня кроме как вариантов убрать, каким-то образом, второе сообщение SONGCHANGED на уровне ядра плеера или добавить какой-нибудь EVENT фактического старта воспроизведения / готовности трека (что решило бы все проблемы), опять же на уровне ядра плеера, не возникает.

ЗЫ. issue на github не создаю, потому что какбы и не баг, вроде бы, а просто мой тупизм и я что-то не понимаю.

 ,

SkyMaverick ()

RSS подписка на новые темы