適当な何かの別館
epgrec UNAの開発・配布元。最終更新は2016/4/30。ダウンロードにはパスワードが必要で、ページ内にヒントがある。
epgrec UNAの録画済一覧の動画リンク切れを修正する(解決)
2015年からepgrecを派生バージョンのepgrec UNAに変更して使用している。epgrec UNAは本家epgrecと比較して、リアルタイム視聴に対応するなど機能拡張がされており大変重宝している。
ただ一つ困っているのが、録画番組の変換失敗や録画ファイルの整理でmp4などに変換したファイルが既定の位置に無い状態で録画済一覧の画面を開くと動画へのリンクが切れてしまい、既定の位置に動画ファイルを存在させてもリンクが復活しない点で、ファイラーから開けば動画自体は見られるが、録画済一覧の画面から開けないのも不便なので何とかしたい。
これは、以下のようにしてepgrec UNAデータベースのRecorder_transcodeTblテーブルにレコードを作ると復活する。このテーブルに登録されているレコードは、pathフィールドのファイル名が既定の位置に存在しなくなったりしておかしなデータになると、自動に削除され、録画済一覧画面の動画リンクが切れる模様。
insert into Recorder_transcodeTbl (rec_id,rec_endtime,enc_starttime,enc_endtime,mode,name,status,ts_del,pid,path) values (9999,"2018-05-13 00:00:00","2018-05-13 00:00:05","2018-05-13 00:30:05",4,"録画モード名",2,0,99999,"動画ファイルへの絶対パス");
rec_idは録画済一覧のリンクをポイントしたときに表示されるURLのreserve_id=の後の数値を指定する。mode,nameは録画モードとその名前。rec_endtime,enc_starttime,enc_endtime,status,ts_del,pidは適当な値で良いと思われるので他のレコードを真似る。idlフィールドはオートインクリメントなので指定不要。
Emacs24.4でorg-mode7を使う
Emacs24.4からorg-modeがバージョンが8となっておりエクスポートオプションや書式が変化している。画像のscaleオプションも見当らず、不便なためorg-mode7を使えるようにした。
以下の記事でorg-mode7のソースからのインストール方法が紹介されているので参照してインストールを行なった。
上記リンク先記事中のorg-mode7のファイルリンク(http://orgmode.org/org-7.8.09.tar.gz)はこのエントリを作成した2018/4時点でまだ有効だった(なお、org-mode公式サイト*1には旧バージョンへのリンクは見当らない)。
上記リンク先の記事の設定はMacを前提としている。linuxではMakefileを以下のようにする(各ディレクトリへのパスは自分の環境を確認のこと)。本来は"datadir"も変更が必要かもしれないが今回は変更しなかった。
prefix=/usr
lispdir = $(prefix)/share/emacs24/site-lisp/org-mode
infodir = $(prefix)/share/emacs/24.4/info
上記リンク先の記事の手順3の.emacsの記述については既にorg-modeの設定が済んでいれば特に必要ない。
また、このままだと元々インストールされているorg-mode8が起動してしまうため、org-mode7が優先して起動するように.emacsに以下のような書式で記述して優先度を変更する。
(setq load-path (cons "優先度を上げたいディレクトリ" load-path))
(Emacsテクニックバイブル~作業効率をカイゼンする200の技 - Google ブックス p.36より)
具体的には以下のようにする。
(setq load-path (cons "/usr//share/emacs24/site-lisp/org-mode/" load-path))
以上で晴れてorg-mode7が使えるようになった。
Ubuntu16.04LTSが頻繁にフリーズする(未解決)
(このエントリは不具合の報告のみで、不具合の解決には至っていないので注意)
Ubuntu16.04LTSをリリース以来使い続けて早2年近くなった。長らく快適に利用してきたが、いつからか数日に一度フリーズするようになった(Alt+PrintScreenを押しながらR->S->E->I->U->Bしても反応なく電源ボタン長押しで電源を切るしかない)。イレギュラーなものと気にせず使い続けていたところ、昨年11月頃からかその頻度が頻繁になり、年末頃から実用に支障を来す頻度でフリーズするようになってしまった。下はここ最近のフリーズ(ハング)の頻度を書き留めたものの抜粋である。時刻だけ書いてあるのはフリーズした時間。ほぼ毎日フリーズが発生している状態である。
1/10 00:30
1/13 14時頃フリーズ 就寝前に無線LANオフで放置。翌日は問題なく動作。
1/14 21:09,22:49
1/15 音楽を掛けて放置。日付けが回った24:51にフリーズ。
1/16 ハングせず。夜 音楽を掛けずネット接続のみオンラインにして放置。
1/17 4:37ハング。再起動し音楽一時停止・オンライン状態。22:28ハング 音楽掛けずネット接続もオフラインにして放置。
1/18 朝から晩まで正常動作
1/19 05:21ハング
1/20 00:54ハング
1/21 正常動作
1/22 18:18ハング(音楽・ネットon) ブートオプション変更(intel_idle.max_cstate=1)するも17:22ハング(音楽・ネットon)
肝心のハードウェア情報として、マザボはASUSのH170 PRO、CPUはIntel Core i5 6500、メモリはCFD Panram DDR4 PC4-17000 CL15 8GB×2、SSDはCrucial MX200を使用している。
調べてみると、マザボ・メモリ・SSD・OSにそれぞれフリーズの原因が報告されていることが次々判明し、泥沼に嵌まり混んでしまった模様。ここからどうしたものか。Windows10+HDDを入手の上動作確認してハードウェア側の不具合かどうかの切り分けが必要になるかと思われるが、不具合切り分けのためだけに出費をするのも躊躇するものがあり保留中。
(2018/7追記)
その後の同現象発生日数は2月に19日間、3月に11日間、4月に10日間、5月に6日間、6月に5日間でだんだん減少する傾向にあり、現在のところ6/20を最後に不具合は発生していない。何度かアップデートが入ったのでそのどこかで不具合が解消されたのかもしれない。やはりUbuntu側の問題だったのだろうか？(2023/6再追記) 解決？
その後フリーズ問題が再発。2019年頃からずっとフリーズの原因が分からず、フリーズしたらその都度電源を再投入して対応していたが、ESM(Extended Security Maintenance)適用のため、カーネルを4.5.0から4.4.0に落とし、ESMでアップデートされたカーネル4.4.0を使うようにしたところ1ヶ月ほど全くフリーズせずに使えている。ESM適用後にカーネルを4.5.0に戻してみたときはフリーズが再発したので、おそらくESM版カーネル4.4.0にフリーズが改善されるアップデートが含まれていたのではないかと思われる(記事投稿時の2018年当時に使っていたカーネルのバージョンは「4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux」だった)。参考までに記しておく。
価格.comでフリーズ報告がいくつかみられる。CPU C StatesをDisableにするが変化なし。「DRAM Frequency」を固定にするが変化なし。清掃してCPUをグリスアップしても改善せず。グラボはCPU内蔵のものを使っており挿していない。
- メモリ(CFD Panram DDR4 PC4-17000 CL15 8GB)
マザボとの相性問題の存在がamazonレビュー欄で触れられている。memtest86+では17時間問題なく稼働(Pass:7 Errors:0)
- SSD(Crucial MX200)
製品にプチフリ問題が指摘されている。しかしディスクユーティリティのヘルスレポートやBIOSのレポートでは不具合を示すような数値は出ていない。復旧用のUSB環境でブートして放置してもハングするためSSDが原因ではない？
- OS(・パッケージ・ドライバ)
突然のハングアップ現象が報告されている。
GRUBのオプション(intel_idle.max_cstate)を変更する方法がある模様。おそらくcpu c stateをOS側から設定する方法であると思われる。設定したが改善しない。値を0にもしてみたが変化なし。
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
また、フリーズ後の起動時にUbuntuに内部エラーが発生したとして「unity-settings-daemon」のクラッシュが表示されることがあったため以下のようにしてunity-settings-daemonを入れ直したが変化なし。
sudo apt-get install --reinstall unity-settings-daemon
また、Intelグラフィックスドライバがインストールされていない場合にデフォルトで入っているドライバとの互換性がなく落ちることがあるとのこと。インストールされているかどうかはglxinfo | grep Deviceで確認できるとのことで実行してみたところ、以下のように表示され、ドライバは入っているようだった。
Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) (0x1912)
(書き掛け)
参照サイト
(書き掛け)
RemminaでWindows10 Home+UltraVNC接続できない(解決)
Ubuntu16のリモートデスクトップクライアントであるRemmina(バージョン1.1.2)からUltraVNC(バージョン1.2.1.6)を走らせたWindows10 Homeに接続したかったが、接続するとすぐにRemminaのViewerウィンドウが閉じてしまい操作することができない。
調べてみると、UltraVNCの公式フォーラムで以下のように「最高画質を選べ」という内容が見つかる。
Re: Remmina cannot connect to computer since V1.2.0.9
Postby sergeyboev » 2016-03-15 18:44
In Remmna VNC select Best Quality.
UltraVNC • View topic - Remmina cannot connect to computer since V1.2.0.9
「高度な設定」タブの「品質」を「最高」に設定したところあっさりと接続できた。さらに別の設定についても選んでみるとデフォルト設定の「256色」以外ならどれでも問題なく接続でき、256色を指定した場合のみ不具合が再現した。
なお、RemminaにはUltraVNC用のプラグインが存在するが、これの導入は必要なくプロトコルには通常通り「VNC」を選択すればよい。
付記
- synergyは併用しない
synergyを稼働させていると、リモートデスクトップクライアント側のリモートデスクトップビューア内から操作のフォーカスを外せなくなり、リモートデスクトップサーバ側のOSを終了させないとリモートデスクトップクライアント側に操作を戻せなくなるので注意。
リモートデスクトップとsynergyを併用するような用途はないが、リモートデスクトップ運用にする前にsynergyで使用していた際は注意。
関連サイト
ネットワーク経由でWindows 10を操作する（VNC編） PCまなぶ
スクリーンショット付きで至れり尽せりの解説。ただし2018/1現在のWindows10とは若干設定項目の場所が変化しているようなので適宜読み替える。
【Ubuntu】UbuntuからWindowsをリモートデスクトップで操作する - Milkのメモ帳
Remmina設定の説明あり。こちらの説明で用いられているWindows10はWindows10 Proであるため、OS標準のリモートデスクトップサービスを利用しておりプロトコルにRDPを選択しているが、一般的なWindows10 Homeにはリモートデスクトップサービスが標準で付いてこないためUltraVNCのようなリモートデスクトップサービスを後から導入する必要がある。UltraVNCではプロトコルに「VNC」を選択する。
Remmina Plugin UltraVNC | Introduction
Remmina Plugin UltraVNCの公式サイト。プロトコルに「ULTRAVNC」が追加される。当初こちらを導入してみたがうまくいかず、試行錯誤(Remmina 1.1のcmakeオプションを指定したり別のバージョンのプラグインを持ってきたりビルダーのバージョンを変えたりと)してみたがすぐにビューアウィンドウが閉じてしまう状態は変わらなかった。結局Remmina(バージョン1.1.2)ではプラグイン無しでUltraVNC(バージョン1.2.1.6)に接続することが可能だった。
ファイラーrangerでゴミ箱を使う with NTFSパーティション
CLIのファイラーrangerはファイルの削除動作を行なうと標準では(スペース選択してからなら確認は入るものの)いきなりファイルが削除されてしまうためゴミ箱機能を使えるようにしたい。trash-cli(公式GitHub)を使うことでゴミ箱機能を実現できるが、trash-cliのファイルをゴミ箱に入れるコマンドであるtrash-putをrmのエイリアスに設定しておいてもranger上で削除操作をする際には有効にならない。
rangerの削除動作をtrash-putと連携させるにはrangerの設定ファイル~/.config/ranger/rc.confを以下のように変更すればよい。
# map dD console delete map dD shell -s trash-put %s
ゴミ箱の中身を見るにはtrash-listコマンドを使うが、標準だとばらばらに表示され使いにくい。ゴミ箱の中身を日付逆順にソートして表示するには以下のようにsortコマンドに渡せばよい。
trash-list | sort -k 1 -r
NTFSパーティション編
ここまでは簡単だったが、ゴミ箱の中身を見ようとtrash-listコマンドを実行すると以下のように出てNTFSパーティションで削除したファイルだけが表示されない(ここではNTFSパーティションのマウント先パスを/mnt/hddとする)。trash-putしたファイル自体は/mnt/hdd/.Trash/1000に存在している。
trashdir skipped because parent not sticky: /mnt/hdd/.Trash/1000
/etc/fstabは以下の通り設定していた。
uuid="00000DUMMY000000" /mnt/hdd ntfs rw,nosuid 0 0
解決方法
まず、/etc/fstabのマウントオプションに"permissons"を追加し、NTFSパーティションをマウントし直す。
UUID="00000DUMMY000000" /mnt/hdd ntfs rw,permissions,nosuid 0 0 # ↑オプションに"permissons"を増やしただけ
次に、.Trashディレクトリにスティッキービットを設定するとともに、.Trash以下のオーナーをログインIDに変更すればよい(以下の例ではログインIDをhogeとしている)。
sudo chmod 1777 /mnt/hdd/.Trash/ sudo chown -R hoge:hoge /mnt/hdd/.Trash/
試行錯誤の記録
ここからは解決に至るまでの試行錯誤の内容。なお、解決に要した時間は3時間だった。
調べてみると、trash-cli公式GitHubのIssue(Problem using Trash on a usb key · Issue #59 · andreafrancia/trash-cli)にてtrash-cliは.Trashディレクトリにスティッキービットが立っていることが必要だが、NTFSパーティションはスティッキービットを立てられないとの内容が見付かった。他のIssueでも作者が以下のようにスティッキービットを立てられないファイルシステムはサポートしていないとコメントしている。
andreafrancia commented on 2 Jan
trash-cli does not support filesystem that does not allow to set the sticky bit.
trash-empty not working for partitions · Issue #65 · andreafrancia/trash-cli
何とかならないかと探していたところTuxera Support - View topic - Cannot mount NTFS with the Sticky bitやntfs-3g を使って NTFS に書き込む - ぽち＊ぷ〜ちにてntfs-3gコマンドの存在を知る。ただし、毎回ntfs-3gコマンドを実行してマウントするのは実用的ではないのでfstabに記述する方法を調べた。
fstabに記述するには以下のようにntfsの代わりにntfs-3gを指定しオプションにpermissionsを指定すれば良いようだ。
UUID="00000DUMMY000000" /mnt/hdd ntfs-3g rw,permissions,nosuid 0 0permissions - How do I correctly mount a NTFS partition in /etc/fstab? - Ask Ubuntu
これでNTFSパーティションのディレクトリでも以下のようにスティッキービットが立つ。
chmod 1777 /mnt/hdd/.Trash ls -ld /mnt/hdd/.Trash drwxrwxrwt 1 root root 0 1月 1 10:10 /mnt/hdd/.Trash
これで良いかと思われたが、実際にNTFSパーティションのファイルを削除すると以下のようにファイルがゴミ箱に移動できない旨のエラーが出る。
trash-put hoge trash-put: cannot trash regular file 'hoge'
そこで、.Trashディレクトリ以下全てのディレクトリをログインユーザ(以下の例ではhoge)の所有にしてみたところうまくいき、trash-listでNTFSパーティションのファイルも表示されるようになった。
sudo chown -R hoge:hoge /mnt/hdd/.Trash/
さらに調べるとUbuntu 16.04でntfsはntfs-3gへのシンボリックリンクになったとのこと。
Re: NTFS or NTFS-3G
Just ran this in Ubuntu 16.04 in case something changed:
tester@vub1604:~$ ls -l /sbin/mount.ntfs
lrwxrwxrwx 1 root root 13 Apr 23 18:14 /sbin/mount.ntfs -> mount.ntfs-3g
It would appear that "ntfs" is still a symbolic link to "ntfs-3g".
[SOLVED] NTFS or NTFS-3G
そこで以下のように/etc/fstabの"ntfs-3g"を"ntfs"に変えてマウントし直してみたところスティッキービットは立っていた。結局マウントオプションの「permissions」の有無だけがキモだった模様。
UUID="00000DUMMY000000" /mnt/hdd ntfs rw,permissions,nosuid 0 0
マウントオプションのpermissionsについてはmountコマンドのマニュアルを見ても掲載が無く、検索してもこれと言った情報が出て来なかった。
参照サイト
trash-cli公式GitHub。FAQにtrash-putをrmのエイリアスにするべきではないと書いてある。
trash-cliパッケージのコマンド一覧が掲載されている。現在はややコマンド名が異なっており以下のようになっている。
| コマンド名 | 機能 |
|---|---|
| trash(trash-put) | ファイルを削除する |
| trash-list | ゴミ箱の中身を見る |
| restore-trash | ゴミ箱からファイルを復元する |
| trash-empty | ゴミ箱を空にする |
| trash-rm | 指定した日数以前のファイルをゴミ箱から削除する |
fstabでpermissionsオプションを設定したが、マウント後にmtabを見るとオプション設定がdefault_permissionに上書きされているのはなぜか？という質問。mountオプションのpermissionについての記述がある。permissionオプションが何か？についての記載はない。
NTFSパーティションをマウントするとrootの所有となりパーミッションが777になってしまうが正しく設定する方法はあるか？という質問。mountオプションのpermissionについて以下のようにpermissionオプションを付けるとchmodやchownが動作するとの回答がある。permissionオプションが何か？についての記載はない。
answered Panther Mar 17 '12 at 15:24
If you mount the ntfs partition with the permissions option, then chmod / chown will work
/dev/sda2 /mnt/excess ntfs-3g permissions,locale=en_US.utf8 0 2
answered CMP Aug 3 '15 at 3:19
UUID=xxxxxxxxxxxxxxxxx /media/mydrivename ntfs permissions,locale=en_US.utf8 0 2
Android上のEmacsでミニマムテープ起こし環境を整える
ひとまずのメモ書き。
Termuxでmpvをインストールする。Termuxについては以下の前回の記事を参照。
以下の記事を参照してmpv.elを入れて設定する。後は使い方まで含めて記事中に全て書いてあるのでそちらを見ればよいのだが、Termuxという環境での設定記録として若干のカスタマイズと補足を書いた。
Termuxにはmozcが無いのでskkかAndroidのIMEを利用する。ただしAndroidのIMEは最下段に表示され変換を確定するまでEmacsに反映されないのでやや使い勝手が良くない。
- ショートカットを変更
以下のようにショートカットを変更した。本来はC-M-kのように設定したかったが、ターミナル上では「C-」の組み合わせが特定のキーしか有効にならない*1ため。
| ショートカットキー | 機能 |
|---|---|
| M-k | 再生/一時停止 |
| M-, | 少し戻る |
| M-. | 少し進む |
mpv.elの以下の箇所のキー設定を変更する。
(global-set-key (kbd "M-k") 'mpv-pause) (global-set-key (kbd "M-,") 'mpv-seek-backward) (global-set-key (kbd "M-.") 'mpv-seek-forward)
なお、リンク先記事のmpv.elのコードに記載されている「H-」とはHyper(Windowsキー)のことだが、BluetoothキーボードのWinキーを押しても反応しなかった(ターミナルなので当然か)。
- 再生
M-x mpv-play→ファイルを選ぶ
- リンクの挿入
「C-c C-l」→「Link:」が表示される→「mpv」を入力→音声ファイルをフルパス指定→RET RETでリンクが挿入される。リンクの上で「C-c C-o」すると再生が開始できる。Termux上のEmacs24という環境のためか、音声ファイルを指定する際にはミニバッファに(no completion)と表示されておりファイル名の補完機能は効かなかった。
- 再生位置の挿入
「C-c C-x -」すると再生時刻が挿入される。挿入された時刻の上で「C-c C-o」するとその位置へ飛ぶ。本来は「M-RET」で挿入されるはずだが、Termux上のEmacs24という環境のためか挿入されなかった。
- これはできないか？
モードラインへの再生時間表示。標準であっても良さそうな機能だが、現在の再生時刻を確認するには「C-c C-x -」して知るしかない。
- GNURoot Debianではどうか？
Termuxとは別のターミナルアプリ「GNURoot Debian(Google Play)」にはTermuxにはないemacs-mozcパッケージが存在するためGNURoot Debianでのテープ起こしを考えたが、GNURoot Debianにはmpvパッケージが存在するものの以下のエラーが出てmpvが実行できなかった。
mpv: error while loading shared libraries: libx264.so.142: cannot enable executable stack as shared object requres; Permission denied
- まとめ
基本的にシングルタスク・シングルウィンドウのAndroid端末では、単体でテープ起こしをすることは不可能だったが、Termux+Emacs+mpv.elの導入により、AndroidとBluetoothキーボード*2(とできればカナル型イヤフォン)さえあればいつでもどこでもEmacsによるミニマムな快適テープ起こし環境が可能となった。記事中のリンク先をはじめとした先人に感謝したい。
