Linuxでテレビ総合スレ 避難所 3
■ このスレッドは過去ログ倉庫に格納されています
デバイス認識してるしファームもロードされてる デバイス番号も合わせた テレビで見れる位の信号は来てるしロックもしない 物理周波数に信号来てるのはチェッカーで確認済み これ以上はちょっと思いつかないな >>731 Windowsでは正常に動いてるということでいいのかな? デバイス指定してNoSignalならアンテナの接続間違ってるようにしかみえないんだけど 接続再確認してあとはpx4video地デジ側2,3,6,7全部確認してみるくらい? >>734 チェックして動かなかった 環境作るの楽なlinuxでも試してみようという流れ >>735 先にWindowsで動くの確認しないと障害切り分けにならん罠 まぁここでやれる事はもうやってる気がするから あとはメーカーにご相談くださいな気がす 他のチャンネルも試してみる 他のデバイス(/dev/px4video*)も試してみる アンテナ外した状態で試してみる 信号レベルが強すぎるとダメっていうのありませんでしたっけ? >>714 ありがとうございます。欲しかったのはこれです。 >>727 つーか郡山のNHK総合ならほぼ笹森山の15チャンネルじゃねーの >>732 その通りだ、俺が間違っていた まとめサイトの人に謝りたい recpt1 実行してるユーザーは video group に入ってるのかな? 参考サイト読んでみたけど、ぱっと見そこら辺書いてなかったから。こっちの見落としだったらごめん。 px4_drv は パーミッション 664 みたいだし。 試しに sudo で recpt1 してみるとか。 あれ、物理chそのまんま書くんだっけ?物理ch-13の数値じゃなくていいんだっけ。 自分はいつもrootで動作確認してそのままmirakurunにするからパーミッションは盲点だったな でもパーミッションならエラーメッセージに出そうな気もする とりあえず作業ユーザーがhogeなら gpasswd -a hoge video としてから再トライだな 無論sudoでもいい >>740 いや、Ubuntu 18.04で参考サイト通りならパーミッションは関係ない VIDEOグループに属してないユーザでsudoも使わずrecpt1出来た(出来てる) >>741 > ./checksignal --device /dev/px4video2 13 > ./checksignal --device /dev/px4video0 BS01_0 --lnb 15 みたいな表記だろう >>720 によるとパーミッションは664 readできりゃいいんだっけか Windowsでもこんな感じらしいし、配線や電波強度に問題ないならメーカーサポート行きで良いんじゃないかな 私ならWindowsとLinux(サポート外とは謳っているが公式Linuxドライバ)の両方で駄目だった旨の結果を送りつけて初期不良か調査を依頼するけど タイトル:エラー メッセージ内容:チャンネル変更の要求が BonDriver に受け付けられないため、スキャンを行えませんでした。 タイトル:スキャン結果 メッセージ内容:チャンネルが検出できませんでした。信号レベルが取得できないか、低すぎます。 ああ、もともとあっちのスレ由来なのか WindowsでもNGなのは確認済と レッツ返品 chardevはvideoグループに追加する必要なし DVBは要追加 >>744 仮に地デジの13chを選ぶならチャンネル指定は0なんじゃないの?って思って。 > ./checksignal --device /dev/px4video2 13 これなら物理26chを指定してるんじゃないかなーと。的外れなレスしてたらスマソ 壁面とチューナーの間のケーブルかその接栓に問題がある気がするな Raspberry Pi 4 + PX-W3U4 + px4_drvという環境ですが、わりとドロップしてしまうことに気づきました。 Driverがxhci_hcdに変わっており、px4_drv作者さんが以前書いてくれた /boot/cmdline.txtにパラメータを記述する方法も使えないようです。 USB3ポートの下側にHDD、USB2ポートの上側にチューナを接続した状態だと以下のようになっています。 $ lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M # HDD /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=px4_drv, 480M #W3U4 なにか改善する方法思い当たる方いますでしょうか? みなさま、様々に考察いただきましてありがとうございます。 笹森山の15ch、郡山市内で視聴できるすべてのチャンネルで録画テストを試みましたが、症状は改善しませんでした。 /dev/px4video2,3 の両方で録画テスト、および、checksignal を実行いたしましたが、問題解決には至りませんでした。 また、念のために gpasswd で作業ユーザーを video グループに追加後、同様の試行を行いましたが、同じエラーメッセージが表示されました。 地デジのアンテナ端子を外した状態で試行しましたが、エラーメッセージは以前と同様でした。 チューナーの初期不良を疑い、問題の PX-W3PE4 を返品することにします。 みなさま、ここまでお付き合いいただきまして感謝いたします。ありがとうございました。 >>751 busterにdkmsでインストしただけ何も設定不要で手元は安定している 怪しむとしたらその繫がってるHDDくらいじゃないかと W3PE4をラズパイでアホほどミスとか設定間違いしまくってエラーも色々みたけどそのエラー内容はみたことないわ。 読み返した感じだと俺も初期不良だと思う。配線ミスとかだとしてもno signalみたいなエラーだったと思うし。 あとはうろ覚えだけど、LNB給電ををONにした状態でBSか地デジのを抜き差しとかするとチューナーが壊れるんじゃないっけ? もしかしたら切り分けしてるときに焦って抜き差ししてるときにこれで壊しちゃったとか >>753 ヒント頂いて解決しました! ありがとうございます 使っていたのはHDDでSSDではないですが、以下の書き込みの通りUASを無効化したところdropほぼ0になるまで改善しました STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this https://www.raspberrypi.org/forums/viewtopic.php?f=28& ;t=245931 他の方のために、簡単にここに手順を書いておきます: 1. syslog や dmesg からHDDケースのidVendor, idProductを取得 Jul 27 09:27:33 raspitv4 kernel: [ 1.337750] usb 2-1: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 3.36 Jul 27 09:27:33 raspitv4 kernel: [ 1.337816] usb 2-1: Product: Ugreen Storage Device 2. 上記から idVendor, idProductの値を xxxx:yyyy:n の形でcmdline.txtに書き込んでreboot usb-storage.quirks=2109:0715:u coherent_pool=4M dwc_otg.lpm_enable=0 .... >>672 だけど今日までにラズパイ3B+とKTV-FSUSB2(K1107)で一通りの環境が出来た フレームサイズ変換させずに1080pのままなら、FFmpegでリアルタイム圧縮して ドロップほぼなしで見られるんだな 映像2.5Mbps音声128kbpsまで落としてネットで見られるようにした これで回線さえ確保できれば海外でも1080pでロケフリできそう で、さっきたまたま尼を見てたら、さんぱくん外出があったのでポチってみたw 今なお月末が近づくと尼に少量出てくるんだな uas引っかかるのか ハブでSSDとHDD4台ぶら下げてるけどなんともないし ケース相性もあるんかなぁ バスパワーHDD繋ぐと不安定なるっぽい ちょっと試しにやってみたらdropでボロボロなったわ しっかりした電源使っても USBは1.6Aまでみたいな文書をみた気がする 5v 1.6A = 8wなんてHDD駆動するのギリギリだし スピンアップも苦しいんじゃないの あとUASのはUSB2.0の方につなぐと無効化されるので問題ないというのも見た気がする Ubuntu環境で録画完了したファイルを同HDD内の別のフォルダに移動するにはどうしたら良いでしょうか cronで録画してなさそうな深夜に定時で移動させてましたが、たまにその時間帯に録画が入ると止まるので現在手動です できれば録画完了してアクセスがないファイルは即移動させたいです 書き込み用に open してる側は mv されても関係ないと思うけど、別パーティションなのか? find . -name "*.ts" -mmin +10 -exec mv {} target \; 読んでてふと思ったんだけど、なんでchinachuだとm2tsで録画なんだろう? 全然仕組みとか知らないんだけど、EDCBはtsだし、何が違うの。 前にEDCBから移行したときに思ったけど、chinachuで.tsで録画できるのかな? EPGStationへの移行も考えてるんだけど、やっぱりm2ts録画でドロップチェックとかもないんかね? 拡張子の表記が違うだけで同じ形式 EPGStationは拡張子.tsで、ドロップチェック機能あり EPGStation録画時間オフセット設定ないのだけがネック >>761-765 ご意見ありがとうございます 実際のところ録画した後の作業自動化って、皆さんどの程度されてるんでしょう? フォルダ移動、リネーム、CMカット、エンコード等 >>764 具体的で助かります! 今晩試してみたいと思います >>767 中身はおんなじなのね。ドロップチェックあるならEPGstationに移行してみようかなぁ >>769 残すものだけWindows環境でCMカットとエンコード あとは見たら一定期間だけ残して消す >>768 それはmirakurun側で設定するやつ >>772 特定番組だけ録画開始を1分前倒しとか mirakueunなの? >>772 Mirakurunの録画マージン設定だけど、2.0.0 RC 13で実装された機能らしい。 しかし、どうやら非推奨らしく「使用方法が分かる人だけ使ってね」というようで ネット検索しても使い方がほとんど出てこない。 >>773 それは無理だね mirakurunがそんな事を想定して出来てない マージンはEPGStation既にあるんだけど ルールに時間オフセットが無いのだけめんど ちょっとお聞きしたいんですが、ffmpegのvaapiのdeinterlaceを使うと、 右から左にカメラが移っていくシーンなどでティアリングが発生するんですが、 同様の方いらっしゃいますか? 録画したtsファイルをvlcで見てyadif x2を使ってみた限りでは、同様のティアリングは発生しませんでした。 失礼しました。xfce4特有の問題でした。 https://wiki.archlinux.jp/index.php/Xfwm ここ見てコンポジタの設定をいじったらティアリングはなくなりました。 px4_drvの作者です 前々から気になっていたDTV02-1T1S-Uのテスト版非公式Linuxドライバをpx4_drvに追加する形で作成してみました https://github.com/nns779/px4_drv/commit/bc02e19bac60d1eeef624d91ed6555042c848401 なお、私はこのデバイスを所有していないため、実際の動作確認は一切行っていません 作成に当たって、過去スレに書き込みのあったUSBパケットキャプチャ結果を参考にさせていただきました ありがとうございます https://mevius.5ch.net/test/read.cgi/avi/1526812712/533 また、このデバイスに発生することの多い、チューナーを開けなくなる現象が、今回作成したドライバでも発生する可能性があります この不具合は、この非公式Linuxドライバでも解決できない可能性があることを、予めご了承ください 使用方法: 1.px4_drvのリポジトリをcloneし、testブランチにcheckoutする 2.READMEの通りにインストールを実行する 3.DTV02-1T1S-UをPCに接続する (/dev/以下にisdb2056video0という名前のデバイスファイルが作成される) 4.recpt1を使用して録画を行う >>779 ttps://pastebin.com/Z3ntq110 dtv02-1t1s-uをpx4_drvで動作させてみましたが TSファイルが出力されませんでした(0byte)。 ログにあるように * Tuner,Demodのロックに成功している * チャンネル設定は成功している * CNRは取得できている ログの95-103行では9303のTS入力ポート0が無効になっているようです。 無理やり有効にしてやればTSは出力されました。 >>779 > また、このデバイスに発生することの多い、チューナーを開けなくなる現象が、今回作成したドライバでも発生する可能性があります > この不具合は、この非公式Linuxドライバでも解決できない可能性があることを、予めご了承ください [ 4954.354035] isdb2056_drv 1-5:1.0: isdb2056_set_power: on [ 4954.354041] isdb2056_drv 1-5:1.0: BW 0c 00 01 64 01 02 00 00 d8 b3 00 e6 25 [ 4957.433056] isdb2056_drv 1-5:1.0: it930x_usb_ctrl_rx: Failed. (ret: -110) [ 4957.433087] xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 4957.434055] isdb2056_drv 1-5:1.0: _it930x_control: it930x_bus_ctrl_rx() failed. (cmd: 0x0001, len: 7, rlen: 0, ret: -110) [ 4957.434061] isdb2056_drv 1-5:1.0: _it930x_write_regs: _it930x_control() failed. (reg: 0xd8b3, len: 1) [ 4957.434065] isdb2056_drv 1-5:1.0: isdb2056_set_power: failed. 動作のおかしなやつはやっぱりダメなようです。 >>782 >>783 ありがとうございます TSが出力されない不具合ですが、TS入力ポートの番号の設定に不備がありましたので修正しました > 動作のおかしなやつはやっぱりダメなようです。 んーやっぱりダメですか… 関係があるかは分かりませんが、公式WinドライバではLNB電源の出力用GPIO(gpioh11)を有効化していますが、 DTV02-1T1S-UはLNB電源の出力をサポートしておらず、有効化設定自体も必要なさそうな気がするので、一時的にその部分のコードを無効化してみました >>785 >TSが出力されない不具合ですが、TS入力ポートの番号の設定に不備がありましたので修正しました TS出力される様になりました。ありがとうございます。 > 一時的にその部分のコードを無効化してみました 残念ながら効果はありませんでした。 所有している「動作のおかしなやつ」は接続時のファームウェアロード等は 正常に終了するのですが、接続後なにもせずに時間が経つとBULK転送がtimeout する様になってしまいます。 >>784 px4_drvを動かしているのはxbuntu18.04(5.0.0-25-generic)です。 bus A320M-HDV memory 16GiB システムメモリー processor AMD Athlon 200GE with Radeon Vega Graphics dtv02-1t1s-uを2台所有していて、背面のシリアル番号の若いほうの動作がおかしいです。 (a)201805-000XX : 動作がおかしい (b)201805-00XXX : 正常に動作 (a)は別PCのWindowsでもBonDriverをロードするとTVTestがフリーズして動きません。 >>787 シリアル番号関係あるの? うちのは 201805-004** だけどおかしくなるよ >>788 関係あるかどうかわからないです。 (b)は201805-003XXですので関係なさそうですね。 >>786 お試しいただきありがとうございます TS出力の件は問題なさそうでよかったです 動作のおかしな個体についてですが、 >接続後なにもせずに時間が経つとBULK転送がtimeoutする様になってしまいます。 ということであれば一定時間ごとにデバイスにアクセスし続ければどうだろう、と思ったので実装してみました https://github.com/nns779/px4_drv/commit/63548344322af50d8dfd0871431499dbca4e17c9 初期化完了後から10秒毎にIT9303のチップバージョン(reg: 0x1222)を読み出し続けます >>790 なるほどそういう方法があるかと期待したのですがダメでした。 * 0x1222へのアクセスは常に成功する * isdb2056_set_power内のit930x_write_gpio(it930x, 3, false)がtimeout(110)する ttps://github.com/nns779/px4_drv/blob/develop/driver/isdb2056.c#L248 timeoutするのはBulk転送全体ではなくデバイスopen時のgpio3のみの様です。 接続後どの程度でgpio3がtimeoutになるのか再確認したのですが5,6分程度間隔があくと ダメな場合が多いです。ただ、接続後すぐでもダメな場合もあって良く分からないです。 >>791 ありがとうございます gpioの操作を行って初めてタイムアウトするというのは想定外でした 一つ確認したいのですが、gpioの操作がタイムアウトした後のレジスタ0x1222へのアクセスは失敗していませんか? 何れにせよ、お手上げ状態であることには変わりはないのですが… >>793 > 一つ確認したいのですが、gpioの操作がタイムアウトした後のレジスタ0x1222へのアクセスは失敗していませんか? ログです。 ttps://pastebin.com/vhcpwrtd 1-117 : 接続時の初期化は成功しています。 119-368 : 1回目のrecpt1。接続直後のため録画に成功しています。 370-429 : 0x1222へのアクセス。成功しています。 431-437 : 2回目のrecpt1。1回目の5分後です。gpio3(d8b3)に失敗しています。 439-441 : 0x1222 へのアクセスでエラーが出ています。 >>793 > 何れにせよ、お手上げ状態であることには変わりはないのですが… やっぱりそうですよね。いろいろとありがとうございました。 一応、自分なりに他の方法もテストはしてみたのですが、 (a) timeoutを短くてして何回かit930x_write_gpio(it930x, 3, false)を繰り返す (b) 常にit930x_write_gpio(it930x, 3, false)な状態で動作させる (isdb2056_probeでgpio3をfalseにした後isdb2056_set_powerではgpio3を操作しない。) (a)は3回ぐらいでgpio3が成功する場合があるのですが、10回全て失敗する場合もあります。 (b)は5分を過ぎても動作する感じなので録画環境構築して詳細にテストする予定です。 ただし、USB電流チェッカーが常時0.33Aぐらい示すので結構熱いです。 後、isdb2056_probeのgpio3は常に成功する前提なので、汎用性はなさそうです。 根拠はありませんが、そのうちにそこでもエラーになりそうな気がしてます。 Mac上で動くdocker公開してもらえませんか? ChinachuなりEPGStationなりはそのままで動くだろうけど、 Mirakurunはハードウェアにベッタリだから無理だろうな 特権コンテナにすりゃ動いてるよ Dockerじゃなくてlxcだけど ubuntuベースのdocker上で動かしてる方いませんか?Mac上のdockerで動かす予定。 USB関連をdocker側に認識させるのと、dockerの外からアクセスできるようにするのが面倒。 誰かやってる人いると思うんだけどな やってる方いたら公開してもらえるとありがたいです。 EPGStationの作者の人が検証に使ってる docker-mirakurun-epgstation を参考にすればいいのでは debianベースみたいだけど https://github.com/l3tnun/docker-mirakurun-epgstation MACでどう直すかは知らんが EPGStation + mirakurunのdockerって公式になかったっけ? Macだとdocker machineだか経由してDocker動かすんだろ そこの環境設定しないと だから、docker-mirakurun-epgstation等をDockerコンテナとして展開させる前の話 macのdockerってusbパススルー出来んのか? それさえ出来ればあとは煮るなり焼くなり MacのDockerでUSBデバイス使う場合は、仕組み的にはLinuxKernelが動く仮想マシンがあって、そこにUSBデバイスをアタッチ、USBパススルー こういうの https://qiita.com/shungok/items/6c5a7b5a9d63d51e6615 VM越しのDockerコンテナでまともに動くかはしらん なるほど、先にVMが必要なのね そうなるともうMACでやる意味も個人的には見出しにくいがそこは人それぞれか KVMの中でlxc動かしたときは問題なかったけど、パススルー周りはかなり怪しそうだ MacはLinuxOSじゃないからまあ面倒だよね ハイパーバイザー上でLinuxが動くから、docker-composeやDockerFile等の設定はLinuxOSとほぼほぼ同じなんだろうけどさ >>799 ホストにpx4_drv入れて、mirakurunとEPGStationをそれぞれコンテナで実行とかはやれてます。 EPGStationはcuda使えるイメージをベースにしたやつ使って、nvidiaのグラボさしてHWエンコードで試聴とか。 linuxではなくゲストがwindows + px-w3u3 v2だが virtualbox -> dropまみれでng vmware fusion -> ok だったな まあ、ラズパイ4とか買ってチューナー部分はmacから分離したほうが楽だと思う これから初録画サーバを立てようかと思ってるんだけど、linuxの方がwinより安定して運用できるっていう認識で合ってる? そんな質問をする奴がlinux、winに限らず鯖を作れるとは思えない…釣り針がデカすぎ >>811 環境が一旦出来上がってしまえば、安定して毎日動くのはLinux。その代わり環境構築出来るまでが大変。 Windows環境の構築は楽だが、アップデートやら不具合で、安定して毎日動き続けるとは言い切れない。 >>812 すまん釣りじゃないんだ winの方で調べてると、ドロップがとうのこうのっていう話題が多く見られたのに対して、linuxではあまり見られなかったから、linuxのドライバではそういうことが起こりにくいのかなと思って 不快だったらスルーしてくれ >>813 てことはリアタイ視聴用にwin使うのはありとして、録画サーバにするとすればlinuxの方が安定ってことか 色々ハードルはありそうだけどlinuxでやってみるわ ありがとう 録画鯖は自分のスキルで安定した状態に近づけるものであって 安定してるものを求めるなら市販品が一番だと思う linuxだけどへっぽこ管理者だから月一ペースで録画失敗するぞ >>814 LinuxでチューナーをMirakurunで制御するなら Win側からLinuxのチューナー使ってリアルタイム視聴も出来るでな TVTestとかVLCとかKodiとか使える なんならブラウザからライブストリーミングで見てもいい 最初の構築がそこそこ面倒だけどね あとはまあ、どんなチューナーでもいいわけじゃないしな ゆうほどwindowsでの構築って楽か? むしろ面倒くさいと思うのだが GUIにしか馴染みがないとファイルコピーですらハードル高いわな PLEXの現行製品、USB接続チューナー(内部USB接続含む)を使うのであれば、ドライバの完成度からもLinuxの方が安定するだろうね どちらにせよヤル気がないと チューナーとか必要な機材は全部今から揃えるからlinuxの方が構築終わった後は快適そうだな win、linux共に立てことないから結局大変な事に変わりなさそうだしlinuxで立てるわ 幸いコマンドラインでの操作自体はそこまで抵抗ないから頑張れると思うw みんなありがとう 慣れるとGUIでちまちまやるよりコマンドをコピペする方が楽でミスも減る それこそDockerで構築をレシピ化もできる エンコ環境はwindowsの方がいいね 特にcmカット >>820 快適なのはwinだな どうしてもLinuxでやりたいというのでなければwinのほうが情報量が圧倒的に多いし トラブった時の解決も容易、アプリの完成度も高い。 Linuxの場合はググっても情報が古かったりするし基本的に自分で解決できる人向け。 winかLinuxかここで聞いているようなレベルであれば素直にwinにしとけ。 plexのチューナーを使う前提だと、winはlinuxに比べてドロップが頻繁に報告されてる気がするんだが、その点はどう? winはドロップ以外に不満が出ないからそこばかり目につくだけなのか? 快適なのがwinならみんなはlinuxのどこが良くて使ってるのか教えてほしい。OSのアップデートに怯えなくていいというのは明確な利点だとは思うけど、それ以外にもいいところがあるのでは? 質問ばかりで申し訳ないが答えてくれると助かる 録画先領域を別にすればHDD4GB、メモリ2GB程度で足りる上にライセンスの心配不要 普段使いのPCに録画もさせてるなら関係ないけど、録画のためにハード用意する前提だとWindowsは無駄多すぎ >>827 plexねドロップ以外に不満はないというより、ドロップ酷くてまともに使えなかったからLinux鯖にした mirakurun使えばWin上でもBonあるから使えるし linuxスレで聞いてるからそっち寄りの意見の方が多いとは思うが、やっぱりwinでやる理由があまり見当たらないな cmカットは魅力的だけど、まずは元データを確実に取得することの方が重要だろうし linuxは俺アプリ作りやすいのも利点 winはGUIベースだからアプリ間の連携が面倒くさい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる