Closed tkmsst closed 3 years ago
再現するか確認してみます。
recordedTmp から移動する処理が正常に機能していないことがわかりました。 修正します。
再現環境の不備で recordedTmp の処理が正しく動いていませんでした。 そのため、再度再現実験したところ正常に機能することが確認できました。
recordedTmp からの移動に失敗した際にエラーが operator の system.log に残っているはずなので、それを見せていただけますか?
情報が小出しになってしまい申し訳ありません。 詳細に調査を行いましたので報告いたします。
まず、ユーザーとして以下の2つ作成し、同じグループ(raspiG)に所属させています。
raspi (sudoer)
epgstation
また、EPGStation(プログラム)は下記の設定です。
gid: raspiG
uid: epgstation
ここで、recordedTmp:'%ROOT%/recorded'はepgstation(raspiG)がオーナーであり、recorded:'/mnt/NAS'はraspi(raspiG)がオーナーになっています。'/mnt/NAS'のパーミッションは770に設定しているため、epgstation(raspiG)も'/mnt/NAS'に読み書きできる状況です。 よってEPGStation(プログラム)も'%ROOT%/recorded'と'/mnt/NAS'の両方に読み書き可能です。 しかし、epgstationは'/mnt/NAS'のオーナーではないため、仮にconsoleから
mv %ROOT%/recorded/xxx.ts /mnt/NAS
とすると、操作(移動)は完了するものの
preserving permissions for xxx... Operation not permitted
preserving times for xxx... Operation not permitted
のエラーが表示されるため、これが原因かと思われます。 結果として、EPGStationのbugとも言えないものでした。
調査ありがとうございます。
node の fs.copyFile
でファイルをコピー後削除しているのですが、まずコピーの時点でエラーが発生しているのかなあと思います。
v1 でもその構成で動かしていましたか? もしそうなのであればファイル移動処理が v2 から変化したことが原因かと思われます。
v2 では標準の fs.copyFile
を使用してファイルをコピー(その後削除)しているのですが、
v1 では fs-extra を使用してファイルをコピーをしています。(主に古い node への対応のため導入していました)
もし v1 で正常に動いていたのであれば fs-extra を導入して v1 と同じ挙動をするように変更します。
v1の時でrecordedTmpを試したときは、ちょうど環境を変えて問題があったもので、あまり検証できてませんでした。
ただ、これとは別の問題で、何らかの理由により予約録画が開始されなかった場合にエラー等にはならず、あたかも最初から予約がなかったようになります。
ネットワークが不安定な状況下で同時録画をいくつか試しているのですが、録画が開始されずに予約が消えてしまったり、ごくまれに「録画中」のままになって残ったりしているようです。さらに検証してみます。
現時点ではrecordedTmpが正常に機能していることを確認しましたので一旦closeします。
環境
2.0.3
0.16.1
14.15.4
6.14.10
Issue
... 下記の設定において録画ファイルが%ROOT%/recordedに作成されますが、録画が完了してしばらくたっても/mnt/NASディレクトリにファイルが移動しません。
なお、recordedTmpの行を削除すると録画ファイルは/mnt/NASに作成されます。(正常動作)