TverRecを使って定期的に観たい番組を保存しておいて時間のある時に視聴しています。リアルタイムでTVに縛られるのは嫌だし、現実的に家に居ない時間の放送だとTVで録画しておく事になりますが、録画を忘れてしまうこともあります。もし視聴を忘れてしまった場合にはTverで見逃し視聴出来るわけですが、それも1週間が限度です。やはりTverRecで確保しておいて後でまとめて視聴出来るのは便利です。
いつもノートパソコンにインストールしたLMDE6環境を主に使っていて、TverRecもそれで処理させています。ノートパソコンのSSDに動画を溜め込むのは嫌なので、外付けHDD（USB-HDD）を接続してHDDを保存先にしています。
エラー発生：番組ダウンロード先ディレクトリが存在しません。
今日、TverRecを実行させると「保存先がみつからない」というエラーに遭遇しました。USB-HDDは認識されているのになぜ？
aoipuchu@letsnote-lmde:~/デスクトップ/TVerRec-master/unix$ ./start_tverrec.sh
⣴⠟⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠻⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣦
⣿⠀⠀⣿⣿⣿⣿⡿⠟⠛⠛⠛⠛⠳⢦⣄⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⠀⠀⣿⣿⡟⠁⠀⠀⠀⠀⠀⠀⠀⠀⠈⢳⣄⠀⠀⠀⣿⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⠀⠀⠀⠀⠙⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⠀⠀⣿⠏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠹⣆⠀⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣦⠀⠈⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⠀⠀⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⠀⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⡟⠁⣀⣀⠈⢻⣿⠀⠋⢀⣀⡀⠙⣿⠀⠀⣿⣿⣿⠟⠀⢀⣿⡟⠁⣀⣀⠈⢻⣿⡟⠁⣀⣀⠈⢻⣿⣿⣿⣿
⣿⠀⠀⣿⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⠏⠀⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⠀⠀⣿⠀⠾⠿⠿⠷⠀⣿⠀⣾⣿⣿⣿⣿⣿⠀⠀⠀⠀⠀⠀⣠⣿⣿⠀⠾⠿⠿⠷⠀⣿⠀⣾⣿⣿⣿⣿⣿⣿⣿⣿
⣿⠀⠀⣿⣿⣧⡀⠀⠀⠀⠀⠀⠀⠀⠀⢀⡼⠋⠀⠀⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⣦⡀⠈⠻⠟⠁⢀⣴⣿⠀⢶⣶⣶⣶⣶⣿⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣧⠀⠘⣿⣿⠀⢶⣶⣶⣶⣶⣿⠀⢿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⠀⠀⣿⣿⣿⣿⣷⣦⣤⣤⣤⣤⣴⣾⠋⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣿⣿⣿⣦⡀⢀⣴⣿⣿⣿⣧⡀⠉⠉⢀⣼⣿⠀⣿⣿⣿⣿⣿⣿⠀⠀⣿⣿⣿⣧⠀⠘⣿⣧⡀⠉⠉⢀⣼⣿⣧⡀⠉⠉⢀⣼⣿⣿⣿⣿
⣿⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⠙⢷⣄⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⠻⣦⣤⣿⣿⣿⣿⣿⣿⣿⣿⣤⣤⣤⣤⣽⣷⣤⣤⣤⣴⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟
Version. 3.4.7
✅️ yt-dlpは最新です
Local version: 2025.04.30
Remote Version: 2025.04.30
✅️ ffmpegは最新です
Local version: 7.1.1
Remote Version: 7.1.1
💡 日本のIPアドレスを割り当てました: 122.145.172.19
Write-Error: /home/aoipuchu/デスクトップ/TVerRec-master/src/loop.ps1:76
Line |
76 | & ('{0}/download_bulk.ps1' -f $script:scriptRoot) $script:guiMode
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Error occurred: ❌️ 番組ダウンロード先ディレクトリが存在しません。終了します
Write-Error: /home/aoipuchu/デスクトップ/TVerRec-master/src/loop.ps1:76
Line |
76 | & ('{0}/download_bulk.ps1' -f $script:scriptRoot) $script:guiMode
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Stack trace: at Invoke-TverrecPathCheck,
| /home/aoipuchu/デスクトップ/TVerRec-master/src/functions/tverrec_functions.ps1: line 296 at Invoke-RequiredFileCheck, /home/aoipuchu/デスクトップ/TVerRec-master/src/functions/tverrec_functions.ps1: line 335 at <ScriptBlock>, /home/aoipuchu/デスクトップ/TVerRec-master/src/download_bulk.ps1: line 81 at <ScriptBlock>, /home/aoipuchu/デスクトップ/TVerRec-master/src/loop.ps1: line 76
Exception: /home/aoipuchu/デスクトップ/TVerRec-master/src/functions/tverrec_functions.ps1:296
Line |
296 | else { throw ($script:msg.NotExist -f $errorMessage) }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ❌️ 番組ダウンロード先ディレクトリが存在しません。終了します
Completed ...
aoipuchu@letsnote-lmde:~/デスクトップ/TVerRec-master/unix$ Code language: JavaScript (javascript)少し注意して保存先に該当する外付けHDDの状態を確認すると、USB-HDDのラベル名が自動的に変更された様で、いつものラベル名の後ろに1が付加されていました。これが原因だったのか。
TverRecの動画保存先指定
TverRecでは動画の保存先を「conf/user_setting.ps1」というファイルで設定しています。これは初回に「system_setting.ps1」ファイルをコピーするなりして、
$script:downloadBaseDir = '/media/aoipuchu/HDD-1TB/Tver'
$script:downloadWorkDir = '/media/aoipuchu/HDD-1TB/Tver/Temp'
$script:saveBaseDir = '/media/aoipuchu/HDD-1TB/Tver/complete'Code language: PHP (php)という感じで設定しています。
私の場合は1つのUSB-HDDストレージしか使っていないので、この辺りは結構適当にやっていますが、物理的に別々のストレージを併用している場合なんかには効果的だったりしますね。読み書きが速いストレージで処理をさせて、完了したファイルをアーカイブ用のストレージに移すとか。
今回のトラブルの状況
ここで今回問題になったのは、
HDD-1TBというラベル名のUSB-HDDです。
Linux Mintの場合はUSB-HDDを接続すると自動的に/media/USERNAME/の下にストレージのラベル名でマウントしてくれます。そして自動的にデスクトップにアイコンが現れます。2回目以降接続しても同じラベルを使用したマウントポイントになるので、TverRecの設定も変更せずにずっとそのまま使用できていました。
/etc/fstabでマウントはしていません。
今日、デスクトップにアイコンが表示されて、USB-HDDはマウントされている状態でした。そしてTverRecを実行したところ「保存先がみつからない」というエラーが表示された訳です。
よくよく確認してみると、
/media/aoipuchu/HDD-1TB
/media/aoipuchu/HDD-1TB12つのマウントポイントが出来ていました。そして今まで使っていた方にはアクセス出来ずRoot権限を求められます。これは確かに何時もと違う変な状況です。エラーの原因はここにありそうです。
Linuxのストレージ識別の仕組み（UUID）
Windowsの仕組みは調べたことが無いので良くわかっていませんが、Linuxの場合はストレージのファイルシステムを作成した場合に、UUIDというユニークなアドレスが割り当てられます。同じUSBポートに別のストレージ（USBメモリーなど）を接続してもキチンと別のデバイスだと認識される理由はUUIDが重複しないように割り当てられる仕組みの理由です。
今回、何かしらの原因でUUIDが変更になってしまい、別のデバイスだと認識されてしまったと思われます。USB-HDDなので抜き差し頻度が高いこともあり、ファイルシステムに何かしらのトラブルを生じてしまった可能性がありそうです。fsckが裏で走ってトラブルを解決してくれた可能性はあります。
Linux Mintの場合は、ストレージのファイルシステムにラベル名「HDD-1TB」と命名しておけば、マウントポイントにラベル名を使用する様です。というよりファイルマネージャ（nemo）がやっているのかも知れません。
今回、ラベルは「HDD-1TB」のままでしたが、実際にマウントされているPATHが変わってしまっている事に気づきました。問題はこれをどこに記憶しているのか？どうすれば元通りに戻せるのか？というところです。
Google Geminiに聞いてみた
状況は把握できたので、Google Geminiに相談してみることにしました。人間よりAIの方が色々な情報を持っているので手っ取り早いです。検索するとブログなどに書いてくれている人もいると思いますが、状況がわかったのでAIを頼ったほうが近道だと考えました。
Geminiの回答はいくつかありました。
まず今回のトラブルが起こった原因は、USB-HDDのファイルシステムに何かしらの不具合が生じてファイルシステムのチェックと修復だろうと思われます。この回答が一番しっくり来ました。他の回答も的を得ていてなるほどそういうケースも有るのかと勉強になりました。
同じラベル名「HDD-1TB」が別々のUUIDでマウントされたため、OSが別のデバイスだと認識してマウントポイントを変更したものと思われます。実際、後ろに1が付加されただけの機械的な対応だったので腑に落ちます。
lsblkコマンドでuuidを確認する方法も学習しました。
aoipuchu@letsnote-lmde:~$ sudo blkid /dev/sdb1
[sudo] aoipuchu のパスワード:
/dev/sdb1: LABEL="HDD-1TB" BLOCK_SIZE="512" UUID="3CD3BF5C12C00EA6" TYPE="ntfs" PARTUUID="e837ee6a-01"Code language: JavaScript (javascript)Geminiに教わらずとも、lsコマンドでシンボリックリンクを確認する方法は知っていました。いずれの方法でもUUIDの確認は可能だと思います。
aoipuchu@letsnote-lmde:~$ ls -al /dev/disk/by-uuid/
合計 0
drwxr-xr-x 2 root root 120 4月 27 19:40 .
drwxr-xr-x 9 root root 180 4月 27 19:40 ..
lrwxrwxrwx 1 root root 10 4月 27 19:40 3CD3BF5C12C00EA6 -> ../../sdb1
lrwxrwxrwx 1 root root 10 4月 27 19:15 98f20f79-8adb-4027-aa49-548dd221943e -> ../../sda2
lrwxrwxrwx 1 root root 10 4月 27 19:15 F7FD-2BD0 -> ../../sda1
lrwxrwxrwx 1 root root 10 4月 27 19:15 e03dea8c-1b33-4d68-a442-25c27a9466f7 -> ../../sda3いずれかの方法で現状のデバイスのUUIDを確認することは出来ます。
マウントポイントを戻す方法
大した手間では無いのですが、TverRecの保存先の設定を変更するのは嫌だなと考えました。後ろに1がついただけじゃないかと思う人もいるかも知れませんが、ラベル名を使っているのにマウントポイントが違うというのはスッキリしません。
そこで、全てのUSBデバイスを取り外した状態で、/media/aoipuchu/をファイルマネージャ（nemo）で表示させました。ここに作成されているマウントポイント（HDD-1TB、HDD-1TB1）を両方とも削除してしまい、改て自動でマウントポイントを作成させることにしました。削除するにはRoot権限を使う必要がありました。（ちょっと要注意な作業です）
マウントポイントを削除したら、Root特権になっているファイルマネージャ（nemo）を終了させます。危険ですからね。
そして、USB-HDDを改めてUSBポートに接続すると、自動的にマウントされました。元通り/media/aoipuchu/HDD-1TBというマウントポイントになりました。
大丈夫そうなので、TverRecを実行させてみるとエラー表示も無く処理が走り出しました。無事に完了しました。
最後にまとめと次回の課題（宿題）
今回、おそらくUSB-HDDのUUIDが変更になったことで、自動マウントポイントが変更されてしまった訳ですが、「それをどこで管理しているのか？」という疑問が残ります。何かしらの方法で（ファイルとして）残しているハズなのです。
Windowsならレジストリに残されている感じの管理情報です
対処方法としては、先述の通り「/media/aoipuchu/HDD-1TB」を削除して解決させたのですが、仕組みを知っていればより多くのトラブル対応が可能となり、それはスキルとして身につきます。同じことがまた起きるかも知れないので、対処方法はコレでOKだけど・・という意味合いも込めて記事に残しておきます。
次回発生時は、対処方法は分かっている前提で、どこでUUIDとマウントポイントの紐付けを管理しているのか？を追求したいと思います。この記事はそのための記録です。
コメント