Проигрыватель музыки

Clementine

MOCP

MOCP

Пошёл вон, позёр.

Cmus.

</thread>

Попробуй все, которые знаешь и/или сможешь нагуглить. // использую deadbeef

Консольный треш сразу можно выкинуть. Это только школоте понтоваться.

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

Это только MPD :3

DeadBeef

xmms2

Что ни клиент, то либо сегфолтится по настроению, либо по функциям не дотягивает даже до pygmy. Убожество как оно есть. Добавим сюда тормозную базу в совершенно непригодном для фонотеки формате :-/

базу не использую (кстати, а чем sqlite хуже, чем свой велосипед?) - у меня «хорошо лежат», родной консольный клиент работает без нареканий (с автодополнением в zsh всё вообще ок), с гуями, да, проблематично, я всё думал взяться за lxmusic (как самый непадучий и больше всего похожий на мои представления о юзабельном аудиоплеере) и довести до ума, но пока руки не доходят (как обычно, ага).

Но сам плеер, как по мне, в сумме заруливает mpd (для десктопа, не для сервера).

Собственно, я mpd выбросил, когда увидел, что мне нужно за каким-то фигом запускать демон отдельно (клиенты этого не делают), плюс тогда он не умел играть файлы без добавления базы. Может сейчас ситуация поменялась, но впечатление было испорчено. А xmms2 сразу заработал как хотелось, что называется, искаропки.

Отказался от mpd + gmpc в пользу Clementine. Доволен, плеер очень удобный. Хорошо работает с тегами из коробки, удобно просматривать коллекцию. В отличие от exaile - не тормозит.

кстати, а чем sqlite хуже, чем свой велосипед?

Он плохо подхоит для большого количества записей. На примере Firefox это можно хорошо ощутить :)))

lxmusic

Вот этот да, кривоват, но на фоне прочих хоть как-то напоминает конечный продукт.

запускать демон отдельно

Надуманная проблема. Реальная проблема — необходимость этот демон явно останавливать при logout.

у меня «хорошо лежат»

У меня тоже, но искать-то иногда нужно.

deadbeef-qt

На примере Firefox это можно хорошо ощутить

у меня костыльная джампилка по хистори на sqlite3 | dmenu работает практически моментально даже на атомном нетбуке, так что тормозит фокс вовсе не из-за базы :)

Вот этот да, кривоват, но на фоне прочих хоть как-то напоминает конечный продукт.

угу, такое впечатление, что аффтар задался целью нарушить все существующие HIG-и

необходимость этот демон явно останавливать при logout.

а зачем?

кстати, о костылях :)

updatedb -l 0 -o collection.db -U /path/to/music/files/

locate -d collection.db Dethklok

deadbeef-qt

Он и на куте уже? Хотеть.

Самый удобный - MOCP Самый функциональный - Amarok

тормозит фокс вовсе не из-за базы

Нет, просто масштаб не тот. Десяток тысяч записей с десятком полей не проблема, а вот попробуйте в FF сделать выборку в истории на 100-200 тысяч записей и нажать Del — слайдшоу на несколько минут с периодическими вопросами лисы «точно продолжить выполнение скрипта? (о.О)» гарантировано. Хотя да, JS тут тоже способствует.

а зачем?

Не даёт сделать вручную umount /home. При этом не отражается в зеркалахlsof и fuser.

Мне нужна не скорость, а метаданные. Название трека я и через find найду, но жанр уже никак.

Почему вы все против mocp?!!!!

Нет, просто масштаб не тот.

как не тот? я делаю выборку именно из фоксовской (ну, точнее, conkeror-овской, хотя xul и база те же) истории. Так что основные тормоза именно из-за js-а.

Не даёт сделать вручную umount /home.

хмм, а это зачем?

хмм, а это зачем?

Иногда бывает нужно. И вообще, если реальный (не системный) пользователь не залогинен, то и процессов, запущенных от его имени быть не должно.

mpg123

gmusicbrowser, конечно же

Есть ещё rhythmbox, banshee moc, mplayer, aplay… Вам чего от плеера надо-то, кроме как музыку играть?

gmusicbrowser

Давненько. В генту по крайней мере (stuff).

И вообще, если реальный (не системный) пользователь не залогинен, то и процессов, запущенных от его имени быть не должно.

Надуманная проблема. Реальная проблема — необходимость этот демон явно останавливать при logout.

Это тоже надуманная проблема, потому что systemd умеет убивать процессы, запущенные в сессии, при её завершении.

Это тоже надуманная проблема, потому что systemd умеет убивать процессы, запущенные в сессии, при её завершении.

Есть более элегантные решения :)

Есть более элегантные решения :)

Сомневаюсь. Особенно в их надёжности.

Deadbeef

mpd

Почему вы сомневаетесь в надёжности Xreset и logout-скриптов шеллов?

Лол, нормальные люди поставили себе Clementine и слушают музыку, а пользователи консольных недоплееров до сих пор костыли обсуждают.

Почему вы сомневаетесь в надёжности Xreset и logout-скриптов шеллов?

Ненадёжны они, потому что не выполнятся. Например, если xinit или DM (или что там будет запускать этот Xreset) будут убиты SIGKILL (например, OOM-killer'ом; возможно, даже SIGKILL не обязателен, а хватит SIGTERM или SIGHUP — например, остановка DM администратором), то эти скрипты точно не выполнятся. И да, не понимаю, при чём тут logout-скрипт шелла.

Далее, с точки зрения практической пригодности этого способа: что вы напишете в эти скрипты? killall mpd? И какое это отношение будет иметь к сессии пользователя? Юзер мог залогиниться 2 раза и запустить 2 mpd из-под разных сессий, а убиты должны быть только те mpd, которые запущены в завершающейся сессии. Поэтому это не решение, а в скрипте придётся среди всех mpd выбирать те, которые относятся к нужной сессии, и убивать их. А для этого нужен systemd-logind или ConsoleKit (насчёт последнего не уверен, что он такое умеет). Но т.к. для этого всё равно нужен systemd-logind, а он и сам умеет убивать нужные процессы при завершении сессии, то необходимость в скрипте плавно отпадает.

То, что я сказал, можно отнести к любому процессу, а не только к mpd.

Ненадёжны они, потому что не выполнятся. Например, если xinit или DM (или что там будет запускать этот Xreset) будут убиты SIGKILL (например, OOM-killer'ом; возможно, даже SIGKILL не обязателен, а хватит SIGTERM или SIGHUP — например, остановка DM администратором), то эти скрипты точно не выполнятся

Да.

И да, не понимаю, при чём тут logout-скрипт шелла.

При том, что не все пользуются DM.

Далее, с точки зрения практической пригодности этого способа: что вы напишете в эти скрипты? killall mpd?

Ну, если вы хотите рассмотреть именно MPD, то я туда напишу mpd --kill, который сверяется с pid-файлом :)

И какое это отношение будет иметь к сессии пользователя? Юзер мог залогиниться 2 раза и запустить 2 mpd из-под разных сессий, а убиты должны быть только те mpd, которые запущены в завершающейся сессии.

Если он их запустил корректно, с разными сокетами/портами и pid-файлами, то, очевидно, всё будет хорошо. Если некорректно, то убивать надо все копии, потому что это не является нормальным режимом работы MPD. У меня он запускался с проверкой на предмет наличия уже запущенных экземпляров.

А для этого нужен systemd-logind

А каким образом оно определяет принадлежность к конкретной сессии процессов, не имеющих управляющего терминала?

То, что я сказал, можно отнести к любому процессу, а не только к mpd.

Де-факто, о нескольких демонах позаботиться несложно. Остальные же являются X-клиентами и/или дочерними процессами логин-шелла, поэтому разуплотнятся автоматически при любом сценарии завершения сессии. А если не разуплотнятся, то это наверняка уже зомби, с которыми возиться бессмысленно.

А каким образом оно определяет принадлежность к конкретной сессии процессов, не имеющих управляющего терминала?

Оно использует только cgroups для определения принадлежности процессов к сессиям. Наглядно увидеть это можно, например, в /sys/fs/cgroup/systemd/user/$USER/$SESSION/tasks.

Ну, если вы хотите рассмотреть именно MPD, то я туда напишу mpd --kill, который сверяется с pid-файлом :)

PID-файлы ненадёжны. Если даже не говорить о том, что приложение никак не может его предохранить от перезаписи и удаления, то всё равно остаются проблемы. Если PID-файл лежит в /tmp, то он может пропасть в любой момент, потому что /tmp может быть очищено когда угодно. В /run обычные пользователи писать не могут (/run/user/* появилось не так давно, и ещё почти ничем не используется). Если он лежит в другом месте, то там может остаться содержимое с прошлой загрузки, поэтому может быть убит произвольный процесс.

Де-факто, о нескольких демонах позаботиться несложно.

Вот именно, нужно для каждого демона писать разные костыли. Если добавляется ещё один демон, то каждому пользователю нужно будет дописать скрипт, чтобы он убивал и новый демон тоже. А с systemd-logind всё проще: нужно один раз настроить PAM и забыть, потом всё просто работает.

Оно использует только cgroups для определения принадлежности процессов к сессиям.

Ну ладно.

Если PID-файл лежит

У меня они лежали в домашнем каталоге, никаких проблем.

Вот именно, нужно для каждого демона писать разные костыли.

Это не костыли, это precise control :-\

А с systemd-logind всё проще: нужно один раз настроить PAM и забыть, потом всё просто работает.

В systemd много чего просто не работает. Так что спасибо, обойдусь технологиями каменного века — они не имеют свойства разваливаться на ходу :)

У меня они лежали в домашнем каталоге, никаких проблем.

gentoo_root

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

Например, такой сценарий: аварийное завершение, pid-файл не удалился, при следующей загрузке mpd не стартует (например, он обновлялся во время аварийного завершения), остаётся старый pid-файл от предыдущей загрузки, при mpd --kill убивается левый процесс.

DeaDBeef is the best. Но лучше, конечно, поставить несколько и попробовать.