реализовано в транке, streamer_free кидает songchanged.

собрал 0.6-beta7.

подробности здесь

Спасібо. Проверю как будет возможность заюзать 0.6.x

лучше проверять в бетах - после релиза уже не будет возможности исправить. придется ждать следующего релиза.

нужно код собирать под i686, а с этим проблема на amd64.

попробовал скомпілять под debian wheezy.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1f3f4e0 in gdk_cairo_set_source_pixbuf () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
(gdb) bt
#0  0x00007ffff1f3f4e0 in gdk_cairo_set_source_pixbuf () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#1  0x00007ffff286a15f in draw_column_data (listview=<optimized out>, cr=0x9b92a0, it=0x77c360, group_it=<optimized out>, 
    column=<optimized out>, group_y=336, group_height=693, group_pinned=1, grp_next_y=648, x=0, y=291, width=27, height=21)
    at plcommon.c:294
#2  0x00007ffff28588c7 in ddb_listview_list_render_row_foreground (ps=ps@entry=0x97c2e0, cr=cr@entry=0x9b92a0, 
    it=it@entry=0x77c360, group_it=0x777f70, even=<optimized out>, cursor=<optimized out>, group_y=group_y@entry=336, 
    group_height=693, group_pinned=1, grp_next_y=grp_next_y@entry=648, x=<optimized out>, y=291, w=899, h=21)
    at ddblistview.c:1379
#3  0x00007ffff285a601 in ddb_listview_list_render (listview=listview@entry=0x97c2e0, cr=cr@entry=0x9b92a0, x=0, y=291, 
    w=899, h=<optimized out>) at ddblistview.c:747
#4  0x00007ffff285ad80 in ddb_listview_list_expose_event (widget=<optimized out>, event=0x7fffffff7f20, 
    user_data=<optimized out>) at ddblistview.c:881
#5  0x00007ffff2310099 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#6  0x00007ffff06f56e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x00007ffff0706750 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x00007ffff070e2db in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x00007ffff070e852 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff242793e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007ffff230ea80 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007ffff1f6346c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#13 0x00007ffff1f63413 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#14 0x00007ffff1f5e437 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#15 0x00007ffff1f605e1 in gdk_window_process_all_updates () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#16 0x00007ffff1f60649 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#17 0x00007ffff1f3e327 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#18 0x00007ffff0234355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff0234688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff0234a82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff230d797 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00007ffff283f7f7 in gtkui_thread (ctx=ctx@entry=0x0) at gtkui.c:1101
#23 0x00007ffff283fa43 in gtkui_start () at gtkui.c:1220
#24 0x00000000004034b9 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1013

как собрать portable deadbeef?

make install сделать не забыл?

как собрать portable deadbeef?

идея portable deadbeef в том, что его собирать не надо. он есть готовый на оффсайте.

инструкций по сборке у меня нет, и опубликованных тулс для этого тоже.

make install сделать не забыл?

Решил вот так (ломать инсталляцию 0.5.6 не хочу): add_pixmap_directory(«/usr/share/deadbeef/pixmaps»);

Кое-как собрал минимальную версию git/master. nullout, gtk2:

event 1004 - playing track address 0x92e8b0
event 1004 - playing track address 0x92e8b0
event 22 - playing track address 0x92e8b0
----------> нажімаю close
event 8 - playing track address 0x92e8b0
streamer_free============= (debug printf)

То есть streamer_free вызывается после событія TERMINATE (8). Фікс, похоже, не работает.

вот так даже:

gtkui plugin compiled for gtk version: 2.24.10
event 17 - playing track address 0
event 18 - playing track address 0
event 18 - playing track address 0
event 23 - playing track address 0
event 11 - playing track address 0
event 11 - playing track address 0
event 1004 - playing track address 0
event 15 - playing track address 0
event 22 - playing track address 0
event 4 - playing track address 0
event 1000 - playing track address 0x92e8b0
event 1004 - playing track address 0x92e8b0
event 1001 - playing track address 0x92e8b0
event 1004 - playing track address 0x92e8b0
event 1004 - playing track address 0x92e8b0
event 22 - playing track address 0x92e8b0
event 8 - playing track address 0x92e8b0
streamer_free=============
quitting gtk
gtkui_stop completed
gui plugin has quit; waiting for mainloop thread to finish
plug_disconnect_all
plug_unload_all

ok, спасибо за инфу. буду дальше ковырять.

глянул еще раз. да, streamer_free вызывается из обработчика TERMINATE, так и должно быть. проблема же в том, что все последующие события не рассылаются плагинам. можно сделать чтобы рассылались, надо только проверить какие от этого будут побочные эффекты.

угу, последнее что получают плагіны - TERMINATE (8).

пофиксил, пробуй, должно работать теперь. вроде ничего не вылетает.

сейчас ок. спасібо.

а когда dvdaudio будет читаться?

а когда dvdaudio будет читаться?

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

http://rutracker.org/forum/viewtopic.php?t=418372

пересобрал из гита, перестали открываться zip и rar.

пересобрал из гита, перестали открываться zip и rar.

плагин для поддержки zip: в стандартном составе ddb, и работает (использую постоянно) — ищи проблему в себе.

плагин для поддержки rar: их несколько разных, и они не входят в состав ddb. но что-то мне подсказывает, что проблема не в них.

спасиб, посмотрю когда-нибудь.

мой pkgbuild (выдержкт основные)

  
depends=('alsa-lib' 'desktop-file-utils' 'gtk2' 'hicolor-icon-theme' 'gtkglext' 'libzip') [br]
./configure --prefix=/usr \
	      --disable-ffmpeg \
	      --enable-gtk2 \
	      --disable-gtk3 \
	      --disable-static \
	      --disable-nullout \
	      --disable-oss \
	      --disable-pulse \
	      --disable-coreaudio \
	      --disable-lfm \
	      --disable-supereq \
	      --disable-sid \
	      --disable-mad \
	      --disable-vtx \
	      --disable-adplug \
	      --disable-sndfile \
	      --disable-cdda \
	      --disable-gme \
	      --disable-musepack \
	      --disable-wildmidi \
	      --disable-dca \
	      --disable-aac \
	      --disable-mms \
	      --enable-src=no \
	      --enable-vfs-zip \
	      --enable-dumb=no \
	      --enable-shn=no --enable-psf=no --enable-wma=no

что мне толку от твоего pkgbuild? предлагаешь лечить геморрой по фотографии?

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

ps: сорри за агрессивный тон, меня подобными «багрепотрами» просто забодали уже.

звиняй, ложная тревога - тупость юзера.

feature request

было бы хорошо если б в deadbeef появился logging (с его просмотром) а в plugin API появился набор функций для взаимодействия с ним. Сейчас то, что происходит внутри плагинов максимум можно писать в stdout/stderr - не каждый пользователь знает как оттуда прочитать.

это запланировано на один из релизов серии 0.6.

Позиция в плейлисте

Насколько я понял, deadbeef (0.6.0-rc1) не умеет запоминать позицию в плейлисте. При нажатии play, deadbeef начинает воспроизводить выделенный в плейлисте трек. Таким образом, при возобновлении воспроизведения после использования функции stop after current track снова повторяется текущая композиция. Foobar же сначала играет первый трек в плейлисте, независимо от выделения, а затем при возобновлении играет с того места (трека), на котором остановился. Мне это дело на багтрекере лучше оформить или так и задумано?

можно здесь, можно в багтрекере, но я нихрена не понял что не работает.

Играет какой-нить трек, нажимаю «остановить после текущей», при возобновлении воспроизведения играет не следующий трек (как в фубаре), а тот, который выделен в плейлисте.

да, после стопа всё сбивается

ага, понял, похоже на баг, проверю.

а нажимать кнопку next проблему никак не решит? я не пытаюсь полностью копировать фубар, и как по мне, нажатие PLAY по логике должно играть выделенный трек.

нажатие PLAY по логике должно играть выделенный трек

Это ок. Тогда хорошо бы было, чтобы курсор автоматом перемещался на следующий трек после срабатывания «остановить после текущего». Это удобно, когда управляешь воспроизведением с помощью хоткеев. Т.е. это обосновано тем, что, когда я снова нажму play, то ожидаю услышать следующую композицию.

Т.е. это обосновано тем, что, когда я снова нажму play, то ожидаю услышать следующую композицию.

ок. я учту, что бывает такое обоснование/ожидание, когда буду планировать следующий релиз. в данный момент, как я понимаю, вы просто можете нажать next, с тем же результатом.

track playtime

Приветствую. Вижу такую проблему:

pl_get_item_duration(track); // sample-accurate

ddb_event_trackchange_t::playtime; // inaccurate (could be longer or shorter than track duration

В результате нельзя рассчитывать на то, что playtime целиком прослушанного трека (без пауз и перемоток) совпадает с track duration. Это баг или фича?

оба значения не sample-accurate. расчитывать на то, что они сопадут до микросекунд - нельзя, т.к. у float точность ограничена. абсолютно точное время треков в сэмплах знают только плагины, декодирующие эти треки - через API эти значения недоступны.

Проблема не с float, проблема в том что playtime скорее всего берётся как разніца между двумя time() - то есть оно плавает между измерениями и не совпадает с тем что выдаёт pl_get_item_duration().

Это критично для кейса «скроблить только если 100% длины трэка проиграно». playtime может выдавать разницу вплоть до 100мс.

Example:

pl_get_item_duration() : 119000 (кажется он всегда старается округлять до целого кол-ва секунд)

event->playtime : 119072

абсолютно верно. чтобы совпадал - надо totaltime и playtime хранить в сэмплах, и пересчитывать при визуализации. такой фичи в ddb нет.

кажется он всегда старается округлять до целого кол-ва секунд

а вот это похоже на баг.

Сделай, пожалуйста, play/pause на пробел по дефолту.

не сделаю. в 0.6 можно забиндить такой хоткей.

Извини, но тугле на плей/пауз должен быть забинден по дефолту на пробел, общепринятая практика. А не на хер знает что.

3:00:00

Self five.

вступать в демагогию про общепринятые практики и прочий бред не собираюсь.

оу, я не заметил, что ты тут сморозил про разницу между двумя time(). такого нет, ессно.

playtime += (float)sz/output->fmt.samplerate/((output->fmt.bps>>3)*output->fmt.channels);

сейчас у себя не віжу такого округленія. Возможно это у меня был баг (связанный код поменял), хотя не могу понять почему.

да, еслі не делать пауз то playtime одинаковый. разница набирается на округлениях.

Фичреквест: возможность задания выравнивания для кастомных элементов интерфейса, а также вожномность менять ширину столбцов в элементе сводки о выделенной записи в плейлисте.

ни один из двух фичреквестов не понял. куда, что и зачем надо выравнивать? что такое «элемент сводки о выделенной записи в плейлисте»? это вы так «selection properties» обозвали? там ширина столбцов вполне меняется мышкой.

Под первым пунктом я подразумеваю выравнивание элемента по какому-то краю и по центру (каверарт к примеру).

Да, «свойства выделенного». Могу заверить, что столбцы упорно не хотят менять свою ширину.

Прилагается нотариально заверенный скриншот для ясности.

https://dl.dropboxusercontent.com/u/54969696/l/2013-11-15-005633_1366x768_scr...

Версия rc1, взята с SF не более часа назад.