なんというタイトルだとお考えの方も多いと思いますが、ちょっと過激に。

JPLAYfemtoはJRIVERでコントロールするのが一番だと言う意見が多いですね。僕はJRIVERユーザではないので、この意見に対して適切なコメント出来ないのですが、「アルバムの整理がきちんと出来たライブラリを持っていれば、その通りかな」と思います。
というわけで、このスレッドは怨念(^^;;;)のJPLAY-JRIVER対決に決着をつけるべく、この二つを組み合わせてベストの音質と操作性を求めるためのテクニカルな意見交換の場にしたいと思います。

まず、とっかかりに、「JPLAY FEMTO」スレッドでmoriさんの「jriver24をコントロールポイントとして、レンダラーにfemto、サーバーにfemtoserverを選択して、普通に再生できています」という質問(No6020)に対して、僕の回答(No6021)「JRiverを別のPCに置くと、femtoServerの中身が見えなくなります」というのは誤りというご報告から。

JRiverを別のPCに置いても、femtoServerの中身が見えるし、再生することも出来ますね。こうすると、シングルPC側ではJRiverを動きませんので、オーディオ的には有利になりそうです。
やり方ですが、JRiverの使い方には慣れていないので、これで正しいのか、皆様方に確認して頂きたいと思います。よろしくお願いします。

①JRiverをインストール(僕の持っているのは21.0です)。
②Tools -> Options -> Media Network
③Use Media Network to share this library and enableb DLNA をマーク。Access Key(KzySeN)を入力。
④これで、JPLAYfemtoとJPLAYfemtoServerが立ち上がっていれば、それぞれPlayerとPlaying fromから見えるようになるはずです。
⑤見えるようになったJPLAYfemtoServerをクリック、Load Libraryをクリック。DLNAフォーマットがおかしいとか文句をいってくるが、無視してOK。ロードさせる。
⑥ロードが完了したJPLAYfemtoServerを右クリック。Media Importというダイアログが表示されるので、Import a single folderを選択、Nextをクリック。Please select the folder to searchにfemtoServerで使用しているNAS or Diskを指定する(NASはホスト名を使って指定できます)。Finishをクリック。
後は、ひたすら待つ。僕の場合はNASがバカでかい(4T)ので、36分04秒かかりました。

終了すると、めでたく、femtoServerが普通(?)のDLNAサーバのようにアルバム名やアーティスト名で取り扱えるようになります。
⑥の部分のやり方がよく分かっていなかったのですよね。moriさん、失礼しました。訂正してお詫びいたします。

yo様

初めまして。

タイトルに惹かれどの様な内容なのか拝見させて頂きました。

私はfemto serverのNAS設定が上手くいかずにJMCに流された者です。一度同じ事を実行しましたが、ライブラリ設定でアラートが出てこれはダメだと諦めていました。

今回yo様の方法でfemto serverにライブラリを設定出来て音出しにも成功致しました。素晴らしいです。
player>audio pathを見るとinput もoutput もnot using JRiver audio engineと表示されておりますのでfemto serverが稼働して音が出ている事に間違い有りません。音も駄耳ですが透明感が増した様に思います。

また、JRemoteからもコントロール出来ました。完璧です。私にとっては「有難やJMC」です。

yo様
お詫びだなんて、とんでもありません。本件については、意外に情報が無くて、不安でしたが、お陰様で安心できました。
Jriverをコントロールポイントにすると、アルバム名やアーティスト名で扱える他、プレイリストも簡単にでき、Jremoteも使えて、操作性は大変よろしいかと思います。

yoさん、こんばんは。

新しいスレッドの立ち上げたいへんありがとうございました。

yoさんの実践された方法で普通にやりますと確かに読み込めますしタグ情報からたどる選曲ができるのですが、実はここに疑問があったのです。まてよ、、何か変だな、どうしてこれができるのかと。（FEMTOサーバーはタグ情報を提供しない（推測）はずなので。またminim serverでは読み込み時にSingle Folder選択は不要のはず、、、）

この状態でJRMCに音源ファイルの情報を表示させると、指定したフォルダーのファイル名を表示してきます。（本来ここは同一シングルPCであってもサーバーのIPアドレスとサーバー名がPrefixとなるはずです。minim serverではそうなります）

で、いろいろと確認してみたのですが、JRMCのメディアネットワーク設定で「DLNAサーバーを有効」としていれば再生可能ですが、これを停止させると再生できなくなります。

minim server利用時は当然ながらDLNAサーバー機能を停止しても再生できますが、FEMTOサーバーでは不可です。ということは、上記の音源情報などとも照らし合わせると、JRMCのサーバー機能が生きていてこれで再生してるのではないか、と疑っています。（JRemoteからは現在のサーバーが何かは見えません。JRMC上は確かにFEMTOサーバーが選択されていますが）

また、DLNAサーバー機能を停止した状態でFEMTOサーバーから再生させようとすると、単に再生できないだけではなく、JPLAY FEMTO全体がおかしくなってしまい、再インストールしないと以後何の再生もしなくなります。

現在のところこの程度で問題の切り分けもできておらず、正直五里霧中です。

いやこれでいいんだよ、という当方の勘違いなのかもしれませんし、あるいはJRMCとJPLAYの間にはやはり深くて暗い河があるのか、、、皆様の貴重なアドバイスをお待ちしておりますので、よろしくお願いいたします。


（注記）
本件の狙いは、FEMTOサーバーでは普通フォルダー検索しかできないという制約をクリアーし、使い勝手とFMETOサーバーの音質的メリットの良いとこ取りができるのでは、というものです。

皆さま

私がplayer>audioを見て確認した内容はJriver をplayerとした場合の経路でした。
ゴンザエモンが仰る通りJriverがserverとして動いている可能性も考えられました。そこで、services & plug-inのmedia networkの項目を確認したところ、Soucesの項目がfemto serverのIPアドレスになっておりました。Jriver serverの場合はJriverをインストールしたPCのIPアドレスとなります。
と言うことは、femto serverが働いていると考えられます。

また、間違っていたら申し訳ございません。

motomotoさん

早速のアドバイス、深謝です。

ご指摘の項目当方も確認してみましたが、同一PCでのテストではIPアドレスが同じなので、これでは判別できませんでした。
もう少しいろいろとやってみますね。

なお、メディアネットワークの詳細の項目にあります「DLNAサーバー」機能のチェックを外しても問題なく再生できますでしょうか？

また、JRMC起動時に以下のようなメッセージはでませんか？

選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。
検索する時に接続しているサーバー名とその稼働状況が正常かを確認してください。
問題を解決し再度読み込みをするまでに、ライブラリが未完成の可能性があります。

上記は、FEMTOサーバーのロード時にも出ますし、再生のためには音源場所を指定してインポートが必要になります（ちなみにMinim Serverではそもそもインポートが不要です）。総合的に考えると

「JRMCがメディアサーバーの機能によって、FEMTOレンダラにPUSH再生している」

のでは？　と思えてしまうのです。


皆様、是非お知恵を拝借させてください。

みなさま、おはようございます！

ちょっと気になって早起きしてしまいました（笑）ので、実験してみました。

１．JRMC上のFEMTOサーバーへの（強制）インポートを別のテスト用音源にしてみました。
２．この結果、JRMC/JRemoteではテスト用の音源が見えてきます。（再生可能）
３、mconnectから確認すると、
　　（１）JRMCのメディアサーバーが生きていて、
　　（２）選曲すればこのテスト用音源が再生されます
４．FEMTOサーバーで指定していたはずの音源は見えません。
５．JRMCのDLNAサーバー機能をオフるとmconnectからJRMCメディアサーバーが見えなくなります。

minim serverでは

１．ライブラリに接続した段階で中身が見える（インポート不要）
２．DLNAサーバー機能をオフしても、JRMC/JRemoteで再生できる。

という状況です。FEMTOサーバーとminim serverではDLNAサーバーとしての仕様が違うのかもしれませんが、まだすっきりできていません。

テスト用音源に対する動きから単純にたどれば、やはりJRMCがメディアサーバーとして音源を読み取り、FEMTOレンダラにPUSHしているようにも見えます。（ライブラリの名前はFEMTOサーバーにはなっていますが）

ゴンザエモン様
お尋ね頂いていたのに、気が付かなくて、申し訳ありませんでした。その件については、このスレッドにて解決済みですね。このスレッドでのお尋ね、御疑問の点については、私も同様の思いを持っていました。まず、DLNAサーバのチェックを外すと再生できない、例のメッセージが出る件は、同じ状況です。
私も、JriverのDNLAサーバである、main libraryとfemtoserver　の内容に差異を設けて、Jremoteでの表示を試してみましたところ、PCでmain libraryを選択しているとJremoteもmain libraryの内容を、PCでfemtoserverを選択しているとJremoteもfemtoserverの内容を表示しました。
素人考えですが、DLNAコントロールポイントからは、JriverのDNLAサーバ機能をオンにしないとDNLAサーバであるmain libraryもfemtoserverも見えなくなるのではないでしょうか。

皆様、いろいろ参考になる書き込みありがとうございます。この調子で真相究明したいと思います。

僕が確認したことを書き込みますが、その前に確認のために使用した環境について。

サーバ : Atom機を使った自作NAS Linux Mint Samba
音楽PC : i5 3470専用機、OS Window10 Home 1803版、JPLAYの最新版をインストール
コントロールPC : MS Surfaceノート(常用しているノートです)、OS Window10 Pro 1803版、JRiverの最新版をインストール
コントロール端末 : Androidタブレット BubbleUPNP
DAC : SoulNote D-2 USB接続
ネットワーク構成は僕のサイトを参考にして下さい。
http://mimizukobo.sakura.ne.jp/articles/articles023.html#001" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles023.html#001

サーバ、コントロールポイント、レンダラー全て独立させ、コントール部分は更に操作(Andeoid)と管理(というのかな、MS Surfaceノート)という形で分離しているのが特徴です。JRiverに詳しくないので、ひたすら外側から攻めて、確かめようということです。

この構成で、僕の最初の書き込みの⑤⑥を行いました(前日の内容が保存されていなかったので)。
その後、Andoid端末BubbleDSで④を実施。
レンダラーはJPLAY FEMTO
サーバーはSurface(Generiv DLNA)
を選びます。

この時、BubbleDSのサーバーの選択ですが、選択肢は次のように表示されます。

Bubble Local and Cloud
Surface (Audiophile 24-bit DAC)[192.168.0.6]
Surface (Audiophile 24-bit DAC)[192.168.0.6]
Surface (Generic DLNA)
Surface .....@......
JPLAY femtoServer
MinimServer[mintc]
mintc: minidlna

一番上はBubbleをサーバとして使う時のローカルな接続のためなので無視。
2番目から4番目までがJRiverと接続してコントールするためのものなので、femtoServerと接続用らしい4番目を選択。
5番目はMSのMedia Player用なので無視。
6番目以降が自作NASのDLNAサーバとなります。
従って、6番目を選択すれば、普通にfemtoServerを使うことができます。

さて4番のGeneric DLNAを選択、再生させます。
ここで乱暴ですが、Surfaceノートで起動したJRiverを終了させます。
驚いたことに、再生は継続し、Bubbleの時間表示も更新され続けます。
曲の終わりまで来ると、Bubbleは次の曲に移ろうとしますが、再生は停止します。
ここでSurfaceノートで終了させたJRiverを起動します。
再び驚いたことに、再生が再開できます。
以下、同じことを何度も繰り返すことが出来ます。

いかがでしょうか。再生中はfemtoServerとJPLAYレンダラーが同期して動いていることは間違いないと思います。
念のため、自作PSツールで動作プログラムの負荷を、リソースモニターでネットワーク負荷を確認しましたが、ちゃんと動いているように見えました。

moriさん、yoさん

ありがとうございます。

何だか、「証明合戦」みたいになっちゃってますね。（これもまた楽しいかも、ですが、、、）

JRMC、JPLAYの内部仕様は当方も全く解りませんので結局状況証拠で追うしかないかもですが、謎だな～と思っているのは以下の3点です。

①JRMCの「DLNAサーバー機能」のオフ（注記）の件、minim server（とFEMTOレンダラ）での組み合わせではこれで動きますが、FEMTOサーバーの場合はここをオンにしてあげないと何故か動かないようです。
（注記）DLNAコントロールポイント機能のみオン

②FEMTOサーバーでは音源の「場所を指定して」のインポートがなぜ必要となるのか。（本来は不要？ ここで明示的にインポートすることによって、名前はFEMTOサーバーのままでも実態はJRMCサーバー機能が肩代わりしている可能性はないか？ 今朝の実験から全然関係ない音源もFEMTOサーバーの名称に紐付けできてしまうこともあって）

③FEMTOサーバーはタグ情報を提供していないはずなのに、JRMC上でなぜこれがハンドリングできるようになるのか。

この辺りを突き詰めて議論を噛み合わせる必要がありそうですね。

なお、コントロールポイントが途中停止しても、再生中の音楽は継続されるという経験がありますが、yoさんの実験ではJRMC本体を止めてしまっていますので、JRMCのDLNAサーバーも止まっているはずですよね。ここはminim serverのケースでも同様に止める実験ができそうなので、やってみます。（本日は出かけちゃいますので、明日以降となります）

重ねて皆様ありがとうございます。当方ケチをつけるつもりは毛頭なく、真にJRMC/JPLAYの連携ができているという望外の状況を確固たるものにしたいという意図ですので、この点ご理解をいただくとともに引き続きいろいろとご教授いただければ大変幸甚です。

だいたい結論は出たかなと思います。以下、許可をもらっていますので、そのままJPLAY日本語掲示板のメッセージを引用します。
---------------------------------
JPLAY日本語デスク

> yo さんへ

> 再生中にコントロール管理部分のMS SurfaceノートのJRiverを無理矢理終了させるという実験を
> 行ってみました。驚いたことに、再生は継続し、曲の終了部分でストップ。更に驚いたことに、
> この状態で終了させたJRiverを再起動したら、再生は再開しました。

JPLAY FEMTOレンダラーにバッファリングされているデータが再生され続けます。DLNAレンダラーは今再生中と次のトラックの情報を持っています。

Android端末上のBubbleUPnPをコントロール・ポイントとして再生を開始し、再生が始まったらWi-Fi接続を切ってください。再生は続きます。JPLAY FEMTOレンダラーは既に再生に必要なURLを知っているので、コントロール・ポイントが消滅しても影響はありません。

SoundgenicのTwonkyメディア・サーバーのライブライリーをJPLAY FEMTOレンダラーで鳴らしてみました。再生が始まってすぐにSoundgenicの再起動をかけます。再起動中は設定画面につながりませんが、再生は続いています。これは、再生データの先読みをしてある程度バッファーに蓄えているからです。これが尽きた時点でサーバーにアクセスできないと、当然再生は止ります。

JRMCでfemtoServerライブラリーのタグ情報が全て見えるようになるというのは、インポート時に別途音源ファイルの場所をユーザーに指定させて独立して読込んでいるからで、femtoServerのライブラリーから引出しているわけではありません。
それが証拠に、インポート時にDLANのフォーマット異常のようなメッセージがでるとお書きになっています。MinimServerのようなfemtoServer以外の「普通」のUPnPメディア・サーバーでは、JRiverが想定している方法でインポートできるので、エラーは出ません。しかし、femtoServerが持つ個々のファイルのURLは独自フォーマットのため、JRMCは読込みに失敗するわけです。

現時点でまだ理解できていない点が1つあります。JRMCのDLNAサーバーをオフにし、コントロール・ポイント機能だけを使う場合、MinimServerのライブラリーは見えてfemtoServerは見えないという点です。
DLNAの仕様に準拠したコントロール・ポイントであれば、両者で挙動が変ることはありません。従って、JRMCは独自仕様であると筋が通ります。どの部分が独自であるかは、当然開示されていません。

以上から、JRMCのDLNAサーバー機能をオンにしてJRMCのコントロール・ポイントでfemtoServerを指定した場合、実際はfemtoServerの名を語るJRMCのDLNAサーバーが動いているというのが当デスクの判断です。この仮説で矛盾点があれば、ぜひお知らせください。

このスレッドに関しては、例外としてyoさんの掲示板での引用をOKとしますから、引用はご自由になさってください。
これはJRMCを使わせないためでは無く、femtoServerを使っていると誤解する人が出てくるのを防ぐためです。そうしないと、femtoServerの本来の音質が正当に評価されなくなります。
---------------------------------
yo

> JPLAY日本語デスク さんへ

丁寧な解説ありがとうございます。とても参考になります。

10分以上かかる曲を再生してみれば、切り分けられるかなと考え、試してみました。
確かに、7～8分位で中断されますね。最初のバッファ読み取りで、その位のデータを読み込んでいるということでしょうか。
ちなみに同じことをminimserverで試したら、演奏は曲の終わりまで再生は継続しました。こちらはサーバとしてのminimserverの機能が正しく働いているということだと思います。
ということで、ご明察の通り、importで行う方法はJRiverのサーバー機能を使うことになり、問題有りのようですね。

直前のメッセージとこのメッセージをそのまま僕の掲示板に掲載しますので、よろしくお願いします。
残りの疑問点も引き続き、僕の掲示板で議論するつもりですので，よろしくです。
---------------------------------

ということです。残念ながら決着はつけそこなったようですが、まあいいかという感じですかね。

皆様

既に結論が出ているころで、かめレスで申し訳ありませんがyo様が外攻めていうことなので私は先に報告したDLNA serverの稼働を確認すると言う内攻めで検討してみました。

結論としては当初よりゴンザエモンさんが言わていた通り、「Jriver Media Center（JMC）母艦又はJRemoteからのJplay Femto Server(JFS)ライブラリ再生指示でJFSを飛び越して直接JMC母艦が指定されたファイルデータをJPlay Femto Player(JFP)に送り込んで楽曲が再生されている。」でした。

yo様のJMC上でのJFSにライブラリを登録する操作時のアラートおよびゴンザエモンさんが指摘されておられた起動時にJFSにライブラリの読み込み時のアラートとが出た時点でJMCは隠れてデータを送信する優等生になることまたは替え玉DLNAserver（全く関係ないServerアドレスが生成されたことが有った）を立てることを決意する。そして、JMCはユーザがJFSのデータからJFCで再生指示した時に如何にもユーザの指示通りに動いているかのように振る舞い再生する。

また、dualPCとJMCPCの構成ですが、再生途中でLANケーブルを抜いたところ約２０秒間はそのまま再生を続け、後にこの約２０秒間を１回だけリピートして停止しました。

皆さん、おはようございます。

活発な議論をいただき大変ありがとうございました。また日本語ヘルプデスクの分析情報の提供（ならびに掲載の許可）についても改めて各位に感謝申し上げます。

当方が希求していたJPLAY FEMTO/JRMCの「美しく理想的？」な連携はどうやら夢物語になってしまいそうですが、音質のJPLAY FEMTOと操作性のJRMCの良いとこどりは完全ではなくてもJRMCサーバー（＋JRemote）とJPLAY FEMTOレンダラーの組み合わせで「結構イケル」という共通認識には至ったと思います。本音ではFEMTOサーバーの音質的な優位点も享受したいところなのですが、、、


なお、FEMTOサーバーからのロード時に「選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。」という要となる部分の本質が突き止められればこれはブレークスルー出来そうな気もします。ただこの辺りは開発に携わっている方でないと仕様なのかそれ以外の問題なのか切り分けは難しいかもですね。JPLAYとJRMC、今回は深くて暗い河ではなくて、もう一息で渡れそうな浅瀬だと改めて認識いたしました。

皆様

私は、一抹の不安がありながらも、femtoserverからのストリーミングではないかと思っていたので、このような展開で、
驚きましたが、真実が分かって大変すっきりしました。皆様のご議論がなかったら、誤解したままだったと思います。ありがとうございました。

ゴンザエモンさん
moriさん

今回のJriver Media Center（JMC）とJplay Femto(JF)との連携については期待を抱かせる様な誤った見解を発言してご迷惑をお掛けしました。

結論は残念な結果となりましたが、個人的には少しはJMCとJFの関係が理解出来ましたので良い経験となりました。

今回の検証を行うにあたり、JMCのDLNAサーバ機能を確認する目的で、このyo様の掲示板でも一世を風靡したlightMPD/upnpgwを久々に持ち出して比較していました。かめレスになってしまったのこの為です。

lightMPD/upnpgwとJFで一番大きく異なると感じたのは、データ送信にありました。

JRemoteまたはJMC母艦からの再生指示で

lightMPDにおいては、JMCのDLNAサーバが１曲分のデータを約２０秒間でlightMPDに送り込み、その後はDLNAサーバ活動を休止する。次曲に移行る直前で、DLNAサーバは再開してまた１曲分のデータを約２０秒間でlightMPDに送り込み休止する。これをプレイリストの終曲まで繰り返す。

一方、JFではDLNAサーバは延々とデータをJFアドレスに向かって送信を続ける。次曲に移行してもDLNAサーバはまたゼロからデータを送り続ける。これをプレイリストの終曲まで繰り返す。

lightMPD/upnpgwとDLNAサーバの連携過程は予想通りでしたが、JFとDLNAサーバの働きは意外でした。

このことから、ゴンザエモンさんの見解とは異なり、私はJMCとJplayの間には、なかなか超えられない深い溝があると感じました。
それでも私は、しばらくは使い勝手を優先させてJMCとJplayの連携で使ってみるつもりです。

皆様、討議にご参加いただきありがとうございました。興味深い結果でしたね。

DLNAプロトコルは500ドルを支払わないと開示されないので、詳細を知ることが出来ないのですが、再生中のデータの受け渡し方がある程度分かって面白かったです。渡し方はmotomoto さんが書かれている通りだと思います。
意外だったのは、JRiverのサーバが最初に5分以上のデータをまとめてレンダラー側に送っていたこと。flac圧縮しているとしても100MBを超えるデータ量になるはずで、まさかそんなことをしているなんて夢にも思いませんでした。ネットワーク速度を考えると、数秒で送れるわけだから、無理はないのですが、ビックリです。

可能性はJPLAY日本語デスクさんの

> 現時点でまだ理解できていない点が1つあります。JRMCのDLNAサーバーをオフにし、コントロール・ポイント機能だけを使う場合、MinimServerのライブラリーは見えてfemtoServerは見えないという点です。
DLNAの仕様に準拠したコントロール・ポイントであれば、両者で挙動が変ることはありません。

という部分ですね。つまり、JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで、DLNA関連の情報は自力で取得し、操作性を改善したコントロールポイントを開発することは出来ないか。
「JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで」という部分はJRiver以外のコントロールポイントはそういう作りのはずです。「DLNA関連の情報は自力で取得し」という部分は今回のJRiverのやり方を参考にすればいいし、「操作性を改善」は前の二つがクリアできれば、どうにでもなるでしょう。
てっとり早いのは既存のコントロールポイントに機能追加してもらうことです。適当な作者を物色し、Marcinさんと連絡をとらせる一手じゃないだろうか。提案してみますかねぇ。

皆様、こんばんは。

いろいろな考察、ご意見とても参考になります。

当方も多分に仮説・推測を含めてJRMCOとFEMTOサーバーの連携を紐解いてみました。


①JRMCから見て、FEMTOサーバーは正しくDLNAサーバーとして認識されている。
　・サーバーリストにFEMTOサーバーはちゃんと現れる。
　　（DLNA機能を有効としておけばDLNAサーバ機能はオフでも現れる）
　・音源情報をFEMTOサーバーからロードしようとする（がエラーとなる）
　・JRMC再起動時にもFEMTOサーバーからロードしようとする　（がエラーとなる）

②FEMTOサーバーをターゲットにして強制的にインポートした音源は（おそらく）
　FEMTOサーバーを使用せずにFEMTOレンダラーに送ろうとする。
　・このためにはDLNAサーバー機能が「オン」でなければならないが、この場合は
　　再生可能。
　・DLNA機能が「オフ」でも一応再生を試みる（が結果失敗してだんまり）

③minim serverとFEMTOレンダラーをコントロールポイントとしてのJRMCから利用する
　ことは問題ない。（コントロールポイント機能のみオン）


前提として、ここまでは今までのやり取りからほぼ「共通認識」と思います。
では、なぜFEMTOサーバーの音源ロードに失敗するのか、ということですが、

仮説：
　（１）FEMTOサーバーがタグ情報をJRMCに提供しない、ということによる問題か？
　（２）JRMC、FEMTOサーバー間の情報受け渡しにおける何らかの問題か？


仮説（１）を確認するために④の実験

④実験：
　タグ情報が提供されず、フォルダー情報のみ提供されていたらJRMCはどう動くか確認するため
　全くタグ情報を持たない音源のみJRMCに読み込ませてみました。インポート問題なく終了。
　・JRMC本体では「ファイル」という項目からフォルダー階層を追って選曲可能。
　・JRemoteではこの「ファイル」という検索手段はなく全音源トラックの一覧が
　　表示されるのみ。（実質的に選曲は結構困難です）

　このことから、JRMC自体はタグ情報がなくても、フォルダー階層情報が提供されていれば
　フォルダー階層をたどることができるようになる。
　（これは通常のコントロールポイントの機能でできていることと同じ、ということに
　　なりますね。一方でJRemoteからの選曲操作は極楽操作ではなく、全くの地獄操作に
　　なっちゃいますが）


上記から仮説（１）は「否」となったので、仮説（２）を検証するために⑤の実験

⑤実験：
　上記と同じタグ情報を持たない音源をFEMTOサーバーのライブラリに指定した場合、
　JRMC上ではFEMTOサーバーは存在として現れる（DLNAサーバー機能オフでも）が、
　音源ロード時にエラーになる。（①の状況と同じ）
　「選択されたDLNAサーバーからファイルを回収する時に問題が起こりました」ですね。


このことから、仮説（２）が実証的には正しく、音源情報の連携・受け渡しに
何らかの齟齬が起きているものと推測します。ただし、これは整合性が取れていない、
というだけでもともとDLNAの仕様自体が結構「やわ」だと感じていますので、
仕様の解釈ならびに実装上の違い、ということだけかもしれません。



（追記）
motomotoさんのFEMTOサーバーとFEMTOレンダラー間のデータ受け渡しの件、大変
興味深く拝見いたしました。

JPLAY6.2ではStreamerからJPLAYサービスに送り出された以後かなり細かく刻んで
トラフィックの負荷変動を均一化していましたが、minim serverなどからの読み込みは
ご指摘の通り、現在の曲の終わる少し前にがばっと読み込んでいますので、平準化
されていませんでした。

おそらくですが、FEMTOサーバーが登場した背景はここにもあって、このサーバーでの
読み込みならびにFEMTOレンダラーに受け渡す処理を極めて平準化することによって
負荷変動を抑えつつ正確なタイミングを刻む、ということを全体にわたって適用しようと
しているのではないでしょうか。そうであれば、サーバーの違いによってこの音の差が
生まれる理由が何となく納得できるような気がします。

ゴンザエモンさん、おはようございます。

すみません。重要な情報を引用しわすれいました。
-------------------------------
JPLAY日本語デスク

yoさんのサイトをのぞきに行って来ました。

femtoServerはタグを読込まない、との投稿がありますが、これは正しくありません。
C:\JPLAY\MusicLibraryをメモ帳で開いてみてください。タグ付きファイルであれば、タグ情報も書かれているはずです。

当デスクでも今確認しました。タグ情報らしきものが全く無いので、最初は本当に読込んでいないかと焦りましたが、手持ちのライブラリーは全てタグ除去済みなので、これは当り前でした。
-------------------------------
ということですので、タグ情報は送られているようです。

従って、

> このことから、仮説（２）が実証的には正しく、音源情報の連携・受け渡しに
何らかの齟齬が起きているものと推測します。

という検証結果はこの点でも確認できます。
femtoServerからのload時のJRiverのエラーメッセージの全文ですが

There was a problem retrieving files from the selected DLNA server.
Please ensure that the server you are connecting to supports seach, and that it is running properly.
Your library may be imcomplete until you correct the problem and reload the library.

となっています。二行目の「supports seach」という部分が気になりますね(僕の持っているのは英語版なので、日本語版はここがどうなっているのですかね)。
これがどういう意味なのかは、多分 C:\JPLAY\MusicLibrary を解析すれば、分かるのではないかと思います。
とすれば、これをJRiverが納得するように変換するプログラムを作れば両者の仲違い(^^;;;をとりもつことかできるのではないかと邪推します。
どんなものですかね。

yoさん、みなさま。

おはようございます。　
JRMCからの日本語のエラーメッセージは以下の通りです。

----------------------------------------------------
選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。
検索する時に接続しているサーバー名とその稼働状況が正常かを確認してください。
問題を解決し再度読み込みをするまでに、ライブラリが未完成の可能性があります。
-------------------------------------------------------

タグ情報についてですが、

「コントロールポイントに情報を提供していない」

というところがミソですね。読んでいるのであれば、せっかく読んだその情報をコントロールポイントに提供しないというのには何らかの理由があるのかもしれません。

おそらくそれも「音質」に関する影響を考慮した上でのこだわりなのかも、、、

タグ情報が提供されない状態であれば先の④の実験から、JRemoteでの操作性には全く貢献しない状況なので、当方的には
もし本件の取り込みエラーが解消されたとしても、ちょっとな～という感じではありますが。

引き続き、JRMCとのコラボでの操作性を維持しつつの音質向上策など探ってみようと思います。また、foobar2000（＋MonkeymoteHD）ではどうなんだろうか、という興味も湧いてきてしまいました（笑）

C:\JPLAY\MusicLibraryを覗いてみました。
XMLで書かれているようですが、これは多分DLNAのプロトコルで規定されているフォーマットなのでしょう。

僕の場合、femtoServerには自作NASにある音楽ライブラリを指定しているのですが、全体でフォルダー(CDアルバム)数が5549、ファイル(曲)数が78000以上あります。
[G:\cd]dir /AD /S /B | find /c /v ""
5549
[G:\cd]dir /S /B | find /c /v ""
83602
G:\cdというのがCDをリッピングしたバックアップフォルダーです。

MusicLibraryは1295行。最低限、フォルダーは二行、ファイルは一行が必要なようなので、全体の情報は持っていないようです。実際、中身を調べると、最近アクセスした(聴いた)フォルダーの情報だけ保存されていました。

これに対して、JRMCのタグ情報を利用した操作性を可能にするには、全ファイルのタグ情報が必要となります。
JRMCのloadというコマンドはこのためのものだと思います。従って、「全ファイルのタグ情報頂戴」と要求しに行ったのに、「これだけだよ」というつれない返事が返ってききて、怒り心頭、「こいつのサーチ機能はおかしいぞ、相手にしてやんねぇ」とエラーにして、以降は自身のサーバ機能を使っているということのようですね。
minimserverの場合は全体ファイルのタグ情報を持っていて、それで返事するから、JRMCは「ういやつじゃ、お前はサーバーとして認めてやるぞ」となり、以降、minimserver側のサーバ機能が使われるということになっているようです。

DLNAプロトコルの詳細が分からないので、JPLAYとJRMCのどっちの言い分が正しいのか分かりません。ただ、JPLAYが音質優先で今のやり方をしているとすると、回避策はタグ情報は自力で読み出すというやり方しかなさそうですね。

怨念の対決は続くだなぁ(^^;;;(^^;;;。

yoさんの書かれたJPLAYとJRMCの会話。

「爆笑！」にて拝読させていただきました。

怨念の対決、あるいは深くて暗い河、、、真にその通りでしたね～　　（取り急ぎレスまで）


追記します：

Music LibraryのXMLを見てみました。単純にするために1フォルダー、1曲、カバーアートのみという
構成です。また、見やすくするためにタグで括られている部分などに改行をいれてあります。

この解析が正しいかどうかは自信が持てませんが、タイトル、アルバム、アーチスト、トラックに
ついてはタグ情報を読み込んでいます。不思議なことにジャンルの情報は見当たりません。


---（ビジーな内容なので、ご興味とお暇のある方用）----------------------------------

c:\JPLAY\femto.png

<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/"" target="_blank">http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">

<container id="r-3" parentID="$femtoRoot$" restricted="1" searchable="0">

<dc:title>D:\JIKKEN\</dc:title>

<upnp:albumArtURI>http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/0</upnp:albumArtURI>" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/0</upnp:albumArtURI>

<upnp:class>object.container.album.musicAlbum</upnp:class>

</container>

</DIDL-Lite>

c:\JPLAY\femtoS.png
c:\JPLAY\femtoR.png
D:\JIKKEN\
r-3
D:\JIKKEN\Message\Folder.jpg
http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4
D:\JIKKEN\Message\
f-5
"D:\JIKKEN\Message\01 - 僕の海.flac"　　　　　　　 <-- ファイルへのパスとファイル名

<item id="6" parentID="f-5" restricted="1">

<dc:title>僕の海</dc:title>　　　　　　　　　　　　<-- タイトル名（タグ情報）　　

<upnp:album>Message</upnp:album>　　　　　　　　　<--　アルバム名（タグ情報）

<upnp:artist>アグネス・チャン</upnp:artist>　　　　<--　アーチスト（タグ情報）

<upnp:originalTrackNumber>1</upnp:originalTrackNumber>　<-- トラック（タグ情報）

<upnp:albumArtURI>http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4</upnp:albumArtURI>" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4</upnp:albumArtURI>

<res duration="00:04:50.08" sampleFrequency="44100" bitsPerSample="16" protocolInfo="http-get:*:audio/flac:*">http://jplayfemto/6</res>" target="_blank">http://jplayfemto/6</res>　　　<-- FLAC音源の情報

<upnp:class>object.item.audioItem.musicTrack</upnp:class>

</item>

参考になるかと思いますので、転送します。
------------------------------
JPLAY日本語デスク

yoさんの掲示板では議論続行のようですね。

MusicLibraryの中身を解析すれば、コントロール・ポイントで表示可能なタグ情報をfemtoServerからの情報より増やすことはできます。但し、単純なテキスト・ファイルとはいえプログラムの解析行為は使用許諾契約違反になりすますから、議論される際には留意してください。

フォルダー・ビューの情報だけから、femtoServerのライブラリーがどこのどのファイルを参照しているかはわかります。これを知ることは許可された使用法でできるので、問題ありません。しかし、それらのファイルを直接読んでタグ情報を抽出しようとしても、抽出プログラムが同一PC上に無い場合には参照権限があるとは限りません。

同一PC上であれば、femtoServerに頼らず、JPLAY FEMTOインストーラーで指定したMusic Libraryのパスをレジストリーに見に行けばわかります。
そしてコントロール・ポイント側で抽出結果と実際のfemtoServerからの情報をマッピングさせると、yoさんの掲示板で議論している方々が目指す状態になります。
抽出プログラムの作成とfemtoServerと同一PCでの常駐、およびコントロール・ポイントの大幅変更が必要ですね。

もし本当にやるつもりなら、proxyサーバー的アプローチがスマートでしょう。中身はfemtoServer、タグ情報やサーチを受付ける機能を付加します。そうすれば、どのコントロール・ポイントでもMinimServerと同じタグ情報や検索機能が実現できます。

前回の書き込みの後、JPLAY日本語掲示板で興味深いやりとりしました。参考になるかと思いますので、二つ目のメッセージの後半、話題の記述とは関係ないの部分を削除し、それ以外は時系列順に全てをそのまま引用します。
-----------
yo

> JPLAY日本語デスク さんへ

フォローありがとうございます。

白状すると、僕はフォルダーの階層構造でリッピングしたCDアルバムを管理していて、フォルダービューさえあれば十分で、タグによる操作性の向上はどうでも良いのですが、まあ、なりゆきで(^^;;;、頑張っています。

このメッセージも大変に参考になりますので、ありがたく転載したいと思います。問題があるようなら、教えて下さい。

-----------
JPLAY日本語デスク

> yo さんへ

あちらに転載していただいても問題の無いように最初から書いていますからOKです。

しかし、JPLAY開発チームがせっかく音質優先のために落した機能を別途追加したのでは、本末転倒どころかMinimServerを素直に使うより音が悪くなるでしょう。

-----------
yo

> JPLAY日本語デスク さんへ

あちらに書いたのですが、「JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで、DLNA関連の情報は自力で取得し、操作性を改善したコントロールポイントを開発することは出来ないか」ということが出来ませんかね。
つまり、BubbleUPNPに外付けでタグ情報を処理するプラグインを付けるという感じです。
音楽ライブラリがどこにあるかという情報はJPLAYと同じようにユーザに指定されるという方法で取得し(これはご指摘ようにJPLAYのレジストリ情報でも取得できますね)、その情報をベースに直接内蔵ディスクなりNASからタグ情報を読み込み、適当なGUIを構築する。再生に入ったら、何もしないということは出来ると思います。

まあ、結局

> もし本当にやるつもりなら、proxyサーバー的アプローチがスマートでしょう。中身はfemtoServer、タグ情報やサーチを受付ける機能を付加します。そうすれば、どのコントロール・ポイントでもMinimServerと同じタグ情報や検索機能が実現できます。

ということになりそうで、DLNAプロトコルの開示が前提になりますので、素人には無理ですが。

-----------
JPLAY日本語デスク

> yo さんへ

少なくともJPLAY開発チームは手掛けないでしょう。

DLNAを熟知している人がボランティアでやるか、カンパを集めてアルファシステムズなどプロに開発委託でしょうね。ソフトウェア開発は1人・年で1500万円ぐらいだと思います。

-----------
yo

> JPLAY日本語デスク さんへ

ひとつだけ開発費用がほとんどかからない方法があるのですよね。

「JRMCに対応させる」です。むこうの掲示板をご覧になっている方にはお分かりのように既に動いている機能の組み合わせを変えるだけで出来るのだから。特に、一番大変なGUIの部分がそのまま使えるのは大きいです。
この方法はJRMCのビジネスからみてもメリットのあるはずで、JPLAYユーザを操作性をダシに取り込む&囲い込むことができるのだから。次期バージョンアップの目玉の一つにすれば、それなりの訴求力があるのじゃないだろうか。

むこうの掲示板でやった真相解析の寸劇の続きをやれば、JRMC親分の取り巻きの一人が「旦那、ここは思案のしどころ、我慢のしどころですぜ。そんなに怒り狂っちゃ、折角の儲け話が消えちゃいます。むこうのしまの客を取り込み、こっちのしまの客を囲い込むには、いい話ですぜ。ここは一番、昔のケンカはとっとと忘れて、J何とかに詫びを入れましょう。同じJ仲間、うるさい客どもを黙らせるには、あいつもサーバと認めてやって、ここから再生しろと教えてやれば、三方(客、JPLAY、JRMC)丸くおさまりますぜ」と説得すれば、よいのではないでしょうか。

あっちで、「JRMCフォーラムに提案してみたら」と教唆煽動してみるかなぁ。

-----------
JPLAY日本語デスク

> yo さんへ

JRiverはJPLAYの関連スレッドを当時全部消去して、JPLAYを使う場合のサポートは提供しないと明言しました。
提案されるのはご自由ですが、yoさん自身がbanされる可能性があります。

-----------
yo

> JPLAY日本語デスク さんへ

参考になる情報ありがとうございます。JRiverのフォーラムは読んでいないので、「JRiverはJPLAYの関連スレッドを当時全部消去して、JPLAYを使う場合のサポートは提供しないと明言しました」とは知りませんでした。

「あっち」と書いたのは僕の掲示板のことですが、そちらで、この情報と「JPLAYチームとしては開発することはない」という情報をベースに作戦を立てたいと思います。
一連の書き込みを引用しますが、よろしいですか。駄目なら僕のメッセージだけで対応いたします(著作権は僕にあるはずなので)。

-----------
JPLAY日本語デスク

> yo さんへ

引用は構いません。
前回も書いたように、JPLAYが提供するものはたとえテキスト・ファイルであっても中身の解析は使用許諾契約違反なので、くれぐれもよろしくお願いします。
-----------

以上です。
「JRMCに対応させる」という案は技術的、経済的には最善の案だと思っているのですが、問題はJPLAY vs JRMCの確執ですね。さて、どうしたものだろうかというところなのですが、皆様方のご意見を頂ければ幸いです。

JPLAY側のスタンスは上記やりとりで大体お分かりになるかと思います。問題はJRiver側ですね。JPLAYの新バージョンに対してどんな反応なのだろうか。

DLNAプロトコル仕様を解説したドキュメントを見つけました。
http://upnp.org/resources/documents/UPnP_AV_tutorial_July2014.pdf" target="_blank">http://upnp.org/resources/documents/UPnP_AV_tutorial_July2014.pdf
Open Connectivity Foundation(https://openconnectivity.org/" target="_blank">https://openconnectivity.org/)というサイトでDLNAというキーワードでサーチしたら出てきました。
これで見ると、JPLAYのMusicLibraryは音楽データの情報をこのフォーマットでそのまま保存しているみたいですね。特別なことはしていないように見えます。
seach機能に関しては、JRMCの言い分が正しいようですね。JPLAYは音質優先でプロトコルで規定している全てのサーチ機能をサポートしていないということでしょう。

というわけで、「あるな」と分かったので、捜したらボロボロ出てきました。

DLNA library survey
https://qiita.com/rchu207/items/a3015522b0b316c96efb" target="_blank">https://qiita.com/rchu207/items/a3015522b0b316c96efb

How a UPnP Search works
http://buildingskb.schneider-electric.com/view.php?AID=15197" target="_blank">http://buildingskb.schneider-electric.com/view.php?AID=15197

A super simple UPnP control point client for Ruby
https://github.com/sidoh/easy_upnp" target="_blank">https://github.com/sidoh/easy_upnp

最後のやつはrubyの簡単なスクリプトですが、これを使えば、femtoServerの機能と動き方をチェック出来ると思います。誰かやってみませんか。

難攻不落の秘密の要塞だと思っていたのですが、意外に穴だらけのようですね。誰かボランティアを募って攻略に臨む一手ですかね。

yo様

>従って、「全ファイルのタグ情報頂戴」と要求しに行ったのに、「これだけだよ」というつれない返事が返ってきて、
>怒り心頭、「こいつのサーチ機能はおかしいぞ、相手にしてやんねぇ」とエラーにして、以降は自身のサーバ機能を
>使っているということのようですね。

私もJRMCとJPLAYとの関係はユーモアたっぷりにyo様からご説明頂いた内容の通りと感じていました。

先に報告させて頂いた通り、JRMCはJplay Femtoレンダラーに延々とデータを送り続けます。yo様が言われる通り、5分間で100MBと言う量のデータを送っています。「何を送っているのか？」と考えた場合、Jplay Femtoレンダラーで再生中のプレイリスト（フォルダー又はアルバム）の全データを送信していると推測しています。レンダラー側では全テータの送信をJRMCに要求しておいて、必要な再生中の曲データだけを取り込み、残りの送信データは破棄している状態かなと考えています。
この状況は、JRMCとJplay Femtoレンダラーシステムの音質低下の1つの要因になっていると思います。
仮に、Jplay Femtoが扱う最小単位がフォルダー単位から曲単位となれば、Jplay Femto側から見ると余計なデータ受信が無くなる可能性が有り、少しは高音質になる様にも思います。

これ以外の対処方法として、これまたyo様と同じ様に「JRMC側にお願い」とも考えました。JRMCにしてみると「相手の首根っこを抑える」メリットは有るかもしれませんが、そうなれば「怨念」では済まなくなって「戦争」になってしまうでしょうから、実施しないと考えます。
また、今回バージョンアップしたJplay7.0はJplay Femto＋Jplay Femto Serverと言った単独機能の集合体ではなく、Jplay Femto/Jplay Femto Serverと1つのプログラムとして働いて初めてDLNA機能を発揮し、高音質化されていると認識することが、機能を理解する上で重要だと思います。

以下、余談で「怖い話」を２つ

第1話
既に結論が出て不要になったJRMCが生成したJPLAY femtoServerライブラリを削除しようと思い、JRMCのライブラリマネージャーの「削除」ボタンで削除致しました。
この時点では、左カラムのライブラリ一覧からもJPLAY femtoServerライブラリは無くなりました。
しかし、JRMCを再起動するとライブラリ一覧にJPLAY femtoServerライブラリが復活しておりました。再試行してもこの現象に変化は有りませんでした。（背筋が凍りつきました。）
そこで、JRMCのアンインストール（当然ライブラリー削除オプションを選択）、再インストールを実施しました。これで完璧と思っておりましたら「ニョキッ」とJPLAY femtoServerライブラリが現れた時には、心臓が止まりそうになり、その後「怨念」を感じました。

第2話
JRMCの再インストール前の事ですが、ライブラリ一覧を見ると「名無しのライブラリ」が有りました。JRMCのライブラリマネージャーで情報を確認すると
「""is a local library located at C:.\..（省略）\AppData\Roaming\JRiver Media Center 24\DLNA Library\uuid_JPLAY10.0.0.1femtoServer\」
と表示されていました。最後の部分の「10.0.0.1」はJplay FemtoコントロールPCの2次側のIPアドレスです。何故、1次側ではなく2次側のアドレスなの？

しばらく、この問題は放置しようと思います。「触らぬ神に祟りなし」ですから。

今は、久々にlightMPD/upnpgwを引っ張り出して来ましたら、変な所でスイッチが入りLinuxの世界にワープしております。

motomotoさん

> 今回バージョンアップしたJplay7.0はJplay Femto＋Jplay Femto Serverと言った単独機能の集合体ではなく、Jplay Femto/Jplay Femto Serverと1つのプログラムとして働いて初めてDLNA機能を発揮し、高音質化されていると認識することが、機能を理解する上で重要だと思います。

同感です。
一つ前のメッセージで紹介したDLNAプロトコル案内ドキュメントを読んでみたのですが、結局、Jplay Femto Serverというのは、Femto専用の特殊な音質優先サーバで、他のレンダラーと組み合わせることは考えていないのではと思います。
コントロールポイントと繋いだ時はフォルダービューだけのサポートなので、これに対応したコントロールポイントを使う必要があります。また、レンダラーとしてFemto以外のものが使えるかなと、MS MediaServerを試してみまたが、動きませんね。コントロールポイントとの相性以外にレンダラーもえり好みするみたいです。
このあたりは前回紹介したRubyのDLNA機能テストツールを使えば、確認できるでしょう。

しかし、いろいろググったら、この呆れたページはまだ残っているのですね。
https://jriver.com/jplay.html" target="_blank">https://jriver.com/jplay.html
関連するページも全部残っているようです。困ったものです。
ちょっと和解を提案するという雰囲気ではなさそうですね。逆に、Femto Server仕様をめぐって、「JPLAY vs JRMC 仁義なき戦い」第二幕を開演しかねないという感じです(^^;;;。

> しかし、JRMCを再起動するとライブラリ一覧にJPLAY femtoServerライブラリが復活しておりました。

JPLAY femtoServerはサーバとして認知される必要があるので、その部分はキッチリと作り込まれているということだと思います。でないと、BubbleとmConnectに認めて貰えませんから。

yo様

レスを頂きありがとうございます。

怖い話で肝心な事が抜けておりました。この数日jplayを聴いておらず、JRMCの再インストールした時も現在もjplay femto PCはネットワークからも外しダンボール箱に入れておりました。この様な状態でも「ニョキッ」とJRMCのライブラリ一覧に現れております。

motomotoさん

> 怖い話で肝心な事が抜けておりました。

femtoServerのDLNAネットワークにおける管理情報の管理の仕方は何か怪しいですね。効率化(音質アップ)のためにDLNA規約をかなり自由に拡大解釈して利用しているように感じます。いずれ、このあたりを発端にして、JPLAY vs 規約遵守連合軍で第二次「仁義なき戦い」が起きる可能性はありますね。

サイトに書いた僕の経験ですが、JPLAYインストール時のNAS登録で入力ミスをしたのですが、どうやっても入力エラーの内容を訂正出来なかったことがあります。
http://mimizukobo.sakura.ne.jp/articles/articles023.html#001" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles023.html#001
結局、OSのインストールし直しで対応しました。その時は謙虚に自分でやったチューニングが原因と思っていたのですが、今となってみると、femtoServerが「エラー内容を不死身とさせていた」可能性もありますね。全ては闇の中ですが。