SimpleLife

TVサーバーをメンテナンスする際にRemote Desktopを利用して遠隔操作をしていますが、Ubuntuのシステムアップデートで接続できなくなりました。ここではその時の復旧手順をメモしておきます。

GNOMEがアンインストールされていたので、再インストールします。

$ sudo apt update
$ sudo apt install ubuntu-desktop

UbuntuのGNOMEをRDPで表示させるための必須の修正をいれます。

$ sudo nano /etc/xrdp/startwm.sh
...
unset DBUS_SESSION_BUS_ADDRESS  <-追加
unset XDG_RUNTIME_DIR           <-追加
test -x /etc/X11/Xsession...
....

Ubuntu用にカスタマイズされGNOMEの設定を読み込むように.xsessionを設定します。

$ echo "export GNOME_SHELL_SESSION_MODE=ubuntu" > ~/.xsession
$ echo "export XDG_CURRENT_DESKTOP=ubuntu:GNOME" >> ~/.xsession
$ echo "exec /usr/bin/gnome-session --session=ubuntu" >> ~/.xsession
$ chmod +x ~/.xsession

xrdpを再起動します。

$ sudo systemctl restart xrdp

Synology NASでWebサーバーを立ち上げ、LAN内でWANと同じURLでアクセスできるようにするためには、LAN内にSSL/TLS証明書を用意して常時SSLで通信できるようにする必要があります。Synology NASはSSL/TLS証明書による通信をサポートしているため、これを使ってSSL通信を簡単に実装できます。

さらにSynology NASはLet’s Encryptを使ったSSL/TLS証明書の発行と有効期限切れ前の自動更新もサポートしているので、SSL通信を実現するためにはこの機能を使う方法が一番手軽です。

しかし、Webサーバーを複数立ち上げる場合はその都度証明書を発行しなければなりません。SSL/TLS証明書はワイルドカードをサポートしているので、*.sabalog.comのようにワイルドカードでSSL/TLS証明書を発行すれば一つのSSL/TLS証明書で対応できます。しかし、Synology NASのLet’s Encryptでは独自ドメインのワイルドカード証明書の発行はサポートしていません。

また、Let’s EncryptでSSL/TSL証明書を発行・更新するためには、発行申請するURLでWAN側からNASに直接アクセスできる状態にしておく必要があります。このため、CloudflareのTunnelingを使用してサーバーにアクセスしている場合などWAN側からNASへのアクセスができないときはLet’s Encryptを利用できません。

このようにSynology NASでLet’s Encryptを使うためにはさまざまな制約があるため、制約を回避できない場合はSSL/TLS証明書は別の手段で発行・更新する必要があります。

ワイルドカード証明書の発行と適用

LAN向けのワイルドカード証明書はプライベート認証局を立てて自己署名したものを使うことができます。しかし、LANからアクセスするデバイスにCA証明書を手動でインストールしないと不正な証明書として認識されてしまい、表示に確認の一手間を要したりデバイスによってはアクセスできない場合もあります。また、異常検知にも影響するので可能な限り正規の証明書を使うべきです。

この異常状態を回避するため、無料認証局のサービスを利用してSSL/TLS証明書を発行し適用します。

ここではCloudflareに登録したドメインでワイルドカード証明書を発行し、自動更新する方法について解説します。Cloudflareへのドメインの登録方法は様々ですのでここでの説明は割愛します。

CloudflareのアカウントIDとAPIトークンを取得する

アカウントIDはドメイン管理画面の下の方に下記のような形で表示されています。これがアカウントIDになります。

APIトークンはマイプロフィールから取得します。

TLS/SSL証明書を発行する

Synology NASにSSHでログインして下記コマンドを実行します。

# --- Cloudflare 認証用設定 ---
export CF_Token=【APIトークン】
export CF_Account_ID=【アカウントID】
export CF_Email=【証明書に付与するメールアドレス】
export CF_Domain=【ワイルドカード証明書に付与するドメイン名】

# --- 実行処理 ---
sudo docker run --rm -it \
 -v /volume1/docker/acme:/acme.sh \
 -e CF_Token=$CF_Token \
 -e CF_Account_ID=$CF_Account_ID \
 -e CF_Email=$CF_Email \
 neilpang/acme.sh \
 --issue --dns dns_cf \
 -d "$CF_Domain" -d "*.$CF_Domain" \
 --server letsencrypt

すると鍵ファイル群が生成されます。下記はドメイン名にsabalog.comを指定した場合に生成されたファイルで、*.keyが秘密鍵、*.cerが公開鍵、*.caが中間証明書になります。

TLS/SSL証明書をインポートする

TLS/SSL証明書のインポートはDisk station上で”コントロールパネル>セキュリティ>証明書>追加”を選択し、証明書ファイルをインポートする際に下記のようにファイルを選択してOKを押せば、証明書が追加されます。

証明書の自動更新

前述のスクリプトで発行したSSL/TLS証明書は有効期限が三ヶ月後に設定されるため、三ヶ月ごとに更新する必要があります。この作業はSynology NASのタスクスケジューラーで自動化できます。

タスクを追加する際にユーザーを「root」、実行間隔を「1週間」、ユーザー指定のスクリプトに以下のコマンドラインを設定して保存します。

docker run --rm --net=host -v /volume1/docker/acme:/acme.sh neilpang/acme.sh --cron

動作確認

テスト実行をした時に下記のようなログが出力されていれば正しく動作しています。

[Thu Mar 12 13:01:33 UTC 2026] ===Starting cron===
[Thu Mar 12 13:01:34 UTC 2026] Already up to date!
[Thu Mar 12 13:01:34 UTC 2026] Upgrade successful!
[Thu Mar 12 13:01:34 UTC 2026] Automatically upgraded to: 3.1.3
[Thu Mar 12 13:01:34 UTC 2026] Renewing: 'sabalog.com'
[Thu Mar 12 13:01:34 UTC 2026] Renewing using Le_API=https://acme-v02.api.letsencrypt.org/directory
[Thu Mar 12 13:01:34 UTC 2026] Skipping. Next renewal time is: 2026-04-06T06:48:08Z
[Thu Mar 12 13:01:34 UTC 2026] Add '--force' to force renewal.
[Thu Mar 12 13:01:34 UTC 2026] Skipped sabalog.com_ecc
[Thu Mar 12 13:01:34 UTC 2026] ===End cron===

実行ログは”コントロールパネル>タスクスケジューラー>設定>出力結果を保存”にチェックを入れることで出力されます。

ユーザースクリプトは、実行指定した時間が来るかタスク上で右クリックで表示されるメニューの”実行”を選択することで実行されます。

参考になれば幸いです。

WordPressでWebサイトを運用していると、画像がアップロードできない、”http://…”でアクセスできないなどの不具合に遭遇することがあります。

不具合の原因特定と修復にはプラグインのインストールやスクリプトの改変などの試行錯誤を繰り返すことになりますが、この過程でWordPress自体が不安定になることがあります。この場合、WordPress自体を新規インストールし直し、元々のサイトのデータをインポートしてWordpress自体をリセットする方法が最も確実です。また、復旧手順が確立していれば何度もトライ&エラーができるので、修復した環境に意図しない設定が入り込むこともなくなります。

WordPressをリセットするにはUpdraftやWordPress All-in-One Migrationなどを利用し、データベース、テーマ、プラグインをバックアップし、WordPressを新規セットアップしてインポートする方法が最も簡単です。

ところが、プラグインを利用した場合はバックアップしたデータベースをインポートする際に処理が一向に進まず、丸一日たっても処理が終了しないことが多々あります。このような場合はデータベースの移行時にプラグインを利用しない形で対応する必要があります。

ここでは、Wordpressのリセット作業時にデータベースの移行をmysqlを利用して確実に行う手順を記載します。

1.UpdraftでWordpressのコンテンツ全体をバックアップする

はじめにWordpressのコンテンツをUpdraftを使ってバックアップします。

バックアップすると以下の5ファイルがWordpress内で生成されるので、これらをPCにダウンロードしておきます。

2.WordpressのデータベースをExportする

WordPressが動作しているPCのターミナル上で下記コマンドを実行し、データベースをExportします。

$ mysqldump -u <user id> -p<password> wordpress > wordpress_backup.sql
# -pとパスワードの間はスペースは入れないこと

Synology NASのDockerでWordpressを動かしている場合は、以下のコマンドでExportします。

$ sudo docker exec -it <dockerコンテナ名>_db sh -c 'mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" wordpress' > wordpress_backup.sql

Dockerコンテナ名はContainer Managerに表示されている下記文字列になります。

3.Wordpressを新規セットアップする

WordPress環境を新規で再セットアップします。

Synology NASの場合はDockder ManagerでWordpressのDockerコンテナを停止した後、Dockerコンテナディレクトリをコピーしてバックアップしておきます。バックアップが完了したらwp/redis/dbの中身を削除してWordpressのDockerコンテナを再構築すれば新規セットアップできます。

WordPress起動後は下記設定をwp/wp-config.phpに書き込むか、バックアップコピーにあるwp/wp-config.phpを新規インストール先へコピーしておき、あらかじめredisの有効化とプラグインインストール時のFTPアカウント要求を抑止しておきます。

define( 'WP_REDIS_HOST', 'redis' );
define('FS_METHOD', 'direct');

新規インストールが完了した後はWordpressにログインして初期セットアップを行い、Wordpressのバージョンを最新のものにアップデートしておきます。合わせてUpdraftプラグインもインストールしておきます。

4.データベース以外のファイルをインポートする

Updraftを使って、バックアップからデータベース以外を復元します。

5.データベースをインポートする

下記コマンドでExportしたデータベースをインポートします。100MB程度のデータベースだと5分程度かかります。進行状況は表示されませんので反応がなくてもじっと待ちましょう。

$ cat memo_backup.sql | mysql -u <user id> -p<password> wordpress

Synology NASのDockerでWordpressを動かしている場合は、以下のコマンドでインポートします。

$ cat memo_backup.sql | sudo docker exec -i <Wordpressコンテナ名>_db mysql -u root -proot wordpress

6.【別URLで新規Wordpressを設定した場合】データベース内のURLを書き換える

WordPressのデータベースのイメージファイルへのパスはフルパスのURLで記述されています。このため、別URLで動作しているWordpressにデータベースインポートしただけでは、エクスポート元のURLが消えると画像が表示されなくなります。この問題は、データベース内のURLを新規URLに置き換えることで解決できます。

データベースのURLの置き換えは以下のコマンドを実行します。

# WP-CLIをコンテナ内にダウンロードする
$ sudo docker exec -it wordpress_recipe_sabalog_wp curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
Password: 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6975k  100 6975k    0     0  15.7M      0 --:--:-- --:--:-- --:--:-- 15.7M

# ダウンロードしたWP-CLIを使って置換を実行する
$ sudo docker exec -u www-data -it <Wordpressコンテナ名>_wp php wp-cli.phar search-replace '<検索文字列>' '<置換文字列>'
+------------------+-----------------------+--------------+------+
| Table            | Column                | Replacements | Type |
+------------------+-----------------------+--------------+------+
| wp_commentmeta   | meta_key              | 0            | SQL  |
| wp_commentmeta   | meta_value            | 46           | PHP  |
| wp_comments      | comment_author        | 0            | SQL  |
.....

下記は変換時の出力サンプルになります。変換には100M程度のデータベースで15分程度かかりましたので、置換実行時は終了まで気長に待ちましょう。

$ sudo docker exec -u www-data -it wordpress_simplelife_sabalog_wp php wp-cli.phar search-replace search-replace 'https://simplelife.sabalog.com' 'http://temp.sabalog.com' --skip-columns=guid --allow-root
+------------------+-----------------------+--------------+------+
| Table            | Column                | Replacements | Type |
+------------------+-----------------------+--------------+------+
| wp_commentmeta   | meta_key              | 0            | SQL  |
| wp_commentmeta   | meta_value            | 46           | PHP  |
| wp_comments      | comment_author        | 0            | SQL  |
| wp_comments      | comment_author_email  | 0            | SQL  |
...
| wp_options       | autoload              | 0            | SQL  |
| wp_postmeta      | meta_key              | 0            | SQL  |
| wp_postmeta      | meta_value            | 19           | PHP  |
| wp_posts         | post_content          | 2926         | SQL  |
| wp_posts         | post_title            | 0            | SQL  |
...
| wp_posts         | to_ping               | 0            | SQL  |
| wp_posts         | pinged                | 1            | SQL  |
| wp_posts         | post_content_filtered | 0            | PHP  |
...
Code language: JavaScript (javascript)

参考になれば幸いです。

※2026/8/11現在の情報になります
※スクリプトや構成のアップデートに合わせて、記事も随時アップデートしています
※2026/8/11 スクリプトファイルをGitHubで管理するようにしました

以前よりUbuntuでTV録画・視聴サーバー（以降、TVサーバーと表記）を設置し、CMを抜いたmp4への変換にはWindowsのAmatsukazeを利用し、バックアップ処理も含めて自動化していました。しかし、TVサーバーのために2台のPCを使うのはもったいないと考え、Ubuntu上で完結するシステムへの切り替えを検討していました。

ところがネットを検索しても、録画後にAmatsukazeを使ってCM抜きmp4を生成する自動化処理はWindows単体もしくはWindowsとUbuntuを2台利用したものがほとんどで、Ubuntuのみで完結したシステムの記事は見つかりませんでした。

そこで、TVサーバーをUbuntuで実装する方法を一から検討し、「録画→不要ファイル削除→CM抜き→mp4/tsバックアップ」の手順を完全自動化して、現在メンテナンスフリーで安定運用しています。

本記事はUbuntu上で上記自動化を行ったTVサーバー仕様をメモしたものになります。

本記事のTVサーバーのシステム構成

構築したTVサーバーのシステム構成は以下のとおりです。

mp4ファイル再生用のメディアサーバーはTVサーバー上に構築することでPC一台でシステムを完結させることもできます。しかし、mp4ファイルは最終的にNASへバックアップコピーするので、録画中のDrop発生要因を減らすことも考慮し、バックアップ先のNAS上で整理・再生するようにしました。

NASへのコピーはSFTPを利用しました。Exportされたディレクトリをマウントする形式だと電源を入れる順番などでマウントに失敗することもあるため、コピー開始直前にNAS側の異常を検知できるSFTPを使っています。

tsファイルはファイルサイズが大きくLAN経由でのコピーは時間がかかる上に、保存後は頻繁にアクセスすることもないことから、NASへのバックアップコピーではなくPCに直接接続したHDDを保存先にしています。

TVサーバー構築用ソフトウェア

TVサーバーを構築するソフトは、録画用に「EPGStation」、リアルタイム視聴・tsファイル再生用に「KonomiTV」を利用します。EPGStationは録画した番組をts形式で保存し、KonomiTVでtsファイルを直接再生して視聴できます。

録画用ソフトにEPGStationを使う理由は、RaspberryPi上でも動作するためです。拙宅ではTVサーバーが何らかのトラブルで録画に失敗する場合に備えてRaspberryPiで録画バックアップサーバーを動かしているため、録画ルール(時刻・条件・録画ファイル格納ディレクトリ)のデータを同期しやすいEPGStationを選択しました。

このような縛りがなければ、KonomiTVが録画予約までサポートしているEDCBを使うほうが便利かと思います。

TVサーバー構築用OS

録画用ソフトにEDCBを使えばWindows PCのみでTVサーバーを構築することはできますが、セキュリティアップデートでアプリが起動しなくなる、録画途中に負荷がかかりDrop発生の可能性がある、再起動が発生する、突発的なブルースクリーンが発生するなどで録画が失敗するリスクがつきまといます。

Ubuntuは自動アップデートなどの自動処理を抑止できる上に、コンソールを使ってファイル操作やログのチェックもできることから、UbuntuでTVサーバーを構築しています。

tsファイルのmp4変換とバックアップ

録画した番組を保存する場合、tsファイルをほかの媒体にコピーするだけで終わります。しかし、tsファイルは下記の点で保存・視聴には不向きです。

• 100時間で約76GBとなり、1年でTB単位でトータル保存ファイルサイズが増加するため、ストレージコストが高くつく
• スマホやタブレットへの保存（オフライン視聴）時に保存できる番組数が少なくなる
• tsファイルを直接再生できるプレイヤー・メディアサーバーが少ない
• CMや番宣など不要な部分が含まれているため、流し見に向いていない

この問題は、Amatsukazeを利用しCMを抜いたmp4ファイルに変換し、tsの代わりにmp4を保存することで解決できます。mp4に変換するとファイルサイズはおおよそ10-30%程度まで縮小できます。

ただし、mp4に変換するとtsファイルに記録されているオリジナルの字幕情報、ニコニコ動画のコメント、CMなどの付帯情報が消えてしまうため、これらを残したい場合はtsファイルも残しておく必要があります。また、録画予約当初は削除を前提としていても、後になってずっと保存しておきたくなることもあるので、tsファイルもしばらくの間は保持していたほうが安心です。

メンテナンスフリーのための自動処理の要件

録画したファイルを保存する際には、通常下記の作業を行います。

• SSD/HDD/NASの残容量確認と不要ファイルの削除
• CM抜きmp4ファイルへ変換
• NAS,HDDへのコピー

本システムはメンテナンスフリーを目的としているので、これらを自動で行う手順を実装する必要があります。変換、転送処理については処理分岐条件はないため自動化は簡単です。しかし、ファイル・フォルダの整理と不要ファイルの削除については、削除したいファイルとそうでないファイルを分けて考える必要がある上に、保存先のストレージ容量の制約もあります。

これらの制約を踏まえつつ、本システムでは次の方法で自動化しています。

不要ファイルの削除

EPGStationで録画したtsファイルの削除は、EPGStationの削除機能にまかせます。EPGStation以外からファイルを削除してしまうとEGPStationのデータベースとの不整合が発生し、トラブルの原因になるためです。

保存が必要なtsファイルは、自動削除処理が実行される前に外付けHDDへコピーして保存します。コピー先のディレクトリサイズが指定容量を超過していた場合は、指定容量以内に収まるまで更新日時の古いファイルから順番に自動で削除して容量オーバーを回避します。これにより、即削除によるファイルの喪失を防ぎます。最大ディレクトリサイズはディレクトリごとに定義できるようにします。

各録画ファイルへ適用する削除ルールは、EPGStationの録画予約時の保存先ディレクトリ指定機能を利用します。ファイル削除ルールごとにディレクトリを以下の4つに分け、録画時にこれらのディレクトリを指定して録画ファイルを自動で分類します。

• no_conversion: CMカットも変換も不要な番組（ニュースなど）
• delete: 一定期間保持する番組（バラエティ番組など）
• delete_after_watch: 視聴するまで自動消去しない番組（連続ドラマなど）
• keep: 再エンコードに備えてtsを残したい番組（映画など）

NAS上のmp4ファイルについてもtsファイルと同様のルールで削除し、コピー開始前にルールに従って削除します。

ファイル削除によって空ディレクトリもできるため、HDDコピー時に空ディレクトリも削除する処理を実行するようにします。

mp4ファイルへの変換

CMカット機能があるAmatsukazeを使用します。AmatsukazeはUbuntuに対応しているため、Ubuntu上で動作させます。

変換したmp4ファイルを格納するディレクトリはtsファイルと同じ構造を維持するようにし、管理の手間を省きます。ここでは/mnt/converted_filesに保存するものとします。

NAS・HDDへコピー

Pythonスクリプトで以下のように処理をします。

• tsファイル：直接接続された外付けHDDへコピー
• mp4ファイル： sftp経由でNASへアップロード

一度変換・コピーしたファイルは繰り返し同じ処理が走らないようにデータベースに記録し管理します。

ファイルをコピーする際には録画ファイルのディレクトリ構造を維持してコピーし、ファイル整理の管理の手間を省きます。

TVサーバー構築

必要なPCスペック

録画・再生だけであればN100等の低スペックPCでも可能ですが、Amatsukazeでの変換を裏で同時に行う場合はCPU性能が必要になります。

Core i9のミニPCをTVサーバーにして運用した場合、変換中に録画ファイルのDropは発生しておらず、1時間番組の場合ですと録画終了からNASへのアップロード完了までは10分程度で終わります。

N100の場合は同時録画をしている最中に変換処理をしているとDropが発生することがありますが、変換処理を深夜などの無録画時間帯で実行することで回避できます。

メモリは8GBでも問題はないですが、選択するCodecやアップデートによって使用メモリが増えることもあるので、Swap発生を抑えるためにも16GBは搭載していた方が安心です。

Ubuntuのインストール

インストールするPCによりインストール方法が変わるため、ここでの説明は割愛します。以下の記事などを参照してください。

• PC Watch：Ubuntu日和 【第38回】ノートPCでもUbuntuを使ってみよう！

EPGStation、KonomiTVのセットアップ

EPGStationとKonomiTVをUbuntuにインストールする方法は以下の記事にまとめていますので、こちらを参考にしてください。

ECDBは下記記事を参考にするとインストールできます。

【2023年10月】Ubuntu + Mirakurun + EDCB-Wine + KonomiTV (px4_drv + recisdb + ISDBScanner) でパパッと Linux 録画鯖構築の手引き

Ubuntu上で動作するAmatsukazeをセットアップする

Amatsukazeのインストールや設定は環境に大きく依存するので、マニュアルを参考にしてインストールしてください。

Amatsukazeのセットアップ後、最終的に以下のコマンドで変換キューに追加し、出力先にmp4ファイルができていればよいです。

$ /home/ユーザー名/Amatsukaze/exe_files/AmatsukazeAddTask -f <tsファイル> -o <出力先ディレクトリ> -ip localhost -s <プロファイル名>

変換が行われているかどうかはAmatsukazeのWebUI(http://localhost:32769)で確認します。

変換に失敗している場合はログを見て原因を探り解決します。

Amatsukazeはサーバー・クライアント型のアプリなので、PC起動時にAmatsukazeServer.shを自動実行し、Amatsukazeサーバーを起動しておく必要があります。これはcrontabに以下の記述を追加すればよいです。

@reboot cd /home/tv-recorder/Amatsukaze/Amatsukaze && ./AmatsukazeServer.sh &

自動処理用Pythonスクリプト

次のスクリプトは上記要件を取り入れたPythonスクリプトになります。Windowsでも動作すると思いますが、動作は未確認です。

https://github.com/sabalog/tv_server_on_ubuntu_with_amatsukaze/blob/main/TvRecorder.py

スクリプトは1ファイルに収めたので、処理内容の確認やカスタマイズはGeminiやCopilotなどを利用して解析・修正していく方法が良いと思います。

環境依存パラメータについては、ファイル先頭に定義されているConfigクラスにまとめていますので、環境に応じて変更してください。年末によく放送されている6時間級の長時間番組録画を考慮するとtsファイルの保存先の最大ファイルサイズはHDDの空き容量が100GB以上、mp4の保存先は25GB以上にしておくと安心です。

【重要】スクリプトにはファイル一括削除処理が入っているため、パラメーターを間違えたりバグによって意図しないファイルを削除することがあります。スクリプト利用の際には、DryRunで十分に動作を理解・確認してください。デフォルトで「dry_run: bool = True」としています。動作確認後にFalse設定にしてください。

このスクリプトを起動すると下記タスクを順次実行して終了します。

• Amatsukazeへ変換タスクを追加
• mp4をNASへコピー
• tsファイルをHDDへコピー・空ディレクトリの削除

処理対象のファイルがない場合は何もせずに終了します。常駐するタイプのスクリプトではないので、実行開始にはトリガーが必要になります。

実行開始のトリガーはcronを利用します。通常のテレビ番組は0,15,30,45分台に終了することが多いため、録画終了からできるだけ早く変換・コピー処理が始まるように、毎時1分を起点として3分おきに実行するようにします。下記はcrontabの設定例になります。

1-59/3 * * * * /usr/bin/python3 /home/tv-recorder/Scripts/TvRecorder.py

N100などスペックの低いCPUの場合は、録画中に変換処理が走っているとDropが発生することがあるため、変換実行時間を録画番組のない時間帯に限定してスクリプトを起動するように設定すればよいです。

このPythonスクリプトは以下についても考慮しています。

• 録画中のファイルは処理対象から除外する
• ニュースなど、長期に保持する必要がないファイルでHDD/NASの容量を圧迫しないように、最長ファイル保持期間をディレクトリごとに設定できるようにする
• HDDアクセスによるDropを避けるため、HDDへコピーする時間帯を制限する
• 変換・コピー処理のログをリアルタイムでログに保存し、コンソール上からもリアルタイムで動作状況を確認できるようにする
• ログの肥大化を避けるため、処理が行われない場合はログ出力しないようにする
• 実際のファイル操作無しで動作確認できるようにDryRunで動作確認できるようにする
• コピー処理実行時にはHDD/NASにコピー可能かどうかを確認し、コピーできない場合はHDD/NASが復帰したときに処理を再実行する
• 後でCMカット位置を変更できるようにtsファイルコピー時にカット位置を示す*.avsファイルも合わせて生成してtsファイルと同じディレクトリにコピーする(更新日付をtsに合わせています)
• 変換・コピー後にファイル移動などで再処理が走らないように、処理を実行したファイルをiniファイルに記録し、次回以降の処理でiniファイルを参照してスキップする

TVサーバー稼働後の運用とメンテナンス

KonomiTVはディレクトリ階層構造でファイルを管理できないため、ディレクトリ構造で整理された1000単位の数の録画ファイルを選択・再生するには不向きです。そこで録画直後の番組はKonomiTVで再生し、録画後のCM抜きmp4ファイルの再生や古いファイルはNAS上で動作するJellyfinなどのメディアサーバーを使って視聴します。

録画・変換したファイルは自動で削除されるので短い期間でNASやHDDの容量が足りなくなることはないですが、保存しておく録画ファイルが増えるとHDD/NASを圧迫してシステムが機能しなくなるため、保存するファイルのトータルサイズとHDD/NASの空き容量は、適宜チェックしておく必要があります。

録画予約時に保存するかどうか未定の番組については、いったん削除予定で保存しておき、保存対象になった時点で録画予約の修正と録画変更済みファイルをkeepに移動すればいいです。コピー処理が走らないので、作業はすぐに完了します。

tsファイルの整理はTVサーバーのHDDをSambaで公開状態にして作業するほうがRDPでUbuntuにリモートログインするより効率がよいですが、削除可能な状態で公開することになるため、誤って削除したときにも復帰できるようにゴミ箱機能を有効にしておきます。

sambaのゴミ箱機能を有効化する設定は以下の通りです。

[ts_files]
...
   path = /mnt/hdd/ts_files
   read only = no
   
   # ごみ箱機能を有効化
   vfs objects = recycle
   
   # ごみ箱のディレクトリ名（共有フォルダ直下に隠しフォルダとして作成される例）
   recycle:repository = .recycle
   # 同名ファイルがあった場合にバージョン管理する
   recycle:keeptree = yes
   recycle:versions = yesCode language: PHP (php)

CMカットのやり直し

Amatsukazeでtsファイルを変換するとき、tsファイルとavsファイルを同じディレクトリに置いておくことで、強制的にavsファイルの定義に従ってCMがカットされます。

avsファイルはテキストファイルでTrim(<トリミング開始フレーム>,<トリミング終了フレーム>)を「++」で連結することでCM位置がカットできます。以下は定義のサンプルです。

Trim(108,26601) ++ Trim(29299,44403) ++ Trim(48000,53124) ++ Trim(53575,54053)

CMのカット位置を変更する場合はこれらの数値を変更・追加・削除して、再変換すればよいことになります。

avsファイルはAmatsukazeのCMカット機能を使うことで生成できます。CMカット目的であれば十分な機能があるので、これを使うことがおすすめです。使用方法はAmatsukazeのマニュアルを参照してください。

そして下記スクリプトを実行すると、avsとtsファイルの更新日付が違うファイルをリストアップし、変換対象ファイルを選択すると、録画ファイルと同様の手順で再変換とNASへの転送を実行します。

https://github.com/sabalog/tv_server_on_ubuntu_with_amatsukaze/blob/main/TvRecorder.py

Amatsukazeアップデート

Amatsukazeは頻繁にアップデートされています。アップデートの際にはファイルダウンロード・プロセス停止・展開・コピー・プロセス起動の手順を実行する必要がありますが、手動では手順が煩雑です。これを自動化したスクリプトが以下になります。

https://github.com/sabalog/tv_server_on_ubuntu_with_amatsukaze/blob/main/Update.sh

スクリプト先頭の設定を環境に合わせて変更し、下記コマンドを実行すると当該のバージョンにアップデートされます。

# Update.sh 1.0.8.9

このスクリプトにはAmatsukazeディレクトリのバックアップ処理を追加しており、Amatsukazeのバージョンアップに伴い不具合が出た場合にこのバックアップを展開しなおすことでアップデート前の環境に戻せるようにしています。

参考になれば幸いです。

TVサーバーを動かしているUbuntu OSはディスプレイが不要なため、設定完了後はヘッドレスで運用しています。運用中のメンテナンスは、下記設定をONにしてWindows Remote Desktopで接続しています。

しかし、Ubuntuは画面出力をしてないとWindows Remote Desktopでの接続ができません。このため、下記のようなHDMIダミープラグを利用して画面表示状態をエミュレートする必要があります。

ところが、4K対応をうたった数百円程度のHDMIドングルはリモート接続時に選択できる画面解像度が2K(1920×1080)の次が4K(3840×2160)となるものがほとんどです。これでは、UbuntuのGUI操作をするには2Kでは画面が狭すぎ、4Kでは4Kディスプレイが必要でかつフルスクリーン表示にしないとドットバイドットで表示できないなど、解像度の選択肢が中途半端です。

2560×1440など2Kから4Kの間の解像度に対応したHDMIダミープラグもありますが、軒並み4000円以上する上に、4Kだとリフレッシュレートが20Hz以下になったりするなど使いにくい部分があります。また、これらの制限事項は商品説明には記載されていないため、HDMIダミープラグがリモート接続で快適に使えるかどうかは買って使ってみるまでわかりません。

この問題は、4K60Hzに対応しているHDMIダミープラグを購入し、下記の設定をしてメンテナンス用の表示解像度を増やすことで対応できます。

手順1：HDMIポートの名前を確認する

まず、UbuntuがHDMIダミープラグを「どの名前」で認識しているかを特定します。

$ ls /sys/class/drm/ | grep HDMI
card0-HDMI-A-1
card0-HDMI-A-2Code language: JavaScript (javascript)

HDMIポートが複数ある場合は複数の名前が表示されるので、下記コマンドでどのHDMIポートに接続されているかを確認します。

$ cat /sys/class/drm/card0-HDMI-A-1/status
connectedCode language: JavaScript (javascript)

connectedと出力されたらそのポートにHDMIダミープラグが挿してあることになります。

手順2：設定ファイルを編集する

設定ファイルを下記のように書き換えます。

$ vi /etc/default/grub
...
(修正前)GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
(修正後)GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=<HDMIポート>:<画面解像度>@<リフレッシュレート>"Code language: HTML, XML (xml)

HDMIポート名は”card#-“の部分を削除して指定します。以下は設定のサンプルになります。

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=HDMI-A-1:2560x1440@60"Code language: JavaScript (javascript)

手順3：設定を反映して再起動する

変更した設定を下記コマンドでシステムに読み込ませて再起動します。

$ sudo update-grub
done
$ sudo rebootCode language: Bash (bash)

すると下記のように2Kと4Kしか対応していないダミープラグでも任意の解像度を選択できるようになります。

接続しても設定した解像度が表示されない場合は、RDP接続時に解像度を直接指定すればよいです。

参考になれば幸いです。