そうそう変わるもんじゃねえな (前略、ドイツにて。あらため) -26ページ目

そうそう変わるもんじゃねえな (前略、ドイツにて。あらため)

ゆるーく日常をつづります。と言いながら、6年ぐらいほったらかしにしていたブログ。2018年に入ってから思うところあって復活したけれど、とりあえず三日坊主の危機は脱出。でも、あまり更新しないなぁ。

とりあえず、ubuntuでの録画環境は作れたので、とりあえずsamba入れないとなぁ。ってことで。

 

まあ、普通のsamba 3のインストールなら何度もやっているので特に苦も無くできるけど、

今回の環境では、ちょいとdockerについて知識をつけたいな、ということで、

sambaもdockerでいれちまえーとやってみた。今日のブログは完全に自分用備忘録。

 

dockerのコンテナイメージとしてはvimagick/sambaを使いました。

 

ホーム下にsambaディレクトリを作成して、そこにdocker-compose.ymlと、smb.confを入れればOK。

そのあたりは、ネットに落ちている情報ををたどればできるわけで。

 

まあ、そのうえで、探そうとしてすぐに出てこない情報とすれば、docker-compose.ymlとsmb.confでのフォルダのマウントの仕方というか記述の仕方ぐらいだろうか。

 

docker-compose.ymlのほうの記述もvimagick/sambaの場合は、こう書けばいい。という情報は落ちているけから、それをコピペして自分の環境に合わせて書き換えていくわけだけど、

 

例えば、/home/hoge/chinachu/recorded/ を録画データのフォルダとして、これをネットワーク内で共有したい場合、

 

docker-compose.ymlの中のvolume: のセクションはこうなるわけです。

先頭のn + 数字:は、行だと思ってくだされ。

 

n + 0: volumes:
n + 1:    - ./smb.conf:/etc/samba/smb.conf

n + 2:    - /home/hoge/chinachu/recorded: /recorded

 

n+2行目で定義している。 つまりコロンの手前に書くのは、実際のフォルダ/ファイルの位置で、

コロンの後ろに書くのはdockerのコンテナ内のフォルダ/ファイルのマウント位置。

つまり、共有したいフォルダの位置は/home/hoge/chinachu/recorded だけど、dockerのsmabaコンテナ内では、ルート直下の /recorded だということです。

 

ちなみにn+1行目では、docker-compose のある位置(./)に保管されているsmb.conf(ファイル)を、Docker内で動いているsambaから見たコンテナ内で本来smb.confの置くべき位置にマウントするわけで。 

 

まあ、そうしなかったら、コンテナ内からコンテナの外にあるsmb.confファイルが参照できないわけで。

 

で、smb.confはまあ、普通にsambaを運用している人なら書けるでしょう。

 

当然、dockerのコンテナ内のsambaから見ると、共有すべきフォルダーは、ルート直下の/recordedなので、それに合わせてsmb.confを書けばいい。

 

まあ、sambaのguiツール(例えばsystem-config-samba) で設定していると、smb.confの書き方忘れてしまうけれど。。。guiツールで編集してもいいとは思うが。その辺は自分で調べてくれ。

 

しかし、こうやってdockerでアプリを導入すると、今までのソフトのインストール/更新のめんどくさい作業は何だったんだろ、と思う。起動も停止も削除も「コンテナ」に対する指示だけで済む。

dockerのコンテナと、実環境の間のデータ/情報の受け渡し方法(ファイルやフォルダのマウント位置とか、tcpなどのポートのフォワード定義をすればとりあえず動くということと、その定義はdocker-compose.ymlの中に書けばいいって話だな。

 

なるほど。

2011年のドイツ赴任の時に録画鯖をたててからの3回目の近代化 (ubuntu 20.04 + mirakurun3.1.0 + chinachu γ、そしてpt2)

 

 

初代(2台構成) 実家に鯖立て。毎日提示にMP4変換のため、エンコ鯖起動。エンコ以外は常に20Wで動作。 建前は実家の両親用ビデオ録画サーバー。2015年退役。

 

マシン1a(メイン鯖):Atom D510 2GB RAM FoxxconのITXミニPCキット改 1TB HDD

チューナー:PT2

OS: windows 7 64bit Pro

主要ソフト: TVROCK + TVTest + Softether VPN(当時はPacketixだったかな) + Tight VNCサーバー

 

マシン1b (MP4エンコ鯖):Phenom X6 1055T + 4GB RAM、1TB HDD(OS) + 2TB HDD(ビデオ)

OS: Windows7 64bit

主要ソフト: ffmpeg + Softether VPN(当時はPacketixだったかな) + Tight VNCサーバー

 

 

 

2代目 2014年:日本に戻ってきて自分用に鯖立て。アイドル時はだいたい18W~20Wぐらいで。 2015年に実家用に転出。

マシン2a:Athlon 5350 4GB    64GB SSD+1TB HDD(リムーバブル)

チューナー:PT3

OS: UBUNTU 14.04 LTS 

主要ソフト: EPGREC+RECPT1+ffmgec、SSHとSoftEther VPNと X11VNC。あと、sambaとDLNAサーバも実装。 

 

2代目のクローン 2015年から運用。チューナーとチューナー数を増やして運用。

マシン2b:Athlon 5350 4GB RAM  128GB SSD+2TB USB HDD

チューナー:PT2 2枚(DIRECのPCI 2スロット→ PCI Express 変換ライザーカード使用。

OS: UBUNTU 14.04 LTS 

主要ソフト: EPGREC+RECPT1+ffmgec、SSHとSoftEther VPNと X11VNC。あと、sambaとDLNAサーバも実装。 

 

3代目:(ここ)

マシン3b:(マシン2bと同じ)  Athlon 5350 4GB RAM   256GB SSD +4TB USB HDD

チューナー:PT2 2枚(DIRECのPCI 2スロット→ PCI Express 変換ライザーカード使用。

OS: UBUNTU 20.04 LTS 

主要ソフト: Chinachu γ+ mirakurun (Docker) 、SSHとSoftEther VPNと X11VNC。あと、samba実装。 

 

3代目は、UBUNTU 20.04 desktop  (サーバ版ではない)を使いました。

mirakurun 3.1.0のDocker版の導入は、かなり簡単ですね。 チューナー、BCASなどのドライバ-類の細かな導入作業はほぼ端折れます。

 

癖があるのはChinachu γの導入です。まあ、Chinachu のupdateに比べ、Mirakurunがどんどんupdateされているため、Chinachuから他のソフトに乗り換えている人が増えていることで、あまり新規でMirakurun(Docker版)+Chinachu γをUbuntu 20.04に導入する人がいないのだろうなぁ。

 

逆に、Mirakurun (非Docker版)を導入した人なら、一通り開発環境の導入、Chinachuの導入前にNode.jsやpm2なども、すべて導入できていることでしょうから、あまり問題にならないのだろうけれど、私の場合、いきなりubuntu 20.04環境作って、docker使えるようにしてすぐにMirakurunを導入してしまったので、何の環境もそろっていなかったというのが仇になります。ただ、驚くべきは、Docker版のMirakurun、めちゃくちゃ導入が楽、ということ。その分、chinachuで躓くという感じ。どこで躓いたかといえば次の2点。

 

1)chinachuを導入し、無事にUIからリアルタイム視聴などができるところまでこぎつけたたけど予約しても録画できない。

2)pm2 startでchinachu自動起動スクリプト読ませてからsaveしたあと、再起動しても、chinachuが自動起動しない。

 

てな、状態になりました。

 

まあ、結論は以下の通り。

 

1)については、chinachu-operatorのエラーログ調べたら、node.jsで足りないModuleがあったみたいなのが判ったので、まずは、足りないモジュールを調べて足してくれる有難いおまじないをしました。

このあたりのワードをwebで調べれば出てきます。   npm install -g npm-install-missing 

 

2)については、簡単に言ってしまえば、pm2そのものの自動起動設定していなかっただけ。多分、非dockerのMirakurunを導入するときに、pm2を導入しているのならば、そこで、saveしただけじゃ自動起動しないわな。

 

ということで、initdに書くような作業を受け持つのはなにか、といえば、startup だな、、、ってことで。

 

 

/////  すみません。わざとわかりにくく書いています。判らない人が意味も分からずに試して思った結果にならないからと、文句言われると、、、、、ちょいと困るので(笑)。  

パソコンのインストール関連も、車やバイクいじりも同じですね。DIYでやることは構わないけど、問題が起きたときに自分で解決する気が無かったらDIYでやるべきではない、プロに任せろ/ちゃんとしたものを買え、ってことで。   まあ、タイヤ交換の件はプロに任せてさんざんな目にあったので、プロって言っても幅があるけどね。 /////

 

 

判ったことは、pt2 2枚刺しと、DirecのライザーカードでPCI ExpressにつないだAthlon 5350環境、

Ubuntu 20.04.01の日本語環境で、mirakurun 3.1.0(docker)+Chinachu γは確かに動作する、ということ。

 

あとやり残したのは、dockerのコンテナ内で吐き出したmirakurunのlogの管理を考えたほうが良いのかなぁと思っている。まだ、どうやればいいのか調べていないけど、docker版の場合には出力をstdout/stderrにする作業が必要かなぁ。 そうじゃないと、コンテナ内でどんどんログが増え続けることに。   まあ、何日に1回か、再起動(コンテナごと破棄) させればいいのだろうけれど。でも再起動時点でコンテナ内に吐き出したログは消えてしまう。過去ログが必要な時に無いのも困るので、はきださせるしかないかな。

 

なんか、ディーラーでの話を書いた後であれなんだけど、

 

特にRR車なので、クラッチのつなぎ方がダイレクトにフロントのぴょこぴょこ
縦揺れとして現れます。

 

いわゆる変速ショックやクラッチのミートについては

ディーラーでXENTRY(昔だとMB STAR)を車につないで

ミートポイント学習をさせると、スムースに変速するようになるのですが。。。

 

一番気になるのは、実は平坦な道での1速の半クラ運転のショック。 

こんな経験ありませんか?

 

平坦な道で、停車している状態で、ブレーキから足を離してしばらくして

ヒルアシスト(坂路でクルマが後ろに下がらないようにする機能)が切れた

状態でわずかにアクセルをゆっくり踏み込んだときのクラッチの

急なつながりによるドンツキ感。

 

渋滞でノロノロ運転していて、周りの速度に合わせてスピードを落として

アクセルoffでクラッチが完全に切れて惰性で動いている状態(惰行)から、

失速しないようにほんの少しだけエンジンの力を伝えようとするときの

クラッチが急につながるあのドンツキ感。

 

クラッチミートポイントの学習でも改善されますけど、比較的短期間で

上記現象は再発します。

 

私の乗っている450系のsmart(Brabus)のパドルシフトでは、たまに

変速しない、という作動不良が起こりました。原因不明で、ディーラーに持って

行ってチェックしてもらってもエラー記録は無く、でも現象は何度も発生する。

でも、あることをやってみたら、変速ショックも小さくなり、パドルの変速不良も

起きなくなりました。

 

ということで、2014年ぐらいからやってみて経験的にわかっている小技を

列記します。変速ショックを和らげる小技は、今なお450系スマートに乗っている

御仁に試してもらって効果のほどを聞いてみたいのですが、

私には、そういう友達いないので(以下略。

多分700ccの450系smartのみにしか使えない情報というかアドバイスだと思うけど。。。

 

冷間時(エンジンが冷えているとき)の変速ショックを和らげる方法:

1)エンジンかける前に一度イグニッションONにした後、サイドブレーキが引かれていること、ギヤをニュートラルにしてギヤインジケーターがNであることを確認。フットブレーキから足を離して、数秒待ち、イグニッションをoffにする。

2)2、3秒してから、再びイグニッションONでセルを回してエンジンをかける

 

運転中エアコン(雪マーク)を使うのであればエアコンはONの状態で1)も2)もやってください。

 

温間時(エンジンが温まっているとき)の変速ショックを和らげる方法:

1)信号待ち中とかで、水温系の黒点が2つ以上点灯している状態で、一度エンジンを切る。

2)数秒待った後、再びエンジンを掛ける。

 

運転中エアコン(雪マーク)を使っている場合は、1)のエンジンを切る前にエアコン(雪マーク)はOFFにしておいてください。運転中にエアコンを使う場合は、2)のエンジンかけてから、発進する前にエアコン(雪マーク)をONにしてください。

 

パドルシフトのシフトダウンが効かなくなる。(シフトアップが効かなくなる)、またはなぜかパドルシフトを動かすとクラクションが鳴る場合の対策:

方法1:

1)エンジンかける前に一度イグニッションONにした後、数秒待ち、イグニッションをoffにする。

2)2、3秒してから、灯火類全部off、ブレーキペダルからも足を離して再びイグニッションONでセルを回してエンジンをかける

 

方法2:

1)走行中、パドルシフトで変速しないことが分かったら、前に車がいないことと周囲に迷惑にならないことを確認してからホーンボタンをホーンが鳴るまで押す。(走行中でも可能です。)

 

その時、ホーンボタンを押し続けても、最初の0.5秒から1秒ぐらい音が出ない場合は、ホーンの音が鳴ることが確認出来たらパドルで変速ができるようになっています。

 

なぜ上記方法で改善するのか、、、、上記手順で改善する経験に基づく想像でしかないですが、

ECUなどの内部の電子部品、特にコンデンサ類の劣化かなぁ、とあたりをつけています。

だって、450系のsmartは、もう15年以上昔の車です。まあ、仕方ないです。

 

ECU内の基準電圧回路またはコンパレーターのコンデンサーの劣化だけではなく、バッテリーの劣化、オルタネーターの劣化など複合的な理由かと思いますが、ECUの電源電圧がイグニッションON直後と、セルを回した後のエンジン始動後で大きく変わってしまいます。これがクラッチミートポイントの誤認識や、オープンループ制御している部分の不整合、パドルシフトのしきい電圧の誤認識を起こしているようです。そのため、上記手順を踏めば、そのあとのクラッチショックやパドルシフトの作動状態が改善するようです。

 

特に方法2は、パドルシフトの信号がホーン回路の電圧によってホーン、up/downを認識しているため、エンジン始動時のバッテリーの端子電圧がちょっと変わるだけで認識不良が起こるようです。

 

 

まあ、ECUとかコンピューターが演算処理をデジタルでこなしていても、入力/出力でアナログ信号を扱うのであれば、まあ、言わずもがな。

 

温間でもう一度イグニッションをOFFにする必要があるのは、クラッチポイントの認識が冷間時と

温間時で違っており、冷間で調子が良くても温間ではショックが大きくなる、またはその反対があるからです。

 

また、エアコンを使うとアイドルアップが働くため、変速時のクラッチ係合ショックが顕著に現れることがあります。


恒久的な解決方法はECUの新品交換、バッテリーの交換、オルタネータの交換、またはECU内のコンデンサーの交換(総入れ替え)で解決するかな、と思いますが、コンデンサの総入れ替えは、ECUを開いて、手作業でやらないといけないので、面倒くさいですけど。いまさらそんなことに金を掛けたくないことと、上記手順で改善できるので、検証方法はわかっているけれど、確認していません。

 

それから、ディーラーでのクラッチのミートポイントの学習は、冷間時のミートポイントの位置合わせだけど、ミートポイントでのクラッチのつなぎ方は、アクチュエーターのトルク(力)は、オープンループ制御だとすると、PWM/電流制御にしても、イグニッションON直後の電圧を基に基準電圧を決めて補正でもしているのかなぁ。

 

何にせよ、基準電圧という点を意識したのは、パドルシフト作動不良が発生しているときの、ちょっとしたいたずらで気が付きました。

ある時、パドルでupはするけどdownしない状況の時に、ある時にパドルを握りっぱなしにしたりいろいろしていたらいきなりホーンが鳴って驚いたり、その逆にホーンを押してもホーンが鳴らないことがあったけど、そのままボタンを押し続けていたら、いきなりホーンが鳴ったり。

 

いわゆるホーン(クラクション)/パドルシフトは、ホーンの配線に流れる電圧がON・OFFだけではなく、で、中途半端な電圧をつかって、パドルup/downなのかhornなのかを認識して動作するということは知っていたけど、パドルシフトは変速するためだけにしか使わないので、本来パドルを握り続けることは無い。一方で、ホーンは鳴るまで押し続ける。もし鳴らなかったら、鳴るまで押すし、押しても鳴らなかったら保安部品が動かない壊れ方は問題である。だから、仮にイグニッションON時の電源電圧で基準電圧を設定しても、パドル/ホーンボタンのいずれかを長くONにし続けると、そのボタンを操作しているときの電圧をホーンの動作のための基準にしているような動作をしていることがわかりました。  パドルシフトを動かしたときにホーンが鳴るときには、ホーンボタンがシフトダウンに誤認識されたような気がしたけど、もう、5、6年前なので、うろ覚え。

 

エンジン始動時にIGN ON→放置→IGN OFF→放置→IGN ON、セルスタートで運用する限り、セルが起動しなくなるまでバッテリーの劣化が進んでもパドルシフトでの変速不良は生じなくなりました。また、パドルシフトが正常に動かないときには、ほぼ確実にホーンボタンを短くたたいただけでは音が出ない状態になっていることや、そのあと音が出るまで長押しすると確実にパドルシフトが復活することも、わかってきました。

 

このことから、エンジン始動前のIGN ON直後のバッテリー電圧が重要だということがわかりました。エンジンかけずにIGN offにしてもバッテリーの電圧は回復しないから、意味ないじゃん、と思うかもしれないけど、燃料ポンプ動作でIGN ONの瞬間の電圧がドロップするんですよね。IGN ONで燃料ポンプが動作し、燃両ライン内の燃圧を上がるとポンプが止まるので、それからIGN offにしてもう一度IGN ONにすると、セル廻って、インジェクタで燃料吹くまでは燃料ポンプ動いていないので、バッテリ電圧がドロップしないんですよ。

 

要するにエンジン始動前に一度「捨てIGN ON」をすること。できるだけ、灯火類、エアコン以外の補器類を動かさない。である。

 

 

 

あと、バッテリー弱まってきたとき、冬の冷間時にセル廻らないぐらい劣化すると、間違いなくパドルシフトの動作がおかしくなったり、変速ショック(クラッチのつながり)が大きくなります。そういうときでも、上に書いた手順でエンジン始動すれば、問題ないです。

 

あ、セルが回らないんじゃ困る、というのなら、IGN ONの後、アクセルを半分踏み込みながらセルを回してください。当然、ブレーキ踏むとブレーキランプついて電圧低下しますので、ブレーキは踏まないので、ちゃんとニュートラル入れてサイドブレーキ掛けてくだされ。アクセルは、セルが回ってエンジンがかかりそうになった瞬間にペダルを戻してください。ちなみに、アクセル開けるのは、マニホールド負圧を下げる目的です。クランキング時のポンピングが楽になるので、セルも廻るというもの。でも、アクセル踏みっぱなしは危ないしだめですが。まあ、450smartは、ニュートラルならブレーキ踏まなくてもセル回せるのでできるワザですね。  これで、冬を乗り切って次の夏も乗り切れ....ませんでした。バッテリーがご臨終になりました。2014年から使っていたバッテリーです。よく持ったものです。

 

ちなみに、バッテリーの記事で温間始動なのにセルの回転がめちゃくちゃ重い時、エアコンON状態でエンジンとめて、比較的短時間でエンジン回そうとするとエアコンのコンプレッサには優しくないです。やっちゃだめな奴です。エアコン切れ~。(わかっていて書いてますが)