Поиск по метке: Linux

Столкнулся с неожиданной для себя проблемой. Сборка проекта под Windows шла криво, в то время как под Linux без проблем. Вначале грешил на обратные и прямые слеши (/ & \). Беглый поиск по этой проблематике дал мне понять, что никаких проблем с unix-like слешами под Windows быть не должно. Оказалось, что всё немного хитрее. Я в некоторых местах работах с путями как со строками, игнорируя тот факт, что пути в процессе работы могут быть сторонним кодом преобразованы. 

Скажем был у вас путь path/path/path. В процессе работы какого-нибудь gulp-плагина он исправился на windows-правильный путь path\path\path. А у вас далее по коду какой-нибудь .replace('path/path', ''). И вот оно сломалось. 

В поисках замены для OpenShot я наткнулся на Lightworks. В статьях про это ПО указывается, что есть и FREE версия, с урезанным функционалом. Причём без деталей о том, в чём именно этот функционал урезан. Проставил, покопался, склепал элементарный ролик, теперь знаю. Это невозможность экспорта никуда, за исключением прямой заливки видео на Youtube или Vimeo. Т.е. сохранить файл на диск нельзя.

По сути я могу это трактовать только как отсутствие бесплатной версии. Потому что такой вот use case нафиг никому не нужен. Рассматривать Lightworks можно только как альтернативу другим платным профессиональным инструментам. Так что прекратите размещать его в свои обзоры бесплатных видеоредакторов.

Некоторое время назад я попробовал воспльзоваться действительно бесплатным редактором ― Shotcut. Но оказалось, что за красивой обёрткой скрывается ― ничего. Этот редактор не умеет практически ничего. Это даже не редактор, это какое-то недоразумение (ИМХО), если честно. Уж на что OpenShot кажется топорным, но Shotcut переплюнул и его :)

Что ж. Буду и дальше искать. Хочется чего-нибудь средне-функционального и, разумеется, бесплатного. Т.к. монтирую относительно простые  и некоммерческие ролики, к тому же, довольно редко. В мире граф. редакторов подобного софта навалом. 

При написании подручных консольных криптов неизбежно встаёт вопрос, а как запускать внешнюю программу так, чтобы не потерять её вывод. Ситуация осложняется тем, что вывод может быть сложнее, нежели просто груда текста. К примеру ffmpeg рисует что-то вроде progressbar-а в поледней строке выдачи. Помимо прочего не хочется терять цвета. 

Стандартная библиотека предоставляет ряд методов для запуска сторонних программ. Я перебрал несколько из них, но всё как-то мимо. К примеру при ручном перенаправлении spawn-а за счёт pipe в process.stdout выдачи я не добился. При ручной обработке on('data', нет цветной выдачи и затирания уже отрисованного текста. Ну и т.д. 

Как обычно великий stackoverflow помог:

require('child_process').spawn('ffmpeg',
	[
		'-i', fname,
		'-f', ext,
		'-vcodec', vcodec,
		'-acodec', acodec,
		'-ss', fromS,
		'-to', endS,
		result
	], { stdio: 'inherit' });

Весь рецепт в третьем параметре ― { stdio: 'inherit' }! 

UPD0. Помимо цветного вывода и затирания текста прекрасно работает пользовательский ввод (пример: ffmpeg спрашивает перезаписать ли сущ-ий файл). Получается, что stdin тоже пробрасывается.

Как уже и писал ранее, случилась у меня проблема с удалением файлов. GoPro подключается к ПК не как USB-flash, а как MTP (Media Transfer Protocol). Это выражется в том, что не все файлы, размещённые на носителе видны, тем что не удаётся посмотреть начало какого-нибудь ролика не скачав его целиком, а также в том, что мой LinuxMint отказывается скачивать с такого вот MTP-носителя файлы, ибо соединение попросту зависает при любой операции.

Ну да ладно. Есть ультрабук с Win8 на борту. Можно качать через него, ведь он файлы видит. И дёрнул меня чёрт сократить время, и скопировать сразу на флешку. Да и не скопировать а "вырезать" и "вставить". Получив несколько невнятных ошибок я столкнулся с ситуацией, когда на SD-карте файлов уже нет, а на флешке их и не появлялось вовсе. Т.е. они утеряны.

В очередной раз высказав всё, что я думаю об MTP и GoPro я подумал, что файлы ведь можно восстановить. Ибо они не должны быть ничем перезаписаны. Должны лежать как на ладони, быстро находиться и идеально восстанавливаться. Картридера у меня увы нет, мой One PlusOne не умеет внешние SD-карты. Но старый SGS II умеет. И посему я решил воспользоваться android-восстанавливалками.

• Первым в ход пошёл DiskDigger undelete. Не сказать, чтобы софтина понравилась, но она смогла найти 1 старый 3 MiB файл, совершенно бесполезный, но это уже хотя бы отличный от 0 результат. Ушло у неё на это около часа.
• Вторым был Hexamob Recovery Lite. Первое, что он сделал ― бросил меня в Google Play покупать платную версию. Логика железная, я скачал бесплатную версию, чтобы убедиться что она хотя бы найти что-то сможет, а меня уже швыряют покупать платную. Вы за кого держите пользователя? Следующим этапом было то, что нет никаких по сути опций и настроек, он просто спрашивает где сканировать и начинает сканировать. Никакой индикации прогресса нет, просто отображении анимации, мол "я ещё не завис". Ну и всякая реклама. Потерпев минуты 3 этот идаотизм, софтина ушла в утиль. Хороший пример того, как нельзя писать подобный софт.
• Третьим был Undelete for Root Users. Порадовал вменяемый и приятный на вид интерфейс, удобное управление. Не порадовало то, что он не нашёл ничего, совсем. На 32GiB ушло 1ч 11м.

Я упустил 1 момент. Дело в том, что 1 файл из 3 мне всё таки удалось с самого начала вырезать-вставить. Его я обкромсал, как обычно ffmpeg-ом, срезав по краям лишнее и снёс оригинал через shift+delete из caja. Затем, потратив часа 3 на восстановление файлов с SD-карты,  я вернулся к обрезанному видео. И понял, что, по запарке, срезал на несколько секунд больше, очень зря… А оригинал уже удалил. Решил восстановить уже этот файл. Проблема усугублялась тем, что файл лежал не на ext3 разделе, а на ntfs. 

• Вначале я наткнулся на ntfsundelete. Это консольная утилита, которой нужно указать раздел и она найдёт все легко-восстанавливаемые файлы, указав их размер, имя по возможности, inode и пр. Мой файл там нашёлся. Восстановив его (4 GiB) я получил 4 GiB кирпич, который ничем не открывается. Я подумал, что сие же mp4, а значит его можно как-нибудь починить. Полез рыскать по сети:
  • mplayer его показывает как какую то разноцветную жуть, мечту эпилептиков.
  • ffmpeg -i грязно ругался.
  • попробовал Video Repair. С ней возникли некоторые сложности, но в конце концов она просто помирала на файле с какими-то невнятными ошибками.
  • попробовал mp4repair.org. На сайте указано, что смело указывайте ему даже huge mp4 файлы, чем я и воспользовался. На ~30% всё повисает…
• Затем, я вспомнил, что файл был удалён ещё и в USB 3.0 Flash-ки. Попробовал Recuva. Нужный мне файл она нашла дважды. 1 пометила как испорченный и переписанный (причём файлом, который был на флешке уже месяц), второй как идеальный, без повреждений. Интересная форма шизофрении. Восстановив "идеальный", я столкнулся с тем, что получил такой же кирпич, как и в случае, ntfsundelete.

Учитывая, что эти 3 видео не являются для меня чем-то жизненно важным, я, убив себе настроение, закончил истязания и забил. Разве что, вот ещё на эту заметку хватило. Пожалуй, стоит купить внешний USB кардридер.

UPD1: Купил картридер. Картридер работает без каких-либо проблем. Попробовал что-нибудь найти через testdist. Тщетно. Из Win8.1 попробовал через Recuva, она в отличии от android приложений, нашла множество файлов. Восстановил те из них, которые могут быть искомыми. Все файлы ― кирпичи. Для "откирпичивания" использовал Video Repair. Получается чёрт знает что. 30% видео (отрывками по несколько секунд) идут без помех, оставшееся ― помесь с жуткими артефактами, всякими сдвигами во времени и прочим цирком.

Извечная беда с горячими клавишами в нестандартной (т.е. английской) раскладке. Наиболее часто попадается в Java и QT приложениях. Наиболее остро я на это натыкаюсь при использовании Mate окружения в свежем LinuxMint-е. Обе баги (что QT, что Java) уже исправлены, что, почему то не сказывается даже на свежих билдах софта, к примеру SmartGit-а. В очередной раз вооружившись поисковиком я стал искать решения в обход. И нашёл! Хороший человек написал небольшую java-утилиту для решения проблем с горячими клавишами. Вся соль в том, что необходимо запустить jar-ки с флагом -javaagent к java. В описании к репозиторию указано, как правильно это сделать для Intelli Idea и ещё ряда приложений. А для SmartGit-а вот правильное решение:

• Создать файл ~/.smartgit/smartgit.vmoptions
• Вписать туда -javaagent:%jarpath%/LinuxJavaFixes-%version%.jar=swt. Вместо %jarpath% указать путь к скачанным с github-а файлам, а вместо %version% текущую версию jar-ки. Обратите внимание на =swt, без этого в SmartGit ничего не заработало. SWT это фреймворк для Java, который использует SmartGit. 
• Готово!

Осталось найти рецепт для QT-приложений :( Похоже, что там надо насильно ставить себе QT5.5+ и собирать из исходников каждое проблемное приложение :(