RaspBerryPiのipv6アドレス固定によるdlnaサーバ機能の改善を期待したが期待外れ

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アドレスは無関係と思われる事が判った事が収穫。

時々いろいろな状況を整理しつつ、再確認・再設定してみよう。