MacOS El CapitanのSourcetreeでBitbucketにプッシュ

前回に引き続き,Sourcetree 2.7.6を使っている ()。今回のリモートサーバは Bitbucket | Git solution for teams using Jira である。
Sourcetree で久しぶりにプッシュしようとすると,次のメッセージが表示された。

remote: Invalid credentials

アカウント設定は次の通り。

  1. 認証タイプ: Basic認証
  2. プロトコル: HTTPS

以前はプッシュできていたし,パスワードも合っている。実際,このパスワードでWebブラウザからログインできるし,Sourcetreeで違うパスワードを入力すると,We couldn't connect to Bitbucket with your credentials. Check your username and try the password again. というダイアログボックスが表示されるからだ。
調べてみると,Sourcetree という「アプリ」を使う場合はアプリ用の認証パスワードが必要らしい (App passwords | Bitbucket Cloud | Atlassian Support)。App passwordをBitbucketのWebサーバ上で作り (Create an App password | Bitbucket Cloud | Atlassian Support),これをアプリのアカウントパスワードに貼り付ければよい。このパスワードは自動生成で,一度しか表示されないので,複数のクライアントでアクセスする場合は注意が必要。方法としては,同じパスワードを共有するか,クライアント毎に別のものを作るかである。クライアント別にした方が安全性は高い。パスワードはサーバに名前をつけて保存できるので,作成するときにクライアントの名前をつけておくといいだろう。

MacOS El CapitanのSourcetreeでGitHubにプッシュ

GitHub Desktop 2.2.2がまともに動かないので,Sourcetree 2.7.6を使うことにした。しかし,ここでまた問題発生。GitHubにプッシュしようとすると,次のメッセージが表示された。

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/r1/knl8dbsd14zf3qtn2tzr4ljm0000gn/T/SourceTreeTemp.9cRxc9

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags --set-upstream origin refs/heads/master:refs/heads/master
Pushing to https://github.com/user/repository.git
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/user/repository.git/'

パスワード認証のサポートは2021年8月13日に終了しているとのこと。GitHub Desktopはパスワード認証で使っていた気がするのだが,よく分からない。理由は不明だが,確実なのは使えないことである。
他にも困っている人はいるようで,解決方法を見つけた ([Solved] remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. | NamespaceIT)。

  1. GitHub.comのウェブサイトにログインしてPersonal access tokenを発行する。Personal access tokenの有効期限は最長3か月なので,3か月したらまた同じ作業をしなければならない。
  2. Sourcetreeのアカウント設定画面で以下のように設定して保存する。
Sourcetreeアカウント設定
  1. (これは必須かは分からないが) Macで「キーチェーンアクセス」を起動し,github.comの「インターネットパスワード」の項目を探し,「パスワードを表示」欄からパスワードを編集してPersonal access tokenを貼り付ける。

これでプッシュができるようになった。しばらくは使えそうである。

El CapitanでGitHub Desktopが中途半端に動かなくなる

MacOS El CapitanGitHub Desktopが中途半端に動かなくなってしまった。GitHub Desktop 2.2.2である。

先日,GitHub Desktopが勝手に更新されて起動しなくなってしまったので,古いバージョンに戻したところだった。動作しないバージョンに更新されてしまうというのも問題だし,更新後のバージョンは何になったのかと調べようとしたが,そもそも起動しないので不明なままだった。動作しないバージョンはどうでもいいとして,問題はGitHub Desktop 2.2.2である。起動すると,ログインを促すメッセージが表示されたので,ユーザ名とパスワードを入力したところ,残念なメッセージが表示された。

GitHub Desktop version is too old

GitHub Desktop設定画面

起動はするが,ログインできないのでGitHub.comへのプッシュはできない。これが「中途半端」の理由である。ファイルの更新状況などは表示できるので,サーバとの同期を除けば使えはする。Gitのコマンドをまともに覚えていないので困っている。これを機にコマンドを覚えるか,別のツールを使うか悩みどころである。

GYAO!の動画をFFmpegでダウンロードする

動画サイトGYAO!がサービス終了する。

誠に勝手ながら、「GYAO!」「GYAO!ストア」「トレンドニュース」は、2023年3月31日(金)午後5時をもちまして、すべてのサービスを終了いたします。
GYAO! サービス終了のお知らせ

終わってしまう前に,気に入った動画を保存しておきたい。FFmpegで保存することができる。全自動でないのである程度は面倒であるが,お気に入りの動画を無劣化でダウンロードできるので利点はある。押さえておくポイントは次の3つ。

  • ダウンロードできる動画とできない動画がある
  • 動画の情報は拡張子が「.m3u8」のファイルに書かれている
  • 映像と音声の2つのストリームがある

これを踏まえたダウンロードの方針は次の通り。

  1. ダウンロードしたい動画のページの中から「.m3u8」を探す
  2. 映像情報は「rendition.m3u8」,音声情報「rendition.m3u8」で同じなので,別名でダウンロード保存する
  3. ダウンロードした映像の形式はTS,音声の形式はAACなので,これを合体させてMP4形式にする

「.m3u8」が検索で出てこない動画はダウンロードできないので諦める。以下のシェルスクリプトを使うと上の手順が簡単になる。スクリプトにはgyao.shなどの好みの名前をつけて保存する。これはMacの例だが,Windowsのバッチファイルでも同様のことができると思われる。
おまけの動作として,タイトルに半角の「!」,「?」,全角のスペースが入っているときはsedで全角の「!」,「?」,半角のスペースに変換している。映像は仮に「tmp-$$.ts」,音声は「tmp-$$.aac」保存する。「$$」はシェルスクリプトのプロセス番号なので他のファイルとの重複を避けている。合体させてMP4ファイルを作った後に削除している。

#!/bin/bash
echo "動画URL:"
read movie
echo "音声URL:"
read sound
echo "タイトル:"
read title
file=$(echo $title | sed 'y/!? /!? /')
ffmpeg -y -c copy "tmp-$$.ts" -i "$movie"
ffmpeg -y -c copy "tmp-$$.aac" -i "$sound"
ffmpeg -i "tmp-$$.ts" -i "tmp-$$.aac" -c:v copy -c:a copy -map 0:v:0 -map 1:a:0 "$file.mp4"
rm -f tmp-$$.ts tmp-$$.aac

具体的な操作は以下の通り。

  1. GYAO!で保存したい動画のページをGoogle Chromeで開く
  2. Chromeのメニューから「その他のツール」→「デベロッパーツール」を開く
    1. デベロッパーツールの一番上で「Network」を選択
    2. 検索窓に「m3u8」と入力
  3. Chromeでそのページを再読み込みする(m3u8にマッチする行が表示される)
  4. Macのターミナルでgyao.shを起動
    1. Chromeデベロッパーツールに表示された,上の方の「rendition.m3u8」を選択し,「Copy」→「Copy Link Address」でリンクアドレスをコピー
    2. ターミナルの「動画:」プロンプトに貼付け
    3. Chromeデベロッパーツールに表示された,下の方の「rendition.m3u8」を選択し,「Copy」→「Copy Link Address」でリンクアドレスをコピー
    4. ターミナルの「音声:」プロンプトに貼付け
    5. Chromeの動画タイトルをコピー
    6. ターミナルの「タイトル:」プロンプトに貼付け
  5. 待っていれば完了

Chromeとターミナルを行ったり来たりする必要があるので面倒だが,ストリーミングを無劣化で保存できるのは利点だろう。
ダウンロードの様子はターミナルに表示される。回線が細いなど,状況によってはエラーが表示されることがある。その場合は,一旦Ctrl-Cでスクリプトを停止し,最初からやり直す必要がある。

エラー処理などは一切行っていないので,ダウンロード後に確認してほしい。例えば,「rendition」を選択するのに間違えるなどして,映像がないとか音声が入っていない動画になっている可能性がある。また,GYAO!のページをロードしたタイミングで回線が細いと判断された場合,低画質の情報になる場合がある。「映像のダウンロードが妙に早いな」と思ったらダウンロードを一旦止めて,ページをリロードして高画質の情報を取得し,再度ダウンロードし直すとよい。

Regza の録画用 HDD を修復する

東芝のテレビ Regza に外付けハードディスクを録画用に取り付けてあるのだが,調子が悪い。具体的には,録画の一覧が見えなくなった。一旦テレビの電源を切り,しばらくしてから電源を入れ直すと次のメッセージが表示された。

新しいUSBハードディスクを検出しました。 登録を行いますか? 登録時にハードディスクは初期化されます。

4TBのハードディスクの50%くらいが使用済みなので,初期化されては困る。ありがたいことに Regza のハードディスク修復ツールを作ってくれている方がいる。それを使って修復を試みようと思うが,修復できたとしてもこのハードディスクを使い続けるのは不安が残る。そこで,修復後に中身を新しいハードディスクにコピーすることにする。大まかな計画としては以下の通り。

  1. 新しいハードディスクを手配
  2. CrystalDiskInfo - Crystal Dew World [ja]Windows PC で起動し,ハードディスクの障害度合いを確認
  3. REGZAハードディスク簡単修復 - ダウンロード・ページ でハードディスクを修復
  4. REGZA HDD Easy Copy - ダウンロード・ページ で新しいハードディスクにデータをコピー
  5. データがコピーされた新しいハードディスクを Regza に接続

まずはハードディスクの修復まで行う。REGZA HDD Easy Repair は Ubuntu で起動する必要がある。手元に Mac があるので,VirtualBox のゲスト OS に Ubuntu 12.04 を導入することにした。具体的な手順は以下の通り。

  1. Index of /releases から 12.04.3 の PC (Intel x86) desktop CD 用 ISO ファイルをダウンロード (Ubuntu 12.04 LTS Desktop 日本語 Remix CD リリース | Ubuntu Japanese Team の方がよかったか?)
  2. Oracle VM VirtualBox - ダウンロード | Oracle 日本 のゲスト OS として Ubuntu をインストール
  3. パソコン経済学: REGZA HDD復旧メモ に習って,/etc/apt/sources.list を修正し,apt-get udate; apt-get upgrade; apt-get install libreadline5; apt-get install xfsprogs
  4. 修復用ハードディスクを Mac に接続
  5. VirtualBox のメニューから Devices→USB→修復用ハードディスクを選択
  6. Failed to attach the USB device. Failed to create a proxy device for the USB device. (Error: VERR_PDM_NO_USB_PORTS) というエラーが表示されたら,一旦 Ubuntu をシャットダウンし,VirtualBox の設定→ポート→USBで「USB 3.0 (xHCI) コントローラー」を選択 (エラー時には USB 2.0 が選択されていた)
  7. mount: /dev/sdb1: can’t read superblock. というエラーが表示されたら,ターミナルを起動し xfs_repair -Lv /dev/sdb1 で修復 ([Linux] XFS 修復 mount: /dev/sdb1: can’t read superblock. – 吉田Style-MindShare-)
  8. ●レグザHDD復旧ソフト「REGZA HDD Easy Repair」の使い方 - レグザREGZA研究 の通りに REGZA HDD Easy Repair で修復

修復できた模様で,まずは一安心。次はデータのコピーである。

Mac のローカルホスト名が自動的に変更される

f:id:nlogn:20210530135256p:plain

このコンピュータのローカルホスト名"MacBook-Pro-307.local"は、このネットワークですでに使用されています。名前は自動的に"MacBook-Pro-400.local"に変更されました。

MacBook-Pro-xxx.localの数字「xxx」がどんどん増えてついに400になってしまった。原因は、無線と有線で同じネットワークに接続しているかららしい (macos - MacOSXでホスト名が勝手に(自動で)変わってしまう - スタック・オーバーフロー)。原因が判明して、今のところ問題がないので放置することにした。

iPhone, iPad から Windows に接続されているプリンタで印刷したい

自宅ネットワーク内で、iPhoneiPad から印刷ジョブを送りたい。プリンタは AirPrint 非対応の EPSON EP-302 なので、なかなか難しい。

以前は Windows AirPrint Installer iOS5 for x86 x64.zip をインストールすればよかったようだが、iPhone、iPADからWindows10を使ってAirPrint非対応のプリンターで印刷する | level1の報告書 にあるように、iOS 10 で対応が終了してしまっているらしい。

当初は、Mac mini にプリンタを接続して、Mac mini をプリントサーバーにしていたのだが、MacBook からは印刷ができるのに、iPhoneiPad からはプリンタが見えないのである。

色々試しているうちに、Synology NASDebian CUPS プリンタが iOS から見えることが分かった。MacBook からも見える。そこで、CUPS で PDF ファイルに出力し、その出力フォルダを Windows で常時監視することで、フォルダに新規追加された PDF ファイルを印刷することにした。Synology NASDebian CUPS からは EP-302 に印刷できないのである。白紙が何枚も出力されるだけなのである。

そして、複雑怪奇な印刷システムが出来上がった。概要は以下の通りである。

  1. iPhone, iPad の例えば SafariGoogle Chrome から「プリント」を選択
  2. 「プリント」は AirPrint 対応プリンタを探しに行くので Synology NASDebian CUPS PDF プリンタを発見し、これを選択
  3. iPhone, iPad で不必要なページのチェックを外して「プリント」
  4. Debian CUPS PDF は /var/spool/cups-pdf/ANONYMOUS/ ディレクトリに PDF ファイルを出力
  5. Synology DMS にインストールした unison で、Debian のファイルを DMS ディレクトリに同期
  6. DMS のフォルダを共有設定
  7. Windows にインストールした FolderMill で DMS の共有フォルダを監視
  8. FolderMill でプリンタに出力

Download - FolderMill FolderMill 4.7 - Free Version は「FolderMill による印刷」であることが分かるカバーページを1枚出力するので、最初に裏紙を1枚入れておくと紙の無駄が省ける。

クラウド対応自動印刷 − フォルダーを監視し、ドロップ(作成)されたファイルをプリンターに自動印刷します。 無償版は、60分毎にソフトウェアの再起動が必要なので、見送った。PdfAutoPrintの詳細情報 : Vector ソフトを探す! はシンプルでいいのだが、Windows でドロップしたファイルだけが監視対象になるようで、NAS 上でコピーされて新規生成されたファイルの印刷はできなかった。ネットワークフォルダには対応していないので、ネットワークフォルダを N: ドライブなどのようにドライブ名をつけてやる必要がある。Windowsでドロップしたファイルは印刷されるが、ファイルはフォルダにそのまま残る仕様のようだ。結局、PdfAutoPrintも見送りとなった。ラドAutoPDFPrintの詳細情報 : Vector ソフトを探す! は未確認。

Unison File Synchronizer を DMS 上でコンパイルするのは手間なので、バイナリを使った。Unison Binaries にある、arm バージョンが使える。

How to use cron on a Synology NAS — Multigesture.net で Synology NAS の crontab 設定。1分に1回 unison する。

FolderMill は、印刷を行うと印刷したファイルを削除する。unison は、同期ファイルが削除されると元ファイルを削除する。このようにして、一旦生成された2つの PDF ファイルは印刷が完了するとすべて削除される。

今回は、このような設定にしたが、Debian CUPS の PDF 出力ディレクトリを共有してしまえば、unison は不要だし、crontab 設定も不要になるはず。しかしながら、Debian chroot は /var 以下に実体があり、NAS は /volume1 以下のフォルダしか共有設定ができない。また、/volume1 以下のフォルダに Debian chroot のフォルダをシンボリックリンクやハードリンスすることもできないのである。

Google クラウドプリントでも印刷は成功したが、Chrome から直接印刷するか、Google Drive アプリから印刷する必要があり、さらに iPhone, iPadGoogle アカウントとプリンタに接続されている WindowsChrome アカウントを同一にしておかなければならないので、家族が使うときに若干問題がある。また、Google クラウドプリントでは、不要ページのスキップが難しい。この点、iOS デフォルトのプリントは簡単で優れている。

今までは、子どもが「これ、印刷して!」と言って iPad を持ってきていたが、自分で印刷できるようになった。印刷要求を送ってから1分くらい待たなければいけないが、そこはご愛嬌で。