miniDLNAのDB形式とジャンル階層の不備

# 2020/05/25
この記事で用いたminidlna-1.1.5は安定度に問題があり、実運用には至りませんでした。
その後、miniDLNA1.2.1を用い、
・◇RaspiにminiDLNAをソースから入れる
・◇miniDLNAでジャンルにalbum層追加
の手続きにより運用可能となりました。

---

備忘録

RaspberryPi3に導入したminiDLNAですが、 ジャンルの下の階層が浅く僕の使い方には適さないので 修正を検討しています。
miniDLNAのDBの形式を調べました

◆RasPiでDLNAサーバー(iTunesから移行)の続きです。
この後◆miniDLNA改、仮リリースへ

 miniDLNAのDB形式

フォルダ構成はOBJECTSテーブルで管理されています。
アーティストやジャンル、アルバムなど色々なものが全てOBJECTSテーブル に入れられます。

次のような階層構成を取っています。idは階層毎に$で区切られた形で与えられています。 例えば"1$6$F"の下には"1$6$F$5"などがあり、PARENT_IDで"1$6$F"を参照しています。

ジャンルの下に置いたアーティストを開くとアルバムが出ず、直接曲が出てしまうのは DB構成がそうなっているからです。

フォルダのブラウズ部は特殊なことはやっていないようにみえますので、 おそらく、ジャンルの下のアーティストと曲の間にアルバムを挟めば、 問題は解決するのではないかと考えられます。

実際にDBにアクセスした例を置きます。 DBアクセスの例

miniDLNAプログラムでこれに対応するSELECT-SQLを発行しているのは upnpsoap.cのBrowsing ContentDirectory部です。

 スキーマ

 OBJECTSに関し

CLASSはこのデータで動かすべき動作を表しています。
Artistリスト下のアーティストとGenreの下のアーティストに差はありません。

REF_IDはフォルダリストのidとなっていますが、利用しているところは見つかっていません。

 DEATILSに関し

おそらく、CREATORがARTISTでARTISTがALBUM ARTISTなのだと思われます。

Composer項目はありません。ただしaacタグ解析部ではComposer項目を取得しています。 DBに追加するのは簡単かも知れません。

 ジャンルの修正

DBを作るロジックは左程難しくはありません。

オーディオファイルでタグ情報を取得した時点で、ジャンルやアーティスト、アルバムが分かりますので、 DBのツリーに曲名レベルのOBJECTSレコードを作ります。その前にその上位となるレコードを検索し、 なければ作ります。
あるいは根元から順にたどり、無ければ作るという形が簡単確実かも知れません。

ツリーの階層をconfで指定できるようにすれば、現在の固定的なものではなく柔軟なものが出来ます。
例えば「作曲家-曲」といったことや「アーティスト-アルバム-曲」「アルバムアーティスト-アルバム-曲」 など自由に指定できるようになります。

とはいえ、、、また今度のココロ だ！◆miniDLNA改、仮リリースへ