chinachu

KODIPiersのAlpha1のマイルストーンは進捗率が91パーセント。いつ覗いても遅々として進んでいないのだが．．．ただ、現状のOmegaは完成度が高く安定している。使い勝手に不満もない。ただ、強いて言えばゲームのランチャが欲しいかな。まぁ、そう考えると次期バージョン更新を急く必要もなく、まったり待とう。一方、TVサーバーはどうだろうか。chinachuγ後のchinachuair構想は実現しそうないので波立つことはないだろう。そして、自宅環境で絶賛稼動中のEDCBはド安

Nexusといっても、googleやtoyotaのソレではなく。次期バージョン、kodiv20のこと。現在、自環境においてv19にすら移行できていない。ラズパイ3は余っているのだが、それだとv19には役不足である。かと言って、ラズパイ4を購入する余裕も無し。そんなことで、まだまだv18はメインで稼動させる予定。当然ながら、v20のことなど先のまた先の話だったのだが．．．。v20において字幕表示にwebvtt形式が対応されるとのこと。その一方、EPGStationではwebvt

表題は某掲示板の書き込みから引用させてもらった。chinachuairは、開発中であることは以前より語られていたが、すっかりと忘れていた。少し前から頻繁にcommitされているmirakurun。そして、表題の書き込み。ハッ、もしかしてchinachuairをリリースするための布石なのか？穿った見方をし過ぎだろうか。そもそも大分と前から開発しているのに、いつまでたっても出ない。記憶にある限り、仕事が忙しいので落ち着いてから開発するとかなんとか記されていたはず。あらためてネット

前回ブログから続き。kodiの次バージョンMatrix、リリース間近。しかし、ラズパイ3を使用する前提で考えるとすんなりと移行出来そうにない。ということで、しばらくはLeiaのpvr.addonを使うことになる。であるなら、見ないふりしてた問題点をこの機に直そう。で．．．今回はそこを修正するところから。毎週視聴する番組をルール設定．．．いやぁ便利:)しかしCSでありがちな週に2回放送や過去の放送を別枠で放送等、番組録画するにはやっかい極まりない。どんだけやるんじゃ．．．番組表でみ

久しぶりに自前修正版pvr.chinachuのコードを触ってみることにした。現在使っているものはpvr.chinachuに手を加えたもの、一言で説明するとpvr.chinachuのEPGStation対応版。ブログを記すうえで便宜上「pvr.chinachu改」と名付ける。ん．．．それならpvr.epgstationを使えば？その通り．．．しかしリリースされるのがあまりに遅すぎた。で、ことの経緯は以前のブログに記しています。そのpvr.chinachu改はLeia用ではあるが、現状何

2011年のドイツ赴任の時に録画鯖をたててからの３回目の近代化(ubuntu20.04+mirakurun3.1.0+chinachuγ、そしてpt2)初代（2台構成）実家に鯖立て。毎日提示にMP4変換のため、エンコ鯖起動。エンコ以外は常に20Wで動作。建前は実家の両親用ビデオ録画サーバー。2015年退役。マシン１a（メイン鯖）：AtomD5102GBRAMFoxxconのITXミニPCキット改1TBHDDチューナー：PT2OS：windows

ＴＶの番組録画に関してルールによる番組予約は、いまどきは当たり前の機能。TVサーバーともなれば家電のレコーダー以上にこの機能は重宝されているはず。しかし、この機能を普通に設定しているだけでは思い通りにいかないことが多い。例えば、タイトルの一致で設定していると、再放送があった場合に同じ番組が録画されてしまう。では、同じものが予約されていれば手動で削除すれば良いのでは．．．。面倒ではあるが、手動で削除することに。しかし、いつのまにか予約が復活していたりする。そう、定期的なルールチェック

以前のブログで、録画後にエンコードの自動実行に失敗したことを綴った。実際にはエンコード処理のかわりにtsselectを実行させてドロップチェックをさせる予定だったのだが．．．。見事に失敗．．．いやいや、ただ動かせなかっただけか；それはそれで諦めたのだがEPGStationのwebapiにあるエンコードの手動実行ではどうなのか？と、気になっていたので試してみた。だめもとで行なった．．．が、意外にも動作した。オ〜！少し手を加えたtsselectが無駄にならなかった:)よくよく考えてみ

長い間、pvr.chinachuにはお世話になった。ありがとう。そして、こんにちはpvr.epgstation。pvr.chinachuは作者の作りっぱ感がありありだった。が、pvr.epgstationは力が入っている。ソースを見ればコーディングが丁寧になっているのが分る。開発開始の経緯はネットで記されているが、それにしても何故に今さら．．．？創造で語らせてもらう。仕事でプログラム作成する場合、時間が無いとコーディング規約を無視して力技で組んでいく。pvr.chinachuは

pvr.chinachu作者さんがepgstationに対応されたようです。その名もpvr.epgstation。。。待っていたひとはようやくか．．．との思いでしょう。自身はepgstationを使いだしたのが遅かったのでそれ程「待ったな〜」感はない．．．。それよりも、pvr.chinachuが志し半ばっぽい感じだったので開発開始が意外だった。作者さんがpvr.chinachuを終えた理由としてざっくりと、tv録画よりも動画配信サービス中心なので．．．。との事で開発を進める理由がなか

EPGStation対応のpvr.chinachuに関して。使えるようになったのでもう良いかな．．．と思いつつもソースを眺める。pvr.chinachuは旨く工夫して最低限の機能は果していた。正直、chinachuの少ないwabapiを利用しているために仕方ないとの見方もある。いずれにしても、最初に面倒なkodi対応からインターフェースを実装するまでが大変だったに違いない。しかし、あきらかに手抜きしている箇所もある。1.録画済みの情報がkodiへ渡されない。2.番組表が更新されない

ライブ視聴前回は番組表の表示までを記しました。完璧とはいかないまでも表示はできたはず。そうなれば次はライブ視聴。無圧縮のストリーム再生だけなら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へのリクエスト

前回のブログの続きです。第2案、epgstationのrestapi対応をしたpvr.chinachuを作成を試みました。その前に第1案も少しだけ．．．と、思ったが、一通りpvr.iptvsimple+epgstation環境を弄ってやめる。欲ばると迷走した上に時間を浪費するのがおち。で、さっそく第2案へ。chinachuとepgstationのrestapiを比較する。そもそもrestapiの対応はjsonのオブジェクトの名前を変えるだけでは？と、思いつつも手を加えて

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

以前に記した記事「isdb-kodiメモリーリーク」の続きです。内容は表題のままでisdb-kodiにあるパッチをあてるとメモリーリークする旨を記したもの。二ヶ国語放送を観なければaptからインストールしたもので十分だったのですが．．．そこは奥歯にものが引掛ったような気持悪さがあり調べてみました。結果．．．すいません．．．こちらのケアレスミスによるものでした；修正後、正しく動作しています．．．何の問題も無く。使わせてもらっている身でありながら、適当な事を記してしまった。作成者さん

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のすごいところは再生できずにタイムア