Linuxでテレビ総合スレ 避難所 2
■ このスレッドは過去ログ倉庫に格納されています
>>282
私もBS-TBSの野球中継で同様の事が起きました。
環境はpt3 + dogeel版recdvb + mirakurun + chinachuです >>282
続き
この状態でmirakurunのプロセスを再起動して適当な番組を録画すると、
数分で録画が止まり同じようにmirakurunが暴走した
マシン自体を再起動すれば治ったのだが理由がよく分からん
recpt1が腐っていたのだろうか?それともnodeには重たい作業なのか いまbs-tbs録画してみたら暴走した
epgがmirakurunとの相性が悪いのか? recpt1 BS01_1 180 bs-tbs.ts
で取得したtsをmirakurunのepgdump.jsに食わしたら
reading - 85786624 of 389644288 [22%] (events=3685)
とでて止まった。
cpu使用率が100%で症状がまんま同じ
node-aribts のバグかなあ inspect でデバッグしてみたら node-aribts の char.js の readC1 関数で止まっているみたい。
これのどこで止まっているのかなーと調べてみたら
case 0x95:
// MACRO
while (this.buffer[this.position] !== 0x4F) {
this.position++;
}
この while で止まっているのが分かった。
が、char.js って一体何をしている部分なのか分からんから修正できないお while (this.buffer[this.position] !== 0x4F && this.position < this.buffer.length)
とかにすれば無限ループは回避出来そうだがARIB文字のデコードがちゃんと出来るのかはわからんな それでいいみたい
url で ng 出るから "ARIBにまともな資料を求めるのは間違っているだろうか" でググってくれ
これによれば
> ※番組名や番組表の解析のみ行う場合は、以下のピンク色のコマンドのみを実装し、
> それ以外のコマンドはパラメータとともにスキップすれば問題ありません
とのことらしいので問題ないのかな?と思います。 > パラメータとともにスキップすれば問題ありません
このパラメータっていうのが気がかりだけど、
仮にだめでも多少番組情報の文字列のデコードに失敗する程度だし止まるよりはマシかな マクロ定義文が0x95 0x40または0x41から始まって0x4Fで終わるのでそれをスキップしようとして失敗ということか mirakurun/node_modules/aribts/lib/char.js にその修正をして録画させてみているけど
今の所暴走せず動いている 該当のバッファの中身はこんな感じ
21 5a 4e 39 3f 4d 21 5b 95 2e 1b 7e 89 cd 8a 45 44 1b 7c de ea 21 5a ca ec 21 3c bf 21 3c 21 5b 4a 21 38 36 1b 7d ab c4 df fe 3c 6e 4c 5a ce be df
0x95 はあるがその後に0x4Fは無いし、その前にあるはずの0x40 or 0x41も無いので根本的に解決するには別の箇所の修正が必要ですね。 お取り込み中邪魔をして申し訳ないのですが、
https://github.com/gcch/Chinachu-Mirakurun-SS
こちらのスクリプトで定期スタンバイ(ハイバネート)をやろうとしたのですが、
/etc/cron.d以下に配置されるファイル(chinachu-mirakurun-ss-cron)の中身の記述が無いようで、
cronがうまく作動しません。
どのような改造を加えたらうまく動くようになるのでしょうか?
どなたかうまく動いている方がいらしゃったらお教えいただけると幸甚です。 たぶん(ARIBの文書には書いてないけど)MACRO の直後のP1が40/41/4fで無い場合は
事前のMACROで定義済のMC(マクロコード):P1を"実行する"ことになってて
マクロコード2eは事前に定義した1バイト外字(DRCS)をG1に指定するマクロなんだと思う
21 5a 4e 39 3f 4d 21 5b => '【旅人】'
95 2e => MACRO ????
1b 7e => LS1R (1B外字??)
89 => MSZ 文字サイズ中
cd => '濱'の外字版?
8a => NSZ 文字サイズ標準
45 44 => '田'
1b 7c de ea => 'マリ'
21 5a .... => '【ナレーター】'.... 自己解決しました。
使ってるディストリがdebianなのでcrond.serviceではなくcron.serviceが使われていたことが原因でした。
install.shのcrondのところをcronにしたらetc/cron.d以下にちゃんと中身のあるファイルが生成されました。 chinachu sleep scriptでまだ不可解なことがあるのですが、
debian stretchでxfce4+lightdmでログオフして放おっておいてもハイバネートに入ってくれないんですが、
ログオフってwhoで誰も表示されない状態ならいいんですよね?
あとdebianでは/etc/cron.d以下にファイルが作られるだけではだめで、/etc/crontabかrootでcrontab -eして
cronのコマンドを書き込まなければならないみたいです。 >>295
おーなるほど
ちなみに何を参考にしてその仕様がわかったの? ラズパイ+さんぱくんで録画してますが2.5インチ500GBでは心許無くなってきました
3.5インチ外付けケースを買おうと思いますが、エコモードや電源連動的なものはchinachuの"operRecOffsetStart"で開始時間を早めにとれば上手く作動しますか? >>298
ARIB-STD B24 1/3 (とISO 2022)から推測したよ
BS-TBSの番組情報の符号化した人はどうかしてると思う
・そもそも’濱'の字は普通の漢字集合で含まれててわざわざ外字を使う必要がない
・'ナレーター'の長音符号をわざわざカタカナでなく漢字集合の奴を使っている
・外字なんてそんなに頻繁に使わないんだからマクロなんぞ使用してちまちま節約しなくても
普通に外字集合をG0..G3のどれかに指定・呼び出して2e or aeでいいのに...
・そもそもVBIを使ってた時代じゃないんだからマクロなんかで節約する必要がない
Mirakurunは使ってないけど実装面では >>288 のようにバッファ長をチェックするだけでなく
MACRO(95)の直後の1バイトを呼んで
40か41の場合のみ4fまで(あるいは次のMACROの手前まで)読むようにすれば
捨てる部分が少なくて済むと思う lightdm.confのautologinuser=のところをコメントアウトした後、ログアウトしたら
ちゃんとハイバネートしました。
どうもお騒がせしました。 >>300
おーさすがです
教えてくれてありがとう ラズパイ+chinachuで録画して、androidtv(mibox)のkodiで見てますが、生tsをwifi経由で見ている為か若干フレームレートが遅い気がします。
Wifiが5Ghzなので十分だと思ったんですが…
有線lanポート買ってandroidtvを繋ぐか、
ラズパイを辞めてサーバーpcを新調し、エンコードして飛ばすか悩んでいます。
どちらがいいとおもいますか? >>299
これで正しいのかわかりませんがラズパイでエコ機能付き外付けhddを使用したところ、
error: TSFilter will closing...
で録画失敗しまくりでした。
別途USBメモリにスワップを置いて、mirukurunのnode_argsでバッファを増やしたら解決しました。 フレームレートが遅いというのがよく分からんが
Wi-Fiの転送速度か足りない、が原因で確定なの?
もう少し切り分けした方がよくね?
ローカルにファイルを置いたらどうかとか、別のNASとかに置いたらとか
スループット計ってみるとか win環境からmirakrun+chinachuに移行したけど、edbc比較でいろいろ不便だわ
リアルタイム視聴のレスポンスと予約システムが特に糞 フレームレート云々が意味不明かな
SMB経由?でkodiで見るのにWiFiの帯域が足りないなら、画面が粗くなるとかじゃなくて止まって読み込み待ちになるだろう
tsの帯域が12Mとか16Mだから、それを通せない宅内WiFiが非力すぎると思う
例えばAndroidTVで他の配信サービス使うにも難渋するのでは
それを回避するのに自宅内でトランスコードするのはいかにも筋が悪く、WiFiを改善させるのが最優先では >>308
edcbのリアルタイム視聴ってtvtestでの視聴でしょ?
chinachuはトランスコードしているから遅くなるのは当たり前よ
クライアントがwinならtvtestで見たほうが使い勝手ええよ
予約周りはスケジューラが動かないとチューナー不足が分からない仕様だから、それが嫌ならepgstationを試すべき
まあ、予約設定の細かさでedcbに勝てるソフトはないな >>308
さすがにリアルタイム視聴はChinachu経由じゃなくMirakurun直接だよな?
直接使うのに比べると遅くて予約は微妙だけど そしてsoftcasのソースが見当たらん
win上にmirakurun+edbcで作り直すかなー >>311
そこはコンパイルしてmirakurun直接 edcb使うならBonDriverProxyEXでええやろ
mirakurun使う意味がないどころか無駄に負荷がかかるだけ bondriver_mirakurunのチャンネルにNHKEテレ1,2,3と表示されるの
NHKEテレ1のみに出来ませんかね? >>315
TVTestの話?
古いバージョンしか使ったことないので違うかもだけど、
設定でチャンネルスキャンすればチェックボックスで表示、非表示変更出来たと思う。 【PINE64】パイン64 part2【ROCK64】
http://mao.5ch.net/test/read.cgi/linux/1513583078/278
278 名前:login:Penguin[sage] 投稿日:2018/07/28(土) 17:09:45.43 ID:1BqDkOOE
PCIe x4スロット搭載のシングルボードコンピュータ「ROCKPro64」が入荷
2018年7月28日 00:00
https://akiba-pc.watch.impress.co.jp/docs/news/news/1135312.html
PCIe x4スロットを搭載したPINE64のシングルボードコンピュータ「ROCKPro64」の
メモリ4GBモデルがテクノハウス東映に入荷した。
ただし、初回入荷分は28日(土)に売り切れ。次回入荷は8月を予定している。
ヒートシンクとケースとのセット品で、店頭価格は税込13,900円。
このほか、オプションの64GB eMMCモジュールとUSBアダプタのセット
「PINE64 64GB eMMCモジュールキット」も販売予定だ。
ただし、同店は「ノンサポート商品」としている。店頭価格は税込5,900円。 Chinachu MirakurunでNHKの録画ファイルが度々0Kbになるんだが px4_drvの作者です
T1->T0の順に開いたときに発生するドロップ対策として、T1を開いた際にT0のR850のレジスタにUHF 13chの設定値を書き込むようにしてみました
恐らくドロップせずに動いてくれると思います
ついでにチューナーを操作する際のパフォーマンスを向上させました
ただ、動作が速すぎて録画開始時のCN値が低めに表示されたり、tsの頭のパケットが乱れたりするかもしれません px4_drvの最新版で同時に複数のチューナーを開いたりチャンネルの設定を行うと、デバイスとの通信が失敗することがあるようです
そのため、最新版への更新は控えていただくようにお願いいたします
原因は恐らくロックの粒度を細かくしすぎたためだと思われます
動作確認不足でした 申し訳ございません mirakurunではT1T0問題は回避できることは>>269あたりで解決してるし、recpt1側でも順序制御できることは>>239で判明してるから、そんなに重要度高くないと思う
安定性の方が大切かな >>331
ずっと以前に>>219でも指摘されてるけど
T0開始 -> T1開始 -> T0終了 -> (T1継続中) -> T0開始
の場合はどうするわけ?
具体的には、例えば
1. 19:00-20:54の番組
2. 20:00-21:54の番組
3. 21:00-21:54の番組
この3つを録画したい時、普通にやれば1番目と3番目がT0になり、3の録画開始時にT1->T0が発生する
そう状況は普通にあるから、解決する必要があると他の人は認識しているんだけど >>333
その場合T1ドロップしない、T1→T0のドロップが発生する条件はT0とT1の両方が閉じた状態から
T1→T0の順番で開いた場合にT1がドロップする、だから例に出した条件だとT0とT1が両方とも閉じた状態には
ならないのでドロップは発生しない >>219も>>331も俺だが、それは>>222で解決済
その後「順序強制するシェルを噛ますか」「recpt1に順序を任すか」「いやmirakurunに任せても大丈夫」ってのがここまでの流れ
「T0T1とも停止状態から」がdrop発生条件なのはそれこそ共通認識と思ってたが >>333
他の人は解決済みであると認識しているよ そういう輩はきっと元気を分けてもらいたいやつだな。無視でいい >>281 のスレの745以降 の問題が本家でも解決されていないままなので
linuxのドライバにもそれが持ち込まれてるってことなのかな... それ書いたの自分だけど、Q3PE4でその症状出るのたぶんWindowsだけ
今の所自分で確認してるのはBraswell系とApollolake系のCPU使ったマザーのオンボードUSB使ったときに出る
断言できるほどテストしてないけどWindowsだと発生する構成そのままで、
公式で配ってるLinuxドライバとかfoltia Anime Locker使って試したときは出なかったから
(出ると4桁5桁ドロップするからすぐわかる)px4_drvでもたぶん出ないんじゃないか?
Q3U4もLinuxにしたらD0とD1開くと出る症状が出なくなったとかどっちかのスレで書いてる人が居たのを見た覚えはあるから
再度試験するかと思いながらも準備だけして放置してる、正直試験は時間掛かるからめんどくさい Raspberry Pi 3B+とさんぱくん、PX-S1UD、EPGstationで環境を構築中です。システムはSDでbooしてrootはUSB HDDのsda1にあります。
立ち上げた直後は問題なく動作(EPGstationへのwebからのアクセス、ファイル共有、SSHアクセス)するのですが、しばらくほっておくといずれもアクセスできなくなります。
cronで29分おきにsda1を見るようにしたら問題なく放置しても動くようになったので、USB HDDの省電力機能(ハードウエアでのHDDスピンダウン)が効いてしまっているようです。
HDDの省電力機能を活かしつつ随時アクセス可能にする方法をご存じの方いませんか? EPGStationには録画前に任意のコマンドを実行する機能があるらしい(使ってないので詳しくはわからん)
https://github.com/l3tnun/EPGStation/issues/88
rootを外付に置くというのは個人的に気持ち悪いと思うが >>342
同じ様な感じになりましたね。かなり前のこと(Raspberry Pi2)なので
詳しい経緯は記憶にないのですが、以下の(1)から(3)の様な対処方法を
考えて結局(3)を選択しました。Raspberry Pi は Kodi 専用に。
参考にはならないですが。
(1) USB HDDケースを取り換えてみる
ttps://jyn.jp/raspberrypi-usb-boot/ 追:たまに相性の悪いHDDケースがある
(2) システムはSD、USB HDD は録画ファイルのみを保存
(3) Raspberry Pi をやめる システムをhddに持って行かねばならん理由がよく分からん mirakurun + epgstationってraspberry piで実用的に動くの?
荷が重すぎるような気がするが 皆さん有り難うございます。システムをSDにしない理由はSDの書き込み上限を嫌ったのが理由です。
普通に考えればrootはSDに置くべきなのでしょうね。すなおにSDにします。
raspberry piが実用かどうかはepgstationにどこまで求めるか次第です。数カ月まえにraspberrypi2+PX-S1UD+2.5inchHDDの構成でepgstationを導入したものも運用中ですが、録画とその後のハードエンコだけならいけます。
しかし、ストリーミングは無理なので視聴はsmb経由かmini DLNA経由になるのと、2週間くらいでハングすることがあるのでたまに再起動させています(原因不明)。
これのHDDは古いタイプのものなので自動のスピンダウンはありません。また、Raspberryの電源供給だけでは動かないので二股ケーブルで電源供給をしています。 ラズパイで、さんぱくん+mirakurun+chinachu運用安定してるんたが
epegwstationって、そんなにいいの?
省電力機能はchinachuで開始を5秒早めることで録画失敗しないようにしてる chinachu γは開発が終了してリクエストにも対応する気がないみたいなので。
( https://github.com/Chinachu/Chinachu/issues/344 )
それと、家族にスマホ越しに操作させるにはEPGStationのほうが便利そうな気がする。
録画単位でフォルダー分けができたり、録画後の処理もあるていど選べる。
その他、予約前後、録画前後のコマンドが使えたりとか。 開発活発だしモバイルで使いやすい
こないだ付いた録画時Dropチェック機能は有り難い chinachuはもうあまり期待はできないかも
中の人は本業が忙しいんじゃないのかな
airって開発してるのかな
epgstationはコミット履歴を見ると活発に開発進行中だね
スマホファーストでスマホの人は使いやすいと思う webインターフェース在れば、アパッチ立てたらスマホから操作とか対象ソフトは何でも良いだろ 認証必要ならアパッチ側で出来るし、秘匿必要ならhttpsにも出来る アパッチ万能説おじさんワロタ
職場にいたらザ・老害って感じですね 認証や暗号化はリバースプロキシのことを言ってるんだろう
うちもnginxでやってる
もっとも誰もそんな話してないんだけどね chinachuはモバイルだと特に番組表がね...
それよりmirakurunでたまに番組情報が欠けるのをどうにかしてほしい
nhkでたまに起こる なるほど、開発改善とモバイル対応でepegstation流行ってるのね
定期録画だけでモバイルとか使わないからあまりchinachuに不満を感じなかった
というか、ラズパイで検索するとchinachuばかりだったのでスペック的な問題なのかな >>351
Drop数ってどうやって使うの?
環境へんすうから呼べないみたいだけど >>362
configでisEnabledDropCheckをtrueにすると、録画ファイルと同じ場所にログファイルが作成される
俺は録画後コマンドでログを自分にメールするようにしてる epegstationは番組表からの一発ルール登録が出来たらいいんだけどな >>364
一発ではないけど、番組、検索、追加の順でクリックするのでダメなの?
大抵ルール条件を修正して追加するからそれで良いなと思ってる。 >>365
ああ、この画面の下部ってルール追加なのか
単なる予約だと思ってた 最近使ってないけど
重複時に何と重複してるかわかるようにして欲しい。ボタン押すと同じ時間に入ってる予約をサービスに関わらず列挙してくれるだけでいい
あとルール表示の際にタイトル順、登録日順、チャンネル順などで並び替えして、そこからルールの一括削除や保存時条件変更したい ラズパイのハードエンコって実時間の何倍かかるの?3B+だと早い? >>368
デコードとエンコード両方をHWアクセラレーションでやると、最速では実時間の1.1倍くらいで終わるようにはなった記憶がある。けどハードウェアエンコードの画質はかなり残念な感じなので期待しないほうが良い
自分は許容できないと感じてソフトエンコに戻した 七森中録画研究会って新刊出さなかったんだな
Chinachuが衰退したからか? 前から今回は出さんって言ってたやん
まあ、開発進んでいないしネタがないんでしょ recpt1 + px4_drvの環境でrecpt1が固まる現象があって困っています。
Mirakurun多段で複数getEPG中などチャンネルを早く移動させると出やすいみたいで
症状が出るとdmesgにこんなエラー吐いてrecpt1がkillできなってしまう
https://pastebin.com/Bawst5E7
[ 960.430745] INFO: task recpt1:1368 blocked for more than 120 seconds.
(略)
[ 960.431292] [<ffffffff81850fc9>] __mutex_lock_slowpath+0xb9/0x130
[ 960.431301] [<ffffffff8185105f>] mutex_lock+0x1f/0x30
[ 960.431322] [<ffffffffc0624368>] px4_tsdev_stop_streaming+0x58/0x150 [px4_drv]
[ 960.431339] [<ffffffffc0625a9b>] px4_tsdev_unlocked_ioctl+0x10b/0x620 [px4_drv]
環境:ubuntu 16.04 + recpt1 (stz2012 最新) + px4_drv (最新)
どなたかアドバイスいただけないでしょうか。 作者さんもよくここ見てるみたいだけど、githubの方に報告してはどうだろう >>372
作者です
ソースコードを確認したところ、デバイスファイルの解放時にデッドロックを引き起こす可能性のある箇所がありましたので修正しました
いかがでしょうか >>373
githubの使い方よくわかってなくて、、、勉強しておきます。
>>374
早速の対応ありがとうございます。
3時間ほどテストしてみましたが、現象がでなくなりました。
このお盆で環境がLinuxに移行できそうです。
めっちゃ助かってます!!! >>368
369と別の人です。ラズパイのH/W Encode/Decode 有効にしたffmpegで
ffmpeg -fflags +discardcorrupt -c:v mpeg2_mmal \
-i "$1" \
-c:a copy -bsf:a aac_adtstoasc \
-c:v h264_omx -vf scale=-2:1080 -b:v 3000k \
-y "$output_mp4" > "$output_txt" 2>&1
ttps://dotup.org/uploda/dotup.org1613198.mp4
https://dotup.org/uploda/dotup.org1613213.txt
滝のシーンがヒドイ出来 書き忘れ
MP4ファイルは90秒、3Mbps、35MB程。 >>376 で張ってくれてるのを見れば一目瞭然だけど、ラズパイのhwエンコーダで出力される動画はファイルのサイズに比して非常に画質が悪いと思う
ビットレート上げればましにはなるんだけど相当大きな値にしないと鑑賞に耐える品質にならず、結局tsから変換する意味はあるのか?と虚しくなる… chinachuみてぇにスマホ向けのリアルタイムトランスコードぐらいかねぇ使い道 >>369によると1.1倍速程度ってことだからカツカツだな 読み間違えた
「実時間の1.1倍」じゃ間に合わないな リサイズとインターレース解除加えたら更に遅くなるんだよね? ■ このスレッドは過去ログ倉庫に格納されています