読者です 読者をやめる 読者になる 読者になる

なんとなく

誰得感満載な記事が多いかも。Mono関係とLinuxのサーバ関係、レビューとか。

RockDiskNextのminidlnaのバグとか

minidlna RockDiskNext

RockDiskNextを購入して1ヶ月ほど経ったので、レビュー的なのをしたいと考えていたのですが、メディアサーバ(minidlna)についてリリース版であるにも関わらずちょっと残念なバグも見受けられるのでそれらをまとめておきます。

RockDiskNextは挑戦者ブランドということで、仕方のないとすることもできるのですが、サポートも付いているので微妙な感じになってます。

答え合わせができましたので、記述しました。
念力デバッグの答え合わせ(RockDisk Nextのminidlnaのバグ関連) - なんとなく

さらに関連したバグが有ったので、記述しました。
RockDisk Nextのminidlnaのバグには続きがあった。。。 - なんとなく

2GB以上のDSFファイルがタグ取得に失敗

minidlnaにバグが有るようだということは購入する前からわかっていた

購入する以前から挑戦者BBSをのぞいていて、minidlnaで2GB以上のDSFファイルのタグ取得に失敗して、表示されないファイルがあるということはうすうす感じていました。

DLNAサーバーとしてファイルを探索した際に、Browse Foldersのメニューをたどると存在するはずのファイルが、Musicのメニューからたどると見当たらないことがあります。
 おかしいなと思っていろいろ調べてみたところ、Music以下のメニューに登場しないファイルは、すべて2GB以上のDSFファイルであり、これらのファイルではタグ情報が消えていることがわかりました。

http://bbs.ioplaza.jp/forum/index.php?topic_id=2321

これをみて、私はタグとしてうまく生成されず、表示されない状態であり、2GB以上のファイルであるということから、

minidlnaのDSD対応のバグのように思えます。
おそらくDSFファイルのscan時にfseekもしくはftellを使っているのではないかと。
2GBを超えるファイルの扱いの部分でのバグだと思います。

IOさんに確認して、対応してもらうしかないと思います。

http://bbs.ioplaza.jp/forum/index.php?topic_id=2321#post_id9336

と回答しました。

というのも実は私も#RaspberryPi でDSDを配信できるminidlnaを作ってみた。 - なんとなくにおいて対応時にハマったので、あたりをつけました。

当時、どうハマったかというと、

  • ファイルは開けていた。
  • DSFファイルのヘッダにPointer to Metadata chunkがあり、Metadataの場所を示しており、この値は8byte(64bit)と定義されている。
  • Metadataの場所までseekする際につかうメソッドのfseekは、
int fseek(FILE *fp, long offset, int origin); 

offsetにそのまま取得した値を代入するとlongなので32bit(2147483647L)までしか扱えない。

  • 解決策としてfseekoメソッドを使用し、64bitまで扱えるようにした
int fseeko(FILE *fp, long long offset, int origin); 

それがうまく行ってないのかな?と当たりをつけたのですが、外れていました。

購入後にログ(/home/.nas/minidlna.log)を確認したところ、

[2014/07/31 17:08:38] tagutils/tagutils-dsf.c:77: error: Cannot open /mnt/nas/Lindberg - Oslo PO Rundel - Berio, Xenakis, Turnage Trombone Concertos/01 - SOLO.dsf

とあり、おそらく、fopenで失敗しているようでした。「マジかよ。そこかよ。」という感じでした。

さらに、このログは出力される場合とされない場合がありました。おそらく以下に記述する/パーティションが100%になるのと同様の理由だと思います。
cronをインストールして、定期的に/tmp/id3.tagをチェックして、存在した場合削除するというスクリプトを実行させたところ、ログには出てくるようになりました。
rpmのインストールとかはそのうち記述したいと思います。

Latin-1の拡張文字(áとかäとかéなどなど)がファイル名に含まれているとタグ取得に失敗

さらにログを見ていたら、2GB以上のファイルではないものでも同じ所で(おそらくfopenで)エラーが出ているものがありました

[2014/08/06 12:48:01] tagutils/tagutils-dsf.c:77: error: Cannot open /mnt/nas/St Petersburg Academic Symphony Orchestra, Alexander Dmitri - Yevgeny Svetlanov Alexander Skryabin/05 - St Petersburg Academic Symphony Orchestra, Alexander Dmitri - II. Voluptés (Delights). Lento.dsf

範囲は詳しく検証していないので、不明ですが、どうもU+00C0~U+00FFのぐらい(Latin1拡張)の文字コードがあるファイルがタグ取得に失敗しているようです。minidlnaでどのバージョンで対応されたかは調べていないけど、masterで対応されているので、対応してほしいです。

9/15追記。ソースコードを確認したら対応するバグはなく、私の確認ミスでした。訂正したします。

システムが不安定に、スキャンの時間がやたら長い

さらに上述したバグ(どちらかは不明)は、システムを不安定にしていると思われます。minidlnaのファイルスキャン時にtail -fでログを確認していると当該バグが発生すると思われるところで、scanが止まっているよう見え、/が100%になっています。

[root@iwa ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
ubi0                  197M  197M  8.0K 100% /
none                  125M     0  125M   0% /var/tmp
none                   20M  140K   20M   1% /var/log

こうなるとGUIでの操作はできなくなります。データエラーというダイアログが出たり、adminでログインできなくなったりしました。

DSFファイル400個程度のスキャンに200分かかります。

12分41秒以上の曲の再生時間(Duration)が表示されない。。。(DSD64で)

DSD64のファイルで12分41秒ぐらいより長い曲について、再生時間がクライアントによってはおかしく表示されたり、全く表示されなかったりします。
sqlite3で/home/.nas/files.dbの中身を確認したところ、対象のカラムに0:-12:-3.000のような値が入っています。
簡単に調べてみたところDSFファイルのSampleCountが2147483647より大きいデータで発生しているようです。

つまりプログラム中で変数の型を64bitで扱わなければいけないのを32bitの型で扱っているようです。

DMCから操作する時に、再生時間は見るものでこれが表示されないと使いづらいくて仕方ないです。

再生時間は、(SampleCount/SamplingFrequency)*1000としてタグに格納しているので、DSD128のファイルは所有していないけど、DSD128だと6分すぎる曲の再生時間が表示されないと思います。

バグかわからないけど、録音日時のロケールがおかしい。

おそらくminidlnaの仕様なんだろうけど、yyyy-dd-mmでTDRCに格納されています。。。
ちなみに自分は気持ち悪かったし、対応するのが面倒くさかったので、年だけ取り扱って月日はタグにしてないです。Mp3tagでも年のみにしているようです。でも、これは仕方ないのかも。

ちょっとバグバグだったので、自分で直そうと思ってソースの開示方法を確認したら。。。

もー、バグが多すぎるし、minidlnaのライセンスはGPLなので自分で直そうと思ってソースの開示方法をサポートに確認してみました。

サポートにフォームから開示の方法を確認したら、1週間以上経って(通常は3営業日程度らしい)やっと回答があって
「確認のためしばらくお待ちください。」
というニュアンスの回答でした。

「ん?3営業日程度での回答ならそれでいいのかもしれないけど、1週間以上経っての回答としてはおかしいでしょ。」と思ったので、
「それはないでしょ。購入前のサポートに確認したら、ソース開示はできると回答もらったよ」と返しました。
そしたら、
「時間がかかる見込みで、いつ頃ご用意できるか未定の状況。準備出来しだい連絡する」というニュアンスの回答を得ました。

ライセンスがGPLのものをバイナリで提供してるのにソースの開示できるのが未定ってどういうことなのでしょうか。。。
開示しないというわけではなさそうだから、待つことにしたのだけれども、提供側の体制としておかしいと思います。

問い合わせから1ヶ月ほど経ちましたが、まだ連絡はありません。

追記(8/23)
8/20に連絡がありました。
しかし、準備出来しだい連絡と言っていたにも関わらず、ちょっと意味不明な対応をされました。。

こちらにどうしてほしいか説明もなく、「ソースコードについて、添付ファイルで送付します」と言って、RockDiskNextで使われているRPMとソースの入手先リスト内容が送られてきました。ソースコードをメールに添付してきたわけではなかったです。

内容を確認すると入手先にはRPMを構成するパッケージのプロジェクトのトップページのURIが記されていました。完全なソースコードはそこではなく、Fedoraプロジェクトにあるんじゃないかと思います。

このリストを受け取っても、説明もないし、内容も微妙だし、こちらは「???」となるばかりです。

そこで確認したら、「ソースコードは入手先からダウンロードしてほしい」と返信がありましたが、入手先でダウンロードできるソースコードが完全なソースコードではないと思われますし、送付されてきたリストにはLinuxカーネルのソースなど足りない項目がまだあるように思われます。さらにminidlnaについて言えば、改変しているにもかかわらず、リストに記述してある入手先はsourceforgeだったりします。

こちらとしては、ライセンスに従ってLANDISKなどと同様の方法(実費を支払ってメディアを郵送してもらう方法)でソースコードを提供してもらえれば、それでいいのですが、このような対応をされるのはなぜなのだろうと思います。
もしかして、完全なソースコードが手元に存在しないものもあるのかなと疑っています。あくまで推測にすぎないので、サポートの回答を待つことにします。

2015/02/11追記
詳しくは、
GPL違反!? IODataにRockDisk Nextのソース開示請求をしてみた。 - なんとなく
にまとめました。

サポートの範囲は。。。

RockDiskNextは挑戦者プレミアムで1年間のサポートが含まれているようなのだけど、サポートの範囲が明示されていなくて挑戦者ブランドのようにBBSでのみではないようだし、WEBUIだけのサポートなのか、動いているOSであるlinuxまでのサポートなのか範囲が不明なのです。

ちょっと調べれば、rootになれるし、WEBUIは使わないようにしているんだけど、それでサポートが受けられるのかも明示されていない。メーカーとしての意思が微妙で、挑戦者なのだからサポートしないからBBSで頑張ってよともならず、たぶんメーカーの想定外の使い方だよなというところも範囲が定義されてないのです。

サポートの範囲について明示すべきだと思います。

追記(8/23)
気づいたのだが保証書がない。購入時のメールで購入後1年は保証はしてくれると書いてあったが、何を保証してくれるのだろうか。保証対象は。。。