"Magellan - Amarok 2.0.1.1 released (http://amarok.kde.org/en/releases/2.0.1.1)" - вышел Amarok 2.0.1.1 с реализацией нескольких новшеств, исправлением ошибок и устранением проблемы безопасности.Из новшеств можно отметить функции поиска и фильтрации содержимого плейлистов, возможность автоматического восстановления целостности встроенной MySQL базы, оптимизацию потребления памяти и т.д.
URL: http://amarok.kde.org/en/releases/2.0.1.1
Новость: http://www.opennet.me/opennews/art.shtml?num=19734
зря они встроили базу
>зря они встроили базуАргументируйте...
>Аргументируйте...Sqlite по объему кода AFAIK сильно компактнее (~300Kb на все как я помню) и по потреблению памяти не злобный.И к разрушениям не особо склонен by design - задуман как необслуживаемый.И лично мне его хватало за глаза под все мои нужды по части амарока.Зачем надо было впендюривать более толстый мускуль - для меня не очевидно.По-моему для ПЛЕЕРА и sqlite то огого с каким запасом.Это ж плеер, с одним юзером как правило.А не супер-дупер сервер БД.SQL там вообще извините, навороты...
Скажи спасибо, что на орокловый кластер его RAC-ом не завязали. "Производительность же сейчас копейки стоит", да только забывают горе-разработчики, что производительность эта не по их дурную голову, а под выполняемые задачи.
MySQL база дает значительный прирост производительности при библиотеках музыки размером в десятки тире сотни гигов.
А по поводу рекавэри - дык оно и для sqlite нужно, если база повредилать.
>MySQL база дает значительный прирост производительности при библиотеках музыки
>размером в десятки тире сотни гигов.ппц что за бред? нахрен мне библиотеки в сотни гигов?
я хочу два раза клацнуть по файлу и чтобы он тут же начал играться, без тормозов и заиканий. плеер должен незаметно висеть в трее или показывать прикольную визуализацию в такт музыке. вот это, млядь, и есть хороший плеер. а неюзабельное убожище быстро решительно отправляется фтопку.
>>MySQL база дает значительный прирост производительности при библиотеках музыки
>>размером в десятки тире сотни гигов.
>
>ппц что за бред? нахрен мне библиотеки в сотни гигов?
>я хочу два раза клацнуть по файлу и чтобы он тут же
>начал играться, без тормозов и заиканий. плеер должен незаметно висеть в
>трее или показывать прикольную визуализацию в такт музыке. вот это, млядь,
>и есть хороший плеер. а неюзабельное убожище быстро решительно отправляется фтопку.
>Зачем тебе Amarok, тогда, если тебе просто чтобы играло и визаулизацию крутило?
Мне, вот, удобнее, когда есть средства для организации коллекции и быстрому поиску по ней. Лирика, Вики и другие сервисы мне тоже интересны. "Rediscover your music" не совсем тождественно "Click file and we'll play it for you", в конце концов.
Про базу -- у меня пока нет сформировавшегося мнения, к сожалению.. С одной стороны -- в KDE вообще была идея "одной базы на всех" (Akonadi, или что-то в этом роде). Ан нет:
- Amarok -- MySQL
- DigiKam -- SQLLiteКто еще чего привнесет? ;-)
>Зачем тебе Amarok, тогда, если тебе просто чтобы играло и визаулизацию крутило?никто и не отрицает, что amarok - хороший каталогизатор.
а музыку, пардон, слушать в чем? допустим, рядовой юзер, не адепт qt, может себе позволить запихнуть в ось и глибу, и моно. ну так и что, есть другие варианты нормальных легковесных плееров с гуем?
блин, может хоть к vlc получится приделать нормальный плейлист.
>Зачем тебе Amarok, тогда, если тебе просто чтобы играло и визаулизацию крутило?Если вы такой умный - придумайте разумный сценарий под которой sqlite не хватит.Не забывая про чижика с sql.ru который 20 гиговую базу в sqlite в продакшне содержит без особых проблем.Если у меня только база коллекции станет порядка несколько гигов - сколько же весит сама коллекция?По-моему чтобы базу настолько отрастить - надо индексировать все mp3 интернета в ней.Никак не меньше.И проблем я вот чесслово не испытывал.С несколькими тысячами наименований.В результате более жирный мускуль просто не выглядит оправданым для ВСЕГО ЛИШЬ ПЛЕЕРА.Это не гугл, мля.Там и sqlite то с пятерным запасом было(тем более что при грамотном юзеже sqlite сливать мускулю как-то ни разу не собирается как-бы).
>[оверквотинг удален]
>Если вы такой умный - придумайте разумный сценарий под которой sqlite не
>хватит.Не забывая про чижика с sql.ru который 20 гиговую базу в
>sqlite в продакшне содержит без особых проблем.Если у меня только база
>коллекции станет порядка несколько гигов - сколько же весит сама коллекция?По-моему
>чтобы базу настолько отрастить - надо индексировать все mp3 интернета в
>ней.Никак не меньше.И проблем я вот чесслово не испытывал.С несколькими тысячами
>наименований.В результате более жирный мускуль просто не выглядит оправданым для ВСЕГО
>ЛИШЬ ПЛЕЕРА.Это не гугл, мля.Там и sqlite то с пятерным запасом
>было(тем более что при грамотном юзеже sqlite сливать мускулю как-то ни
>разу не собирается как-бы).Вот тут все по полочкам:
http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-Th...В частности (да простят мне вольный перевод; кому не нравится -- линк на оригинал выше):
Проблема 1: производительность. SQLite достаточно производительная при небольших коллекциях. Но те из пользователей больших коллекций, которые не поленились опробовать MySQL, либо Postgre SQL (в первом амароке), сообщали об огромном (enormous) увеличении производительности при выполнении сложных и/или множественных запросов, таких как:
- добавление множества пунктов в список воспроизведения
- сканирование файлов
- фильтрация/поиск в коллекции.Так как нашей цельню является удовлетворение потребностей пользователей больших коллекций, ровно так же как и пользователей с небольшими, и т.к. архивы цифровой музыки как правило *не становятся меньше*, увеличение скорости для пользователей с большими архивами является очень важной задачей.
Многие наши программисты, после перехода на mysqle (так мы ее называем, хоть это и не официальное обозначение), тоже заметили значительное ускорение при ежедневном использовании Amarok 2. Т.е., встроенное решение вполне себе заменяет отдельный MySQL сервер.
Проблема 2: назначение SQLite (поговорим об универсальности). Многие пользователи (включая меня) имеют несколько компьютеров, подключеных к одной базе Amarok'а. Предполагая что все компьютеры имеют доступ к музыке, расположенной в одной и той же точке монтирования (также имеются еще несколько правильных настроек), у вас появляется возможность сканировать единожды, проигрывать везде, обновлять рейтинги, етц - и все будет фиксироваться в одном месте. Даже если не стоит задача расшариваеть БД для нескольких компьютеров, многие пользователи все-равно хотят иметь БД на определенном сервере из соображений скорости, безопасности и более централизованного резервного архивирования. Если вы считаете что все вышеперечисленное не является распространенным, вы несколько ошибаетесь. MySQL и PostgreSQL всегда прекрасно спавлялись с подобными примерами использования. SQLite же полностью исключает их, т.к. была разработана для других целей.
Т.о., у SQLite уже два минуса.
Но, также как мы не можем полагаться на пользователя, что он в состоянии правильно настроить Strigi/Nepomuk, мы не можем полагаться и на то, что он справится с настройками MySQL или PostgreSQL. Т.о., нам нужно встроенное решение, которое будет "просто работать". Для MySQL такая возможность имеется (некоторые начинания есть уже в v4.1.x; полная поддержка ожидается к 5.1 (AFAIK)). У PostgreSQL подобных решений нет вообще (хотя имеется интересный концепт).Так что мы остаемся с -- как вы могли догадаться -- MySQL. Это может не быть любимой ДБ каждого (хотя для многих - она такой является), и я даже не знаю сколько скрытых проблем во встраиваемое реализации данной ДБ, но она удовлетворяет основным требованиям. Он может быть как втроенной, так и доступной по сети (да, на данный момент нет такой возможности в Amarok 2, но она появится). Она достаточно производительная для больших коллекций. И, самое главное, она позволяет использовать один backend, который будет удовлетворять все наши требования.
Если вы все еще недовольны нашим решениям, я прошу прощения. Мы пытаемся удовлетворить больгинство, но мы не можем удовлетворить каждого. Также, мы те, кто разрабатывает и поддерживает данное приложение, и поэтому мы делали выбор не только на основании коллективных отзывов тысяч пользователей, но и для собственного удобства в том числе. Пожелуйста помните, что даже если большинство комментов к этой статье будет содержать негативные отзывы, на самом деле данное решение удовлетворит подавляющее большинство наших пользователей намного лучше, чем любое из тех, которые мы могли бы использовать на данный момент.
>MySQL база дает значительный прирост производительности при библиотеках музыки размером в десятки
>тире сотни гигов.Я не заметил никаких проблем с производительностью в амароке при [скольких-то] гигах.Несколько тысяч наименований.Зачем чинить то что не сломано?Может еще туда оракловую базу впендюрить?Или постгра?На супер-больших базах в десятки-сотни гигов дескать быстрее будет.Вот только плэйлист ну ниак не катит на супер-большую базу а у sqlite строго говоря НЕТ никаких проблем с производительностью.Отдельные фрукты на sqlite такие базы вбубенивают что невольно про постгра и оракла вспомнишь.Более того - на том же sql.ru один субъект утверждал что заменив мускуль на sqlite на базе гиг в 20 (а тестировал он до ~100Gb если не вру) еще и в скорости выиграл.Но субъект натурально разбирается в том как sqlite работает и как его юзеж оптимизировать.Напрашивается вывод что разработчики Amarok просто не ахти какие спецы в SQL и решили сделать как им было проще.А то что плеер еще распухнет - ну и фиг с ним дескать.Мне это не нравится: хотя ресурсов нынче дофига - это не значит что плеер должен их резко захавать в одно рыло.А когда в системе запущен с десяток увесистых программ - ресурсов как-то уже и не кажется дофига и дарить вагон оных всего лишь плееру совсем не хочется.
>MySQL база дает значительный прирост производительности при библиотеках музыки размером в десятки
>тире сотни гигов.А вот на sql.ru народ утверждает что перешли с мускуля на sqlite да еще и выиграли в разы.Если с умом sqlite поюзать.Если разработчики амарока вместо того чтобы твкнуть работу движка под задачу просто ставят другой - ну ой.Видимо надеяться на то что он станет легче не стоит - они тогда при случае еще и оракл прикрутят (у него фич больше и вообще, вдруг кто захочет заиндексить *.mp3 интернета?!).Ну и кластер под все это потребуют, никак не меньше.
Хрен с ней, с базой. Пусть вернут визуализацию и эквалайзер.
вот чего я ждал:
- Queue track functionality has returned.
- Add "Stop after track" option to the playlist menu.вот чего недостает:
- кнопок в тулбаре для управления очередью (рандом, репид)
- каие небудь средсва для управления позицией и размерами виджетови еще, кажется у плеера какие-то проблемы с IDv2 или с IDv3, не уточнял
но у некоторих трэков не отображается заголовок/исполнитель хотя в первом амароке отображались нормально
>у некоторих трэков не отображается заголовок/исполнитель хотя в первом амароке отображались
>нормальноДа, раздражает.
Не хватает нормального плейлиста, чтобы можно было сортировать по колонкам типа год, альбом, исполнитель
>Не хватает нормального плейлиста, чтобы можно было сортировать по колонкам типа год,
>альбом, исполнительБудет в 2.1
Закапывайте... И ставьте mpd+sonata. Или mpd+ario.
mocp однозначно
user@home:~$ ps aux | grep mocp
user 8065 0.1 0.2 12968 1360 pts/1 S+ Jan11 1:27 mocp
после амарока - самое то
>mocp однозначно
>user@home:~$ ps aux | grep mocp
>user 8065 0.1 0.2
>12968 1360 pts/1 S+ Jan11
> 1:27 mocp
>после амарока - самое тоncmpc меньше жрет, после амарока самое оно. Только этим на работе и пользуюсь.
[usr@home ~]$ ps aux | grep ncmpc
user 30720 0.0 0.0 4120 696 pts/14 S+ 18:40 0:00 grep ncmpcp
Может кто порекомендует mp3-плеер, желательно для kde.
Требования:
- основной интерфейс представляет из себя плейлист,
- одноклавишные, либо перенастраиваемые хоткеи для управления воспроизведением (play,pause,track back,track forward)
- хорошие возможности сортировки плейлиста (по полному пути, например).
Может быть амарок и поискать какие то скрипты к нему?
В свете того, куда развивается и без того нерезвый амарок - его мне и не надо, есть уже оно у меня. Хочется чего-то вроде плейлиста от winamp или foobar2000.
>В свете того, куда развивается и без того нерезвый амарок - его
>мне и не надо, есть уже оно у меня. Хочется чего-то
>вроде плейлиста от winamp или foobar2000.Во-во, хочется чего-то такого же.Таковым мог бы быть XMMS но он написан на антикварном первом GTK (диалогами открытия файлов в оном можно детей пугать!) и по сути помер.Есть что-то лучше?
mpd+ncmpc
А что-нить графическое? XXI-ый век ж на дворе.
он аудиосд проигрыватьто научился или придется третьего ждать? :(
Который там хотел кликнуть по песне и проиграть её - ну так выбери при создании коллекции sqlite! Не отмечай ни одной галочки при импорте музыки! И вообще, юзай XMMS или запусти WinAMP 2.8 или WMP9.0 под Wine. Тебе надо двумя кликами запускать песню - молодец! А ты не подумал, что остальные не такие, как ты сам? Не надо путать своё мировоззрение с окружающей тебя действительностью. Лично у меня 49 гигабайтов музыки, и причём ни одной песни рэп... ;-)
>Который там хотел кликнуть по песне и проиграть еёи тебе привет.
>запусти WinAMP 2.8 или WMP9.0 под Wine
лучше я запущу foobar под winxp
>А ты не подумал, что остальные не такие, как ты сам?
я кагбэ смотрю по сторонам и вижу, что фактически всем хочется, чтобы плеер играл музыку. да, вот так просто: нажали на кнопочку - и звучит музыка. и никому нет дела, какой там максимальный объем плейлиста у плеера, потому что это дело десятое. главное - удобство в использовании.
>Не надо путать своё мировоззрение с окружающей тебя действительностью.
это скорее к разработчикам амарока
>Лично у меня 49 гигабайтов музыки
у меня приблизительно столько же. winamp справляется, foobar не виснет, wmp наверное тоже не подавится.
amarok чёто там оптимизируют-оптимизируют, а он жрет всё больше и больше.p.s. заранее предупреждаю: не надо брызгать слюной по поводу некрософта. я говорю о продукте, а не о платформе.
Ну так используй как тебе удобно. Сначала создаёшь коллекцию, а потом удивляешься, а зачем вообще коллекция, раз ты и так все пути к файлам помнишь... И куда ресурсы делись... Тебе не кажется, что кто-то не помнит все пути к файлам в своей коллекции музыки и вообще не заморачивается, ему главное песни в такт к настроению, а не помнить, где нужные файлы. Ему и нужна библиотека. Кому-то удобней amaroK с Sqlite, кому-то приятней с MySQL (как было сказано, если библиотека большая), а кому-то вообще без библиотеки. Сними галочки с директорий поиска файлов и обнови библиотеку. Вот тебе и твоя производительность и "клик по файлу - песня немедленно играет". А лучше установи XMMS. То что надо! Только в iPod песни в таком случае сам вкидывай, песенки сам сортируй по папочкам (именно папочкам, а не директориям - тебе же нравится винда...), а не доверяй всё это плееру. Сам рипай песенки с дисков отдельной программой, а не сразу, и перевводи названия песен в тэги тоже сам. Если тебе это нравится. Поностальгируй по жизни в XX веке... Да, и обложки альбомов сам сканируй. Как в амароке их вообще отключить?! А цивилизованные люди в это время просто запустят амарок, проиндексируют директории, и двумя кликами будут играть песни, обновлять айпод и рипать диски с подстановкой названий песен из Интернета. Глазей-глазей по сторонам - ты заметишь только таких, как ты сам и будешь считать, что как удобно тебе, так удобно и всем, и никак иначе.
А по-твоему, Амарок не играет музыку? Я же говорю, удали библиотеку и он станет обычным винампом раз тебе с ней не удобно, её же не принудительно включают.
>все пути к файлам помнишьнахрен их помнить? вставил диск и слушай
>лучше установи XMMS
если xmms не был ещё большим говном, чем amarok, то я бы юзал xmms
>Сам рипай песенки с дисков отдельной программой, а не сразу
ты рипаешь диски в плеере ???
только на торренты, пожалуйста, это не выкладывай.>перевводи названия песен в тэги тоже сам
ах да, amarok уже научился другим кодировкам, кроме уникода?
>обложки альбомов сам сканируй
твой амарок умеет сканировать обложки?
>удали библиотеку и он станет обычным винампом
если из амарока удалить библиотеку, он станет никому не нужным унылым говном. потому что главная фича в этом разжиревшем поделии - функциональность каталогизатора. я понимаю, часть линуксоидов никогда не юзали нативного тунца, а винамп оценивают по древнему клону в виде xmms.
Винамп оценивают по винампу. Я так понимаю, твоя жалоба выглядит так:
Зачем они ваще библиотеку сделали? Это же так неудобно!
А тебе говорю - отключи. А ты: зачем, это же главная фича...
Пути к файлам на диске тогда.А если аудио-CD,то amaroK сам скачает названия песен и обложку альбома и покажет их.Это сделает любой плеер.
Спрашивается, а какую кодировку тебе нужно? windows-1251? Чтобы развеять твою уверенность, скажу. Даже в винде давно уже юникод. По всем софтовым сайтам для винды распространяются и активно скачиваются программы для перевода тэгов песни или целых библиотек из windows-1251 и KOI8-R (автоматическое определение) в Юникод. Дал бы ссылку на один сайт,где есть инструкция с картинками, но пишу с телефона...
Чем тебе не нравится рипы, сделанные амароК'ом и Konqueror'ом? Тэги нынче популярны в Юникоде, качество отличное. На формат людям пофигу, например, на дарксайд.томск.ру около трети коллекции в ogg (примерно сто двадцать гигабайт). А на торрентах обычно есть отдел "Музыка без потери качества" для FLAC. Присмотрись. Или тебе не нравится то, как amaroK делает MP3 кодеком lame? Пользователи Windows тоже делают это lame'ом, если ты не знаешь... Он входит в K-Lite Codec Pack. WinAmp тоже не умеет сканировать обложки, и никакая связаная с музыкой программа не умеет.
Я не понимаю твоей проблемы. По-твоему, коллекция тормозит и вообще не нужна, так как нужен лишь плейлист и красивая визуализация. Причём не только тебе, а вообще всем. Отключать ты её отказываешься. Может, где-то коллекция создаётся быстрее и имеет такой же или более крутой функционал?