harekaze

ライブ視聴前回は番組表の表示までを記しました。完璧とはいかないまでも表示はできたはず。そうなれば次はライブ視聴。無圧縮のストリーム再生だけならEPGStationのwebapiに準じたリクエストをするだけです。最初にリクエストするアドレスを設定します。src/pvr_client/initialize.cpp-ADDON_STATUSADDON_Create-g_schedule.liveStreamingPath="channel/%s/watch.m2ts?ex

EPGStationが神ソフトであると分った。更にkodiのpvrアドオンでも使えるとなれば、これ以上に求めるものがない。もしかしてゴールしてしまったのか。そうかもしれん．．．。そうであるなら、この機に一度pvr.chinachu(改)を振り返ってみるのも有りか。で、コードの差分に対してコメントを並べてみます。番組表を表示してみるとにもかくにもpvr.chinachuを落としてきます。ブランチはmasterを使用。まずは他機能への依存が少ない「番組表」の処理から。

思っていた以上に相性が良く感じられる。chinachuでもEPGStationでもkodi上から使用するなら変わらん．．．と普通は思う。いやいや、自分が一番そう思っていた。どうせ同じならシンプルで軽く、且つ十分に評価されているを選んで当然。が、EPGStationを触ってみると180度考え方が変った。EPGStation用にpvr.chinachuを修正する過程において、その心変りの理由とは。そもそもchinachuは、運用までに多くの手間が必要だったし、ラズパイで使うなら尚更。結

ここしばらくはEPGStation+pvr.chinachuを触っていたが、chinachuと比べてさほど優位性も感じなかったので、もういいかと思っていた。一通りの動作は確認済み。残り手を付けていないのはルールだけ。そう思いながらEPGStationの録画設定をブラウザから弄っているととても感触が良い。あれあれ．．．。そうそう、これこれ．．．こんな機能が欲しかったんだよな。優れているのは分っていたが実際に触ると気持が揺らぐ．．．。使うかそうでないかは、ルール機能を追加したうえ

前回から引き続きEPGStationをサーバーとしたpvr.chinachuの対応について記します。番組表表示とライブ視聴まで問題無かったことは前回までの内容。今回は残りの番組予約、録画、再生までの修正を試みました。最初に番組予約の対応をするためchinachuへのリクエスト関数を確認する。これまでの作業同様、安易に作業が進むことを想定していたが．．．そうは簡単にいかない。番組表とライブ視聴はHTTPリクエストのメソッドがGETのみ．．．今回はPOSTchinachuへのリクエスト

pvr.iptvsimple用の番組表の色分け定義です。chinachu用ですが、ジャンルの定義値を合せればEPGStationで有効かも？<genres><genretype="80"subtype="5">anime</genre><genretype="32"subtype="2">information</genre><genretype="32"subtype="1">news</genre><genretype="64"subtype="0

以前のブログでも記していたようにラスパイ3b+pvr.chinachu環境で満足している。それは今でもブレてない。自身の用途としてTV視聴と録画関連がひと通り出来れば何もいらない。それをするのに必要なスペックは十分．．．いや十分ではないが不足は感じない。音はしないし電気もい喰わない．．．これ以上なにが必要なのかと思う。そんな環境にも、やはり死角はある。複数の録画予約の時間が重なった場合に問題となる事が稀にある。後に録画した分を再生する際、シークが効かないというもの。ごく稀であ

以前、ブログへ記したラズパイkodiがcrashする件です。ざっくりとした内容は、kodiを放置状態にするとcrashするとのこと。詳細は「kodiクラッシュでアイドル中を調査」を読んでください。当初は、クラッシュ発生のトリガーが分ればと考えていた。が．．．思いとは裏腹に跡を残さずシレッと落ちる。あえて特徴を挙げるとすると、何も操作せずに放置している状態で発生する。時間などの法則性なしに、いつのまにかkodiが再起動。kodiのログをみる限りではpvr.chinachuが定期的に

kodiでTVや動画を愉しむのは赤外線リモコンが不可欠。ウィンドウズPCの場合は、設置するTVチューナーに付属するもので代用できる。ドライバーから何から全てが揃ってるので問題ない。が、ラズパイだとそうはいかない。ではどうするのか．．．で、自身の環境で用意したもののを紹介します。実際のところ、リモコンの事をあれやこれや考えだしたのは大分と前のこと。TvTestが賑っていたとき、自身ももれなく使用させて頂いていた。ウィンドウズPCでpt3を使ってはいるがリモコン用途にpx-s3u2をU

pvr.chinachuで録画した番組は録画終了通知されたタイミングで「最近の録画」として表示されない。表示するには手動で「録画一覧を更新」してやれば問題なく表示される。たとえばそのタイミングにkodiを利用していれば録画終了通知によりその旨把握できる。が、そうでない場合には結構気付かない。kodiを起動させた時に「最近の録画」にシレッと表示されていることが結構ある。すっかり忘れてたっ．．．あれ程楽しみにしてたのに．．．みたいな感じ。そうならないように自動で表示されるように修正を加え

以前、ブログに記したようにkodiが落る。crashログが知らないうちに溜っている。ログにはcrashしたタイミングの情報はなく役に立たない。どうしたものか。そもそも何時から発生していたのか？原因はkodiなのか、pvr.chinachuか？クラッシュするタイミングは？環境に依存する？去年の暮れあたりから、ちまちまと調べていた。まずは、発生時の共通点はあるのか。やっかいな事に使用している時には落ちない。発生時は必ず寝ている夜中や外出中で放置中のタイミング。うちではrasp

サーバー、クライアント両方にラズパイを使用した環境において、kodiから録画ファイルを削除した際、データが残る場合あり。DeleteRecording関数により、サーバーへ削除要求を出した後、1秒スリープを挟んで再度サーバーから情報を取得、データをkodiへ渡して終り．．．。のはずが、サーバー側での処理が間に合ってないのかしてkodi上にデータは表示されたまま置いてけぼりに。サーバーからデータを受ける際は同期処理なのに対してデータを与える場合はSleepをおいて間に合せているみたい。

前々からホームディレクトリにcrashログがあるのはわかっていたが、使用しているときに落るようなこともなかったのでスルーしていた。最近になってディレクトリを開くとcrashログで埋まってた．．．何じゃこりゃ。さすがにマズい。数日おきにcrashしていたらしく長い時間を掛けて埋まったらしい。ログの内容だけではわからず色々と試したらメモリーリークしていることを発見。kodiとpvr.chinachuの組み合わせを変えてみて原因を特定。その結果isdb-kodiを使用してTVや録画を視聴

うちで使用しているkodiはisdb-leia-18.4と殆ど同じものを使ってる。このバージョンはデュアルモノ音声の二ヶ国語放送を正しく再生してくれるありがたいもの。NHKはよく当該音声に対応した番組を放送している。ニュースの英語対応や海外放送局の製作したドキュメンタリー等々。あるときにニュース番組を視ていてふと思いついた。。。英語で聞いてみよう。ちなみに英語は理解できない．．．ただの興味本位。切り替えは視聴中に「設定」から「オーディオストリーム切替」で選択する．．．はず。番組表に

1/6に記したブログの内容が間違ってた．．．もし参考にされたならすいません(^-^;結果からいうとsrc/chinachu/recorded.cpp>refresh()にあるforループ内の先頭で構造体をクリアするだけで良いみたいです。[1]そもそも当該修正は以前から腑に落ちず、見直さないとと思っていた箇所。見直すと変なコードを書いているよなぁ。「ラズパイ=組込み=処理速度を考慮」という短絡的な発想で変なコードを書いた始末。非力なマイコン使ってるわけでもないのに愚直に記

近頃はあまりにも問題なさ過ぎてネタが無い。と、思っていたら見つけてしまった。うちで使っているリモコンが劣化してきたためにボタンを押した時の反応がよろしくない。頻繁に使うボタンは特にそう。「決定」ボタンは顕著で少々強く押さないとダメ。強すぎると二度押ししてしまうし、弱いと反応しない。さすがに日常つかっていると慣れてくるが．．．やはり多少のミスはある。録画したTV情報を見るためコンテキストメニューから選択する際にあやまって「再生」を押してしまった。。。が、反応しない。見間違いか．．

大分と使い勝手が良くなってきた。表示や動作は問題ないがログをながめるとERRORがちらほら。原因の判明しているものは無視してもよいレベルのもの。気になるのは録画再生時に発生しているもの。普通にみれてるよな．．．と思いつつ発生源を調べる。どうも録画要求の情報をファイルとして認識しているためにERRORを出力しているみたい。pvr.chinachuではrestapiで再生するためにURL情報を設定しているのに。しかし、それでは終らない。kodiのすごいところは再生できずにタイムア

2020/1/22追記本文の内容が間違ってます。同日のブログでその旨を記しております。TVメニューに「最近の録画」としてサネイルとともに再生状況が表示される。未視聴の場合は非表示、視聴済みと視聴途中はそれぞれの状態を記号で表示。また、視聴を中断した録画番組は前回の中断位置から視聴できる．．．本来は。しかし、比較的最近になってようやく気が付いた．．．おかしくなっているなことが。未視聴なのに途中再生の印が表示されたり、途中再生の位置がとんでもないことに。そこは使っていれば直ぐにわ

かつてのTVチューナーサーバーといえば「chinachu」。今では取って代って「epgstation」へ。で、chinachuと比べてどこが良いのか調べてみた。が．．．明確に答えている記事は皆目。「epgstationは便利」とか漠然としたことはどうでもよい。「chinachuと比べてここが便利」と比較したものはみあたらない。何も変わらないなら、新しくて多く利用されている方がよい．．．確かに。では、やっぱりepgstationを使うべきか？いやいや、それはちょっと早計か。で、簡

録画してもタイミングよってはTVメニュー画面の「最近の録画」に表示されない。待てば良いのか？．．．これがなしのつぶて。ではリブート．．．ようやく表示される。これは、あかんやつや。だが．．．よくよく調べればコンテキストメニューにあった。「録画一覧を更新」さすが作者さん。そりゃ対応するよな。では、いざポチッとな．．．ありゃ。反応せんがな。試しに同様の機能を使ってみる。「予約一覧を更新」ポチッ．．．「スケジューラーの実行」ポチッ．．．動く気配なし。まさか．．．未実装か？そ

ここのところ少しでも変な挙動が有ると無視できなくなっている。それ、どうでも良いから．．．と言いつつそちらを凝視してしまう今日この頃。タイマーの自動登録．．．これが痒いところに手が届かない。EpgDataCapBonを使っていた時に当たり前にできたことがダメ。手放しでできるのは番組名と開始時間を組み合わせたものが基本。issueにも要望があるが「しません」と言い切っている。ということで活用とまでいかないまでも使わないこともない。CS等では再放送に対してフィルターを掛けれるのかが使い道

以前からネットで見受けられた問題。基本表示されるけど、何かをきっかけに表示されなくなる。そうなると、なにをしようがダメ。サーバーやクライアントを再起動．．．ダメ番組データをクリアして再取得．．．ダメ挙句の果てにアンテナ線を抜き差し．．．当然ダメ「番組表が歯抜けになる」等との指摘あったが解決策なし。いや．．．あるにはあったがどれも効果なし。今更に他力本願とはいかなそうなのでコードをみる。まったくわからん。そもそも番組情報をリスト化した後はkodiに委ねている．．．じゃkodi

ライブ視聴するのに気になる点あり。チャンネル切り替えの際に一瞬ちらつく。ぜんぜん問題ない．．．少し気持ち悪いけど。しかし、放送局によっては進捗表示（パーセンテージで表わされるもの）が繰返し表示される。一旦これが表示されると、待っても終らん。ネットで調べると、原因は音の同期が云々．．．よく分らん。で、解決策は「早い回線速度に変えなさい」．．．いやいや、うちは無線LANしか無理。どうしたもんか？試しにpvr.simpleではどうか？これが、なぜかちらつかない。なんでだろう。ソー

kodiから録画予約が出来ればこそchinachu-kodiを使う意味がある。だが、悲しいかなleia移行後は録画予約出来ない。で、少しばかり修正しようと思う。そもそもは何故、録画予約のリクエストが断わられるのか。。。以前のブログでも（略いずれも先んじて対象ファイルをリクエストを試みることは同じ。ここでkryptonはエラーが返ってくると諦めてしまう。しかし、leiaはしつこい。サーバー側で拒否されているだけなら別の方法を用いて確認する。ちなみに以前にブログで記したchinach

最新は比較的最近にコミットされている。まだまだ生きてると思いつつも環境対応に終始されているよう。各プラットフォーム対応やkodiのバージョンアップ対応等々。かろうじて延命させているだけか？ネットを見ていても関連した内容は古いものばかり。唯一、イシューにある「情報取得の失敗」も知らないうちにクローズされてるし．．．これに関しては、おざなり対応でも動くから良いのか。使わせてもらっている側からすると無茶苦茶便利。この環境を使ったひとはepgstationへは行けないはず．．．なんだけ

先日に記したkodiの安定バージョン。kodiにパッチをあてたものの、FFMPEGは0p1pp1版のブランチisdb-4.0を使用。そのまま使えて且つ問題なので良い．．．のだけど、ハイブリッドという違和感。いやいや、そこはフランケンシュタインのようなつぎはぎの化け物感が．．．やっぱり、当該リビジョンに用意されたFFMPEGを使用するのが良い。で、FFMPEG-VERSIONを確認。VERSION=4.0.3-Leia-18.2きっと、大して変らんぞ...と思いながらもデュアルモ対

windowsならkodi-leia18.5がとても良さげにみえる。まず、pvr.chinachuにおける「HTTP2問題」を、こともなげにクリアしている。さらにいえば、チャンネル切り替え時のちらつきも殆どない。一瞬暗くなるが、その他の比ではない。しかし、悲しいかなそのままではデュアルモノは使えない。では0pipp1版の修正分パッチをあてればとも思う...しかし、ffmpegの修正方法を理解していない。あぁ、悲しい。で、ラズパイに載っける一押しを紹介。0p1pp1版でもleia

少し過去に戻ってkodiのkryptonからleiaに切り替えた時のはなし。表示良し。ライブ視聴良し。録画よ．．．録画．．．あれ、録画出来ない？なんじゃ、あたふたあたふた...。ググッたが、「録画出来ませんよ」とは誰も記してない。んっ...。kryptonは苦労知らずだったのに．．．aptからのアップデートなのでそれなりに情報が出ているはず．．．ない．．．ということは、自分の環境が悪いのか？当時、kodi+pvr.chinachuもそれなりに賑っていたはず。が、まった

どちらが人気か？Chinachuの開発が止っているせいもありEPGStationへ乗り換えるひとが増えてる。ただ、chinachuも過去記事の情報量では多く負けてはいない。しかし、時は流れる。kodiはまだまだ機能向上が図られているが、chinachu（はたまたpvr.chinach）は枯れた感が半端ない。ただし、kodiやnodeのバージョン更新等の節目では対応されているみたい。やっぱり、epgstationか．．．個人的にchinachuを使い続ける理由は、やっぱりko

kodi-18.5がリリーズされた。今、使ってるのが18.4。あんまり変わらんか。Windowsで試した。いたって問題なし。ＧＵＩのローカライズされた文言が違う．．．ん？いやいや、ひとつ気になる点が、ＴＶサーバにChinachuを用いた場合、HTTP2問題で視聴出来ないはずじゃ？[1]問題ない？！動く？！何で？そういえばChinachuのコードを一ヶ所手を加えてるのが影響したか．．．今のコードをpullしてラズパイ3Bで試す。やっぱりダメ。わからん。[1]ざっくり