kodiのdlnaサーバをスマホのfidataアプリから使用している。
自宅のネットワークのIpv4に負荷が大きい場合にtorneやどこでもDIGAは再生停止したり繋がらなかったりする（宅内・宅外共通で発生）がfidataでの音楽再生は全く問題ない。（ロスレスデータなので、宅外の動画再生よりデータ量は多きにもかかわらず。）
以上から、kodiとfidata間はipv6で通信していると推測。
vpn環境もipv6対応しているので、宅外でも通信は非常に安定している。
ipv6での疎通確認サイト、亀が動けばOK。
www.kame.netkodiが稼働しているRaspBerryPiを再起動すると、fidataのキューシートが使えない。（スキップする、参照元を確認すると使えるがアルバム毎に必要なので不便。）
ipv6で繋がっているならば、ipv6アドレスが変更された場合に参照元が不明となったいるのでは？と推察。
現在のアドレス確認 （ブリッジ使用しているのでbr0、未使用ならeth0で実行）
ifconfig
br0: flags=省略
inet6 ”現在割り振られているアドレス” prefixlen 64 scopeid 0x0<global>
設定ファイル編集
sudo nano /etc/network/interfaces
下記を最終行に追記
iface br0 inet6 static address ”確認したアドレス” netmask 64
で再起動後も、同一にできたが改善しなかったので元に戻した。
ipv6アドレスはプロバイダから割り振られると思われるので、確率は低いと思われるが重複する可能性も有るかも？なので戻した。
設定戻して再起動しても同じアドレスだったので、推察は的外れだった？
パナソニックのMusic Controlアプリでは再起動してもキューシートは使えた（ただし、vpn環境で接続できないので常用不可）のでfidataアプリ側の問題と思われる。
MusicControlアプリがipv6対応なのかは検証不十分。
2024/01/16 確認、MusicControlアプリでもNGになる場合があった、何が要因なのかは不明のまま。
dlnaサーバー名でキューシート情報を管理しているとは思われるが、再生時にその他のアドレス情報を使用している（キャッシュ？）からスキップするが参照元を確認するとサーバ名からたどってファイルが確認できて、その後は再生可能となるのか？
今回は、RaspBerryPi再起動後のfidataキューシート無効に対してipv6アドレスは無関係と思われる事が判った事が収穫。
時々いろいろな状況を整理しつつ、再確認・再設定してみよう。
