Доброго.
Заранее извиняюсь, если про старое...
В общем, на данном плеере давно и полностью, про фубар благополучно забыл,
но иногда всё же к нему обращаться приходится.
ISO. Иногда попадаются образы, которые аплеер воспроизводит как шипение. Редко, но попадаются такие.
Фубар их играет. 
По каким законам это происходит, не понимаю.
Help.

9 часов назад, CHAY сказал:

ISO. Иногда попадаются образы, которые аплеер воспроизводит как шипение.

 

А с какими конкретно образами наблюдается эта проблема?

Да ISO, фиг знает, какие они бывают. Образы SACD. Я извлек прогой DFF, такая же ерунда как и с образом. Могу один файл прислать, может это поможет разобраться?

16 минут назад, CHAY сказал:

Могу один файл прислать, может это поможет разобраться?

Да, можно на файлообменник выложить.

Извините за ложную тревогу.
Не знаю, в чем была проблема.
Сейчас пришел, собрался заняться отправкой файла, и ещё раз всё проверил:
Скачал последнюю версию аплеер, выставил там всё как обычно (ISO, DFF и т.д.),
забросил этот образ - шипение. Забросил порезанные с этого образа DSF - шипение.
Фубар - всё играет.
Тут же снова ещё раз запустил аплеер - играет)
Может комп где-то вклинивается, раз перезапуски способны повлиять, не знаю...

У себя часто наблюдаю проблемы инициализации ASIO у АП в XP, у фу такого не наблюдается, равно как и у AudioPlayer плага в FAR. Лечится перезапуском АП.

 

 

Игорь, на всякий случай напомню про многострочный path.txt для линукс версии.


 

Изменено 28 октября, 20205 г пользователем AleXH

22 часа назад, AleXH сказал:

Игорь, на всякий случай напомню про многострочный path.txt для линукс версии.

Посмотрю в выходные.

В 28.10.2020 в 14:00, AleXH сказал:

Игорь, на всякий случай напомню про многострочный path.txt для линукс версии.

Вот консольный плеер (x64), который рассматривает многострочный path.txt как плейлист и воспроизводит его в стелс-режиме:
 

https://yadi.sk/d/1MmekPxPy406XA

Спасибо.

 

UP. В процессе эксплуатации ар замечены следующие недостатки:

1. Офиц и ласт ар не всегда правильно загружают/применяют настройки из config.dat (приоритеты процесса, конфиг ядер), если содержимое path.txt вызывает ошибку при парсинге, а порой и при правильном path.txt, но если это 1-й запуск ар. Процесс первичной настройки ар сопровождается подавляемыми ошибками?

2. Офиц читает из path.txt не строку, а до конца файла (ожидаемо), не ожидаемо - странно усекая при этом path.txt и перезаписывая его - было 745 байт, 7 строк, стало 403 байта, 4.5 строки. Т.е. парсинг path.txt неустойчив.

 

Правильно ли я понимаю алгоритм - по окончании воспроизведения трека инкрементируется номер строки (только его мы храним в памяти), и делается попытка прочитать строку с новым номером из перечитанного path.txt, если успешно - воспроизводим, если нет, то завершаем процесс? Т.е пользователь может добавлять в плейлист новые пути к музфайлам в процессе воспроизведения.



 

Изменено 2 ноября, 20205 г пользователем AleXH

5 часов назад, AleXH сказал:

Правильно ли я понимаю алгоритм - по окончании воспроизведения трека инкрементируется номер строки (только его мы храним в памяти), и делается попытка прочитать строку с новым номером из перечитанного path.txt, если успешно - воспроизводим, если нет, то завершаем процесс? Т.е пользователь может добавлять в плейлист новые пути к музфайлам в процессе воспроизведения.

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

Имхо лучше каждый раз читать построчно, отсчитывая строки считать следующую. Даже 1000 строка не вызовет ощутимой задержки, учитывая что path.txt лежит в рамфс. С другой стороны 20 треков это уже >1 часа прослушки, поэтому path.txt c >200 строк практически нереален.

 

Как вариант (необязательно), номер воспроизводимой строки и её саму можно сбрасывать в перезаписываемый curr.txt, тогда будет понятно что ап воспроизводит. Например: 1:Track01.flac

Изменено 2 ноября, 20205 г пользователем AleXH

Вот обновленный ap-playlist. Список перечитывает, curr.txt создаёт.

 

https://yadi.sk/d/tZ5VSVaR9vXfGA

Последний вариант похоже не видит path.txt и, возможно, своей папки /usr/ap, если запущен из скрипта, а не комстроки.

 

в башскрипте:

1. создаю /usr/ap/path.txt с полными путями к *.wav файлам

2. линкую ар2 в ар

3. запускаю ар

открывается интерфейс ар, вижу карта выбрана правильно, FM (в config.dat так), MMAP (в config.dat так), буфера default  (в config.dat так),  приоритеты сброшены в 0, должно быть 10 и -10, ядро не выбрано, должен быть singlecore. Ожидал запуск в стелс с воспроизведением. Ок, закрываю по х, попадаю в скрипт, выхожу из него, ls -l - я в папке /usr/ap, cмотрю path.txt - 745 байт, ар2 слинкован в ар, запускаю ар, воспроизводится 1-ый трек, затем тишина, ps показывает ар в памяти, содержание  curr.txt верное - 2:вторая строка.

 

Первый вариант треки из path.txt играл, один раз прочитать path.txt мог.

 

заменил в ар curr.txt на play.txt (нативнее), на поведении ар никак не сказалось.

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

 

Добавил перед ар установку его папки - теперь стартует в стелс воспроизводя 1-й трек, 2-й попрежнему - тишина. Это уже на стороне ар.

 

Изменено 3 ноября, 20205 г пользователем AleXH

В запускающем скрипте надо перед запуском плеера переходить в его папку. Он все файлы ищет в текущей папке.

в UP так и сделал, но 2-ой трек из path.txt - тишина, ар похоже просто висит в памяти. Но что любопытно, 2-ю строку в play.txt сохраняет, а вот со стартом её воспроизведения траблы - не из-за того же? - текущая папка не музфайла, а ар. Хотя пути к музфайлам могут быть произвольными.


 

Изменено 3 ноября, 20205 г пользователем AleXH

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

 

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

Я у себя, по крайней мере, пару строк проверял.

Изменено 3 ноября, 20205 г пользователем IgorA

Да, согласен, неразумно, в сад.

 

Если запускать из комстроки поведение такое же - 1-ый трек и тишина, процесс ар висит в памяти, play.txt содержит 2:второй трек. В первой версии треки отыгрывались, но изменения path.txt не подхватывались.


 

UP. Есть вопрос - убивая стелс ар с помощью killall ap убивается только процесс ар? - Он же в одну нить и ничего не порождает? - А как насчёт очистки использованной им памяти - всё на плечах сборщика мусора ядра? Как всё это организовано? - И Миша мне какую-то дичь втирал про демоническую природу стелс ар - это так?



 

Изменено 3 ноября, 20205 г пользователем AleXH

ap в стелс режиме в одном потоке работает, но даже если бы он создавал нити, то kill прибивает процесс целиком, с дочерними нитями. За освобождение памяти от ресурсов, занятых завершенными процессами, отвечает диспетчер памяти ядра и память должна освобождаться.

 

Что касается демонической природы, то стелс ap, действительно, запускается по правилам запуска службы (демона).

 

 

path.txtБаг парсера. в папке 5 flac + 1 cue, пути длинные. Скриптом формирую path.txt, в нём оказываются 5 полных путей к флэкам, все строки завершаются LF, в том числе и последняя, 5-ая. запускаю ар в своей папке, ар формирует play.txt и завершается, в play.txt попадает 2 байта "6:".

 

Изменено 3 ноября, 20205 г пользователем AleXH

Исправленный вариант:

 

https://yadi.sk/d/9oRldrVUM0KigA

 

Когда доиграет и завершится, в play.txt  запишет closed.

Стартует со 2-го трека, а не с 1-го, после его проигрывания тишина, ар в памяти висит.

Имхо вместо записи closed лучше переименовывать play.txt => stop.txt, тогда будет видно на каком треке остановился.

Не догадался проверить нормально ли в интерфейсе треки отыгрывает, офиц отыгрывает, месяц назад слушал.
UP. Подозреваю дело в UTF8 символах типографских кавычек.




 

Изменено 3 ноября, 20205 г пользователем AleXH

Пути в многострочный path.txt надо записывать вообще без кавычек, даже когда там  пробелы и кириллица.

это типографские, юникодные кавычки внутри пути. Чего только юзвери не суют в пути - юникодные кружочки, звёздочки - горе-дизайнеры. Это ещё на иероглифах не тестировал ;-)

 

Изменено 3 ноября, 20205 г пользователем AleXH

Если они  записываются в path.txt без перекодировки, как они есть в имени файла, то мешать не должны. Проверьте, как в остальном, с обычными именами файлов без типографских кавычек.

сейчас гляну - посмотрел, отыгрывает 1-ый трек, затем тишина, но в имени 1-го трека есть одинарные ascii кавычки ))) Во 2-ом есть обычные ascii круглые скобки.

Рекодинга нет, выше есть path.txt, в нём видно, что только кавычки 2-х байтовые, остальное ascii, FAR открывает в редакторе как UTF-8, отображает корректно.

 

Пути грабятся и составляются через слэш из $(ls -pL "$path") как есть, а поскольку разделы NTFS, то UTF-8.

 

Завтра могу попробовать создать:

/media/sdd2/test/1.wav
/media/sdd2/test/2.wav
/media/sdd2/test/3.wav
и посмотреть,будут ли отыгрываться 2-ой и 3-й треки.

 

Кстати, все пути к музфайлам замечательно передаются в качестве аргумента ap "$path", но не забываем отыгрывается-то только 1 файл, поэтому возможно проблема есть и в этом случае, просто до неё дело не доходит.

UP.  Проверил на тесте выше - без изменений, отыгрывает только 1 трек, затем тишина.

Какими у стелс-ар должны быть права? У меня он создаёт devtmpfs, mode=0755

 

Проверил test с ascii <80h путями на 1-ой версии - весь плейлист отыгран, процесс ар завершён, но тест с юникодными кавычками провален.
 

Изменено 4 ноября, 20205 г пользователем AleXH