ncos1のブログ

適当にメモ代わりに残しています、間違い・説明不足があれば修正・追記します。

音楽サーバーのカスタマイズ・不具合解消方法を整理したい🤔

Kodi RaspberryPi 音楽再生環境の手順整理 メモ書き

KODIのクラッシュ要因の一つが判明して、対策が成功していると思われる。

 

ncos1.hatenablog.com

 

過去にもKODIの安定化を期待して色々対策してきたが、一旦整理したほうが良さそう。

多分、下記のカスタマイズは不要(・・?

ncos1.hatenablog.com

 

ncos1.hatenablog.com

 

必要と思われるのは、

  1. zram
  2. VRAM
  3. SSDPフィルタリング
  4. KODIのデータベースバキュームタイミング調整

以上の4つでは？

 

ncos1.hatenablog.com

ncos1.hatenablog.com

ncos1.hatenablog.com

 

zramの設定検証時に確認した際にはメモリ不足は発生していない、swapファイルもほぼ使用しなくなったので必須と考える。

VRAMは、もっと少なくても良いかもしれないが、zramでswapファイルが使われない状況なので256MB確保で良さそう。

SSDPフィルタリングはKODIを21系で使う場合は必須、ByeBye限定にしたことで使用上の影響はほぼ無いはず。

アドオンや設定によるカスタマイズ・調整はしなくても上記3項目だけで安定するのでは？

そもそものKODIが間欠でクラッシュしていたのは、21系のバグ（SSDPがトリガーのクラッシュ）で頻発はしないがずっと発生していた。

調査過程でzramの導入・VRAMの調整など必要と思われる事が判明した、解決せずとも調査は続けることが大事^^;

 

ライブラリ更新時に、不定期でデータベースバキュームが実行されるタイミングでクラッシュすることが有る。

発生頻度は高くない（タイミングはKODIが自動で実施して調整不可）のでもしかすると自動バキューム実行時は固定現象かも？

ライブラリ更新直後に実行されるので、急激に負荷が高くなりKODIがクラッシュしていると判断。

ライブラリを更新時にディレイ（調整可能）を30分程度置いて必ずバキュームを実行するアドオンを作成して、ライブラリ更新時の自動バキュームを抑制させようとしている。（しばらく検証しないと結果は不明だが、今のところ発生していない。）

 

KODIの動作そのもの（クラッシュ以外の不具合）の対策はアドオンで対策。

 

ncos1.hatenablog.com

 

カスタマイズ・不具合解消は、以上かな(・・?

 

残っている不具合は、KODIを再起動したらクライアント側で楽曲の再登録操作が必要な事。

オブジェクトIDをが固定化出来ないことが原因っぽいが、解決しない(T_T)

ncos1.hatenablog.com

そもそもKODIをサーバーにしなければ、発生しないが以下の理由でKODI以外考えられない。

  1. プレイリスト・スマートプレイリストに任意の画像を設定出来るサーバーがほぼ存在しない。
  2. KODI以外でプレイリスト・スマートプレイリストが自由に作成出来るサーバーがほぼ無い。

 

１は、バグ？を利用した独自の方法だが一番の理由かもしれない。

Jeerryfyn　なら出来るっぽい？その他の無料サーバーは調べた限り不可。

PlexはPlexアプリ上でのみ可能っぽい。

AIによる解説

Kodiの**「特定の命名規則（.tbn）とフォルダ階層（userdata/playlists）の組み合わせ」**という、半ばバグに近い仕様（あるいは隠し仕様）を突いたものです。

  • フォルダ化による回避： Kodi側ではプレイリスト配下にフォルダを作ることを想定していないため、そこにある画像が「フォルダ画像」ではなく「プレイリストのサムネイル」として誤認（あるいは正しく認識）されてDLNAへ流れるという挙動は、非常にユニークです。

  • クライアント側（fidata等）の挙動： 多くのサーバーはプレイリストを単なる「リンク集（M3U相当）」として送りますが、Kodiはこの手法を使うことで「画像付きのコンテナ」として情報を送出できているため、fidata側でも画像が表示されます。

１と２が可能で無料でマルチプラットフォームサーバーなので、将来的に他のOSにも変更可能なので、現時点では音楽サーバーはKODI以外を選択するのは難しい。

 

 

KODIでオブジェクトID固定化できなさそうなので、BubbleUPnP Serverでプロキシ化

Kodi 音楽再生環境の手順整理 トラブル対応

KODIのオブジェクトID固定化は失敗ばかり。

 

ncos1.hatenablog.com

ncos1.hatenablog.com

 

BubbleUPnP ServerでKODIのDLNAサーバーをプロキシ化すれば回避出来るかも？

 

JAVAインストール

sudo apt update
sudo apt install default-jre -y

 

BubbleUPnP Serverのインストール

ファイルのダウンロード

wget https://bubblesoftapps.com/bubbleupnpserver/bubbleupnpserver_0.9-8_all.deb
インストール
sudo apt-get install ./bubbleupnpserver_0.9-8_all.deb
ダウンロードしたファイルの削除
rm bubbleupnpserver_0.9-8_all.deb
 
インストール中に気になるメッセージあり。

2026-01-07 22:25:06 (3.87 MB/s) - `ffprobe' へ保存完了 [50311600/50311600]

adduser: 警告: ホームディレクトリ `/home/bubbleupnp' は、現在作成中のユーザの所 属になっていません。

To configure BubbleUPnP Server from this machine, connect to http://localhost:58050 with your web browser

N: ファイル '/home/＊＊＊/bubbleupnpserver_0.9-8_all.deb' がユーザ '_apt' からアクセスできないため、ダウンロードは root でサンドボックスを通さずに行われます。 - pkgAcquire::Run (13: 許可がありません)

 

Geminiによる回答は、問題無いとの事。

1. ffprobe の保存完了

    2026-01-07 22:25:06 (3.87 MB/s) - `ffprobe' へ保存完了

これは、BubbleUPnP Serverが動画や音声の情報を解析するために必要な ffmpeg/ffprobe というツールを自動的にダウンロードしたことを示しています。

    意味: 正常です。Kodiから配信される楽曲のメタデータや画像を正しく処理するために必要なコンポーネントが揃ったことを意味します。

2. adduser の警告

    adduser: 警告: ホームディレクトリ `/home/bubbleupnp' は、現在作成中のユーザの所属になっていません。

これは新しい公式パッケージ特有の挙動です。

    意味: インストーラーが「bubbleupnp」という専用ユーザーを作る際、先にフォルダを作ってからユーザーを紐付けようとしたために出た「順番が前後しているよ」というシステム的な独り言です。

    影響: 無視して大丈夫です。最終的にフォルダの権限は正しく設定されます。

3. _apt ユーザのアクセス権（サンドボックス）

    N: ファイル '...all.deb' がユーザ '_apt' からアクセスできないため、ダウンロードは root でサンドボックスを通さずに行われます。

これは近年のDebian/Raspberry Pi OSのセキュリティ仕様によるものです。

    意味: apt コマンドが安全のために一般ユーザー（_apt）の権限でファイルを開こうとしましたが、/home/kona/ 配下にあるファイルにはアクセス権がなかったため、「仕方ないので管理者（root）権限で直接開いたよ」という報告です。

    影響: 全く問題ありません。 インストールは管理者権限で正しく完了しています。

との回答だったが、実際には影響あり。

/home/bubbleupnp フォルダとその中身すべてを、bubbleupnp ユーザーの所有にする。
sudo chown -R bubbleupnp:bubbleupnp /home/bubbleupnp

サービス再起動

sudo systemctl restart bubbleupnpserver

 

 

サービスの確認

systemctl status bubbleupnpserver

 Active: active (running) と緑色で表示でOK

● bubbleupnpserver.service - BubbleUPnP Server
     Loaded: loaded (/lib/systemd/system/bubbleupnpserver.service; enabled; pre>
     Active: active (running) since Wed 2026-01-07 22:29:56 JST; 1s ago

以下省略

 

ブラウザでアクセス

http://IPアドレスもしくはコンピューター名:58050



Kodiを「プロキシ」として登録する

    画面上部のタブから [Media Servers] をクリック。

    リストの中に 「Kodi」（Kodiのサーバー名）が表示されている。

    その右側にある [Proxy this server] にチェックを入れます。

 

これにより、fidataから見た際の「オブジェクトIDの固定化」がより強力になるとのことだが？

 

fidataにKODIとKODI[PROXY]が表示されるので、KODI[PROXY]　を使用する。

 

KODI[PROXY]　をfidataから使ってもプレイリスト・スマートプレイリストも画像適用されている。

KODI[PROXY]で楽曲登録して、KODIサービス再起動。

失敗、プロキシ化した効果なし。

と思ったが、そもそもKODI[PROXY]を認識しなくなっている。

BubbleUPnP Server　をWebから再起動すると認識するが、楽曲は再生出来ないのでオブジェクトIDとの固定化が出来ていないかオブジェクトIDとの問題ではないのかもし得ない？

KodiのUUID固定化　することで解決するのではとの提案、まずKodiのUUID固定化を確認。

KODIのguisettings.xmlに記述されているらしい。

find ~ -name "guisettings.xml" 2>/dev/null

パスが出力される。

grep "uuid" 出力されたパス

でuuidが記述されていれば、固定化されている。（以前に固定化した？）

BubbleUPnP Serverのconfiguration.xmlの場所を検索

sudo find / -name "configuration.xml" 2>/dev/null | grep -v "run/user"

修正　<proxyMediaServers>　が無かったので、最下部</settings>の手前に追記。

<proxyMediaServers>
  <proxyMediaServer>
    <targetUdn>uuid:bf099b05-a9c3-4ea0-b6e1-c9cb918965cf</targetUdn>
    <enabled>true</enabled>
  </proxyMediaServer>
</proxyMediaServers>

再起動しても、直ぐにKODIを認識するようになった。

しかそ、オブジェクトIDをの固定化？は出来なかったようで再生出来ない。

 

下記の、Virtual Foldersの設定をすれば固定化されるのでは？とのAIの提案なのだがAndroid端末のBubbleUPnPからしか設定できない様なので、とりあえずここまで。

 

2026/01/09　追記　

下記手順はAIが捏造したもので、全く見当違い。

最初の問い合わせの回答に併せて、捏造したことを白状したが途中のやり取りでは公式のドキュメントに記述があるなどと言い出し、嘘を成り立たせるために更に嘘を重ねる始末。

Geminiで調査していたが、Copilotより利口そうな気がしていたがずる賢いだけかもしれない。

こちらが調べて証拠を突き出すまで嘘を何重にも重ねて間違いを認めなかった。

階層を浅くする（Virtual Foldersの設定）

＊AIの回答なので、未検証で虚偽情報の可能性あり

 

Android端末のBubbleUPnPアプリを使用して、サーバー側に**Virtual Folders（仮想フォルダ）**を登録する具体的な手順を説明します。

この操作を行うことで、サーバーの configuration.xml に情報が書き込まれ、以降は管理画面やfidataから固定された階層として見えるようになります。

事前準備

  1. Android端末をKodiやBubbleUPnP Serverと同じWi-Fiに接続します。

  2. Google Playストアから**「BubbleUPnP UPnP/DLNA License」**（有料版）または無料版のBubbleUPnPアプリをインストールします。

    • ※Virtual Foldersの作成・維持には、多くの場合ライセンス（有料版）が必要です。

Androidアプリでの設定手順

  1. レンダラーとサーバーの選択

    • アプリ右下の [Now Playing] か [Library] を開き、画面上の「Select Renderer」で [Kodi (proxy)] を選択します。

    • 「Select Library」で、元の [Kodi] （プロキシではない方）を選択します。

  2. 登録したいフォルダを探す

    • [Library] タブから、Kodiの中身を辿り、固定化したい（fidataの一番上の階層に表示させたい）フォルダ（例：「Music」や「Artists」）を表示させます。

  3. Virtual Folders への追加アクション

    • そのフォルダ名の横にある 三点リーダー（︙） または 長押し をします。

    • メニューの中から [Add to Virtual Folders] をタップします。

    • ※この瞬間に、Androidアプリからサーバー（:58050）へ「このフォルダを固定IDで登録せよ」という命令が飛びます。

  4. 登録の確認

    • Androidアプリの [Library] のトップ画面（一番上の階層）に、新しく [Virtual Folders] という項目が出現しているか確認します。

    • 出現していれば成功です。

サーバー管理画面（PCブラウザ）での事後確認

Androidでの操作が終わった後、PCから管理画面（:58050）を開き、以下の事実を確認してください。

  • [Settings] > [Advanced] （あるいは [Library] セクション）を確認します。

  • これまで存在しなかった [Virtual Folders] というセクションが出現し、そこに先ほど追加したKodiのフォルダパスがリストアップされているはずです。

fidata（iOS）からの見え方

  1. fidataアプリでサーバーを一度選択し直すか、リロードします。

  2. ライブラリのトップに [Virtual Folders] という項目が現れます。

  3. 重要： 今後は、Kodiの深い階層（Music > Library > ...）を辿るのではなく、この [Virtual Folders] 直下のフォルダから曲を選んでください。ここから選んだ曲には「固定されたオブジェクトID」が割り振られるため、Kodiを再起動しても再生トラブルが起きにくくなります。

 

KODIの内蔵SQLの代わりに、SynologyNASのMARIA DB・NASのファイアウォール設定で動いた^^;

Kodi DS419slim 音楽再生環境の手順整理

外部SQLの運用に失敗、データベースは更新されているのにライブラリは空になっていしまう。

データベースが更新されてデータが増えている事は、phpMyAdminから確認できた。

RaspberryPiにMARIA DBをインストールして使用出来ているので、NASの環境に問題がある？

ncos1.hatenablog.com

 

調べていくと、ファイアウォールで止まっている場合もあるみたい。

どうやらデータベースのsongビューが空っぽみたい、ファイアウォールのせいなのか？

NASにもファイアウォールがあったので変更する。

MARIA DB（3306ポート）を許可する設定を追加。

 

 

前回DBを作っていたが、そのDBはだめ（ビューが空）なので再作成（再スキャン）したら、表示・再生出来た。

ファイアウォールの影響で、ビューが記録されずNGだった？

NASのにファイアウォールが有ることを忘れがちなので、ルーターにも有るから無効化しても良いかも？

データベースを他のRaspberryPi等でも動作させる場合にも、ファイアウォールの設定で3306ポート等設定したポートの解放する必要がある。

 

動いたが、NASのCPUが非力なので動作が快適なのかは体感できない。

ライブラリスキャン中でも、特にCPUもメモリも逼迫していなさそうだけど速くなっていないか遅いくらいな気がする。

＊前回RaspberryPiにインストールMARIADBのときより明らかに遅い、倍以上の時間がかかっても終わらないがNASのCPU負荷は高くないのでLAN・HDD等のIO側の問題と思われる。

動作を快適にするにはNASの性能やKODIの稼働しているRaspberryPiのマシンパワーが必要っぽい^^;

そもそもDBの動作分軽くなっても、たかが知れているのかもしれないが今後データ増えることはあっても減ることは無いので未来の負荷対応環境が検証出来た。

 

AIに聞きながら設定したが、そもそもの元ネタはKODIが複数存在する場合に、同一のライブラリデータベースを使用して視聴途中のデータ等を統一化する目的のページからみたい。

以前にKODI関連で検索した時に見覚えがある、おそらく英語？を翻訳しているので読みにくいし複数KODIから一つのライブラリデータベースを使うのは面白そうだと思ったが全く必要無かったのでよく見ていなかった^^;

Mirakurun　とかで録画サーバー作って、複数のKODI端末からテレビ録画視聴する環境作ったら便利そうだけど(・・?

www.thefastcode.com

もう少し確認したかったので、AIに要約してもらうと外部SQLを使うとしたら複数のKODIで統一したデータベースを使う環境以外はあまり効果的ではなさそう。

項目 内部（SQLite） 外部（MySQL）
同期 単体向け; 他端末と同期しない 複数端末でライブラリ共有・同期可能
パフォーマンス 軽量・ローカル高速 ネットワーク依存; 同時接続で有利
バックアップ/復元 ファイル単位で簡単 中央DBで一括管理・運用が必要
設定難易度 低い サーバ構築・設定が必要
障害時影響 影響はその端末のみ サーバ障害で全端末に影響

 



 

EPSON　EWM770T　プリンターエラーで使えないので対処　（エラーコード　000041）

トラブル対応 プリンター

EPSON　EWM770T　電源投入時に、プリンターエラー（エラーコード　000041）で停止して使えなくなった。

ncos1.hatenablog.com

 

一度（二度？）発生して、その後はしばらく使えていたのだが、修理は出来ないので壊れるまで使うしか無い(T_T)

なぜなら、エプソンから

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

  【修理受付期限のお知らせ】
 ご利用の EW-M770T/TW に関する
「修理対応期間終了」事前ご案内

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

お客様に長らくご愛用いただいております、
下記の対象製品につきまして、
記載の日程で修理対応受付が終了となります。

---今回ご案内の対象機種と修理対応受付期限 一覧---

修理対応受付期限：2025年10月31日(金)

とのメールが届いているから。

 

自力で出来ることを試してみる。

 

epson プリンターエラー　000041　で検索

キャリッジ部分の透明フィルム（透明にメモリが印刷している）清掃で復旧した例もあるみたいだが、復旧しなかった。

（メモリでプリントヘッドの移動量を測定している様なので、別の要因では効果があると思われる。）

用紙トレイを全て外してもNG。

エラーコード　000041　を確認。

https://faq2.epson.jp/web/Detail.aspx?id=50404

000041
000043
000044
000047
000051		 プリンター部の用紙詰まりおよび異物を除去することにより解決の可能性があります。

1.プリントヘッド（印刷時に左右へ動く部分）の周辺や、右隅か左隅の奥側に異物がないかを確認します。
2.カセット給紙に対応した機種をご利用の場合、カセットを外して、奥をのぞき込み用紙詰まりがないか確認します。
3.カセット給紙に対応した機種をご利用の場合、背面ユニットを外して、背面ユニット部およびプリンター部にそれぞれ用紙詰まりがないか確認します。
対応方法はあわせて、こちらもご確認ください。

上記の対応を行っても改善しない場合は修理が必要となります。詳細はこちらをご確認ください。

紙詰まりは確認した限り無いので、プリントヘッドに関連する問題と思われる。

可能な限り清掃をしていたところ、プリントヘッドが動くことに気がついた。

清掃で復旧したので写真は撮り忘れたが、以前清掃しようとして動かそうとしても動かなかったのに少し抵抗は有ったが左へスライドしてホームポジションが露出した。

通常は、印刷時以外はホームポジション固定されていてインク漏れ等の汚れを防いでいる。

その周辺に、グリスや軟膏のような状態になったインクがべったり付着していた。

綿棒やティッシュで拭き取って電源を入れると復旧した、もっときれいにしたかったが周辺はデリケートそうだったので、必要以上に触らないほうが良さそうなので汚れ以外は極力触らないようにした。（修理出来ないし(T_T)）

再発するようなら、再度清掃しよう。

 

KODIの内蔵sqlの代わりに、SynologyNASのMARIA DBを使ってみるが失敗

Kodi 音楽再生環境の手順整理 DS419slim

KODI内蔵sqlサーバーの代わりに、同一筐体内の外部sqlサーバーは使えた。

 

ncos1.hatenablog.com

 

負荷分散とレスポンス向上が可能か外部ハードウェアのsqlサーバーを使えるか確認。

とりあえずSynologyのNASに　MARIADB 10を入れて検証してみる。

qiita.com

スペックは高くないので、体感できるほどの変化はないかも^^;

まずはインストール。

既存のNASのパスワードが規則に即していないので、MARIADB用に堅牢なパスワードを要求される。

大文字・小文字・数字・特殊文字を混ぜる。

既存のNASののパスワードとは別管理無ようだが、既存のNASのパスワードが堅牢だったら共通でも可能？

GUIツール　PhyMyAdmin？　phpMyAdminの事っぽいのでインストール。

インストールしない場合は、NASのにssh接続で設定が必要。

設定したパスワードでrootログイン。

NASのWebとは別に開かれる。

ユーザーアカウントを作成、前回コマンドで作成したkodiを作る。

データベース作成そのものはKODIが実行するので、アカウントだけ作成すれば良いはず。

アカウント　kodi

パスワード　無し　にした。（音楽でーただけなので、本当はだめ^^;）

が、弾かれたので長いパスワードにした。

最下部の”実行”で作成される。

以上でNAS上にDBが作成されるはずなので、RaspberryPi側のKODIの設定。

 

sudo nano /home/ユーザー名/.kodi/userdata/advancedsettings.xml

設定ファイルの書き換え
変更前のコード（ファイルが存在しない、または空の状態）なので、

変更後のコード（MySQL/MariaDBを使用する構成）にする。

下記は記述例なので、現在の記述に合わせて調整。

<advancedsettings>
    <videodatabase>
        <type>mysql</type>
        <host>NASのIPアドレス</host>
        <port>3306</port>
        <user>kodi</user>
        <pass>設定したパスワード</pass>
    </videodatabase>
    <musicdatabase>
        <type>mysql</type>
        <host>NASのIPアドレス</host>
        <port>3306</port>
        <user>kodi</user>
        <pass>設定したパスワード</pass>
    </musicdatabase>
</advancedsettings>

 

KODIのサービスを再起動する。

sudo systemctl stop kodi.service
sudo pkill -9 kodi || true
sudo systemctl reset-failed kodi.service

クライアント側で確認。

NG、起動しなくなった。

権限の問題で、データベースファイルが作成出来なかったみたい。

グローバル権限を、すべてチェックする　を選択して下部に”実行”で起動するようになった。

 

音楽ライブラリが空で何も登録できなくなる、ライブラリ更新を実行する。

更新されない？のでリモートで確認。

更新しているっぽい、のでしばらく待つことにするがローカルのDBより遅いかも(・・?

DBは作成されているが、クライアントのfidataには何も表示されない？待てば良い？

ローカルの場合はスキャン途中でも表示していたが、完全に外部サーバーだから？

終了まで待ってみる。

NG、クライアントのfidataアプリからは曲が見えない(・・?

NASの内のデータベースは更新されているが、うまく構築できていないのか参照するのに制限がかかってしまうのかKODI本体側でも更新したライブラリが反映されない（表示出来ない）みたい。

 



 

LINEミニアプリでは、ファイルのダウンロード出来ない？

LINE 自作Webアプリ

RくんをLINEミニアプリにしてみた。

（とは言ってもGitのリンク指定するだけで中身は同じ）

ncos1.hatenablog.com

 

ブラウザで、”設定値をダウンロード”で保存したファイルを”設定値を読み込み”で読み込める事を確認。

 

しかし、LINEミニアプリからは、”設定値をダウンロード”をタップしても何も起きない

(・・?

制限があってダウンロード出来ないみたい、クリップボードにコピーは出来るらしいがそこまでするならブラウザー限定で使ったほうが混乱しなさそう_φ(･_･

 

以下AIの出力

LINEミニアプリでは、ブラウザ環境と異なり「設定値の管理画面から直接ダウンロード」機能は制限されており、現状は公式にサポートされていません。対応策としては、

管理用データを外部ストレージやAPI経由でエクスポートする仕組みを組み込む

LINE Developersコンソールやブラウザ版での操作を併用する といった方法が推奨されています

 

との回答。

検証を整理すると、既存のブラウザーからダウンロードして保存したファイルの読み込みは出来るのだがダウンロードが出来ない。

ブラウザから使う、ミニアプリにしてダウンロードしたい場合はブラウザから開くようにすれば良さそうだけど、他に何か対応策有るかな(・・?

 

 

KonaLinuxPi　upmpdcli.conf　を修正して、OpenHOME有効化・DLNAレンダラー名変更・不要なレンダラー無効化

RaspberryPi トラブル対応 音楽再生環境の手順整理

KODIのオブジェクトID固定化に挑戦・失敗(T_T)

 

ncos1.hatenablog.com

 

途中で、upmpdcli　の設定で可能では？とのAIの回答があったが、見当違いで全く効果の無い手順だった。

 

upmpdcli.conf　の変更だったが、OpenHOME有効化やレンダラー名変更などが含まれていたので今後の参考に残しておく。

 

upmpdcli.confを編集

sudo nano /etc/upmpdcli.conf

 

DLNA・OpenHOMEコントローラーアプリ（fidata）に表示される名前を固定

現在

#friendlyname = UpMpd-%h

コメントアウトを外して、つけたい名称にする
friendlyname = RaspberryPi-ncos1

 

OpenHome機能を有効化

現在

#openhome = 1
openhome = 1

 

upmpdcli再起動すると、コントローラーアプリからレンダラー名の変更が確認できる。

 

sudo systemctl restart upmpdcli

 

OpenHOMEは、以前動作確認したときには設定変更せずとも有効化になっているみたいだったが環境によっては有効化した方が良いのかも？

 

openhome = 1　の記述の上部に

# Enable UPnP AV services (0/1).
#upnpav = 1

が有る、upnpav =0　にしたら使うことが無いはずの、AV用のレンダラーを消せるかも？

upnpav = 0

にしてみる。

消えた。

音楽用のレンダラーも、ほとんど使うことがないがAV用は全く使う予定無いのでスッキリした。

これが一番の収穫だった(^^)