Windowsアプリでのローカル管理は一台のマシンとアプリで行うので、とっつきやすく説明もしやすいメリットがあります。
音楽をPCで扱うことに慣れていない方にとって、これらのソフトやベンダー製の音楽アプリは優秀な入口です。

しかし残念ながら、Windowsローカルでの管理にはいくつかのデメリットがあります。

• PCの電源を落としたら聴けない
• ハードディスクが壊れたら即死。大量ファイルを長期管理するのにPC1台で十分と言うエンジニアはいないと思います
• 使用技術がWindows依存であったり、メタ処理の設計が欧米向けであるため簡単なカスタマイズしかできない
• ノイズ対策の障壁が高い、PC自体がうるさい。体感音質が本当に優れているかどうかは環境と耳による
• 音楽視聴に適したスペックという点で言えば、既にWindows PCよりハイエンドモデルのスマホの方が上・・・だったのですがExperiaがミッドモデルにも展開しシェアが躍進。ほとんどのスマホはWindows PCより音楽を聴くのに適しているという時代にすぐになるでしょう。ほんの数年前のネットワークプレイヤーでさえ一部スペックがExperiaを下回る場面が出てきています。それなりの付加価値がなければ、下手するとネットワークプレイヤーという機器のジャンルが死にかける可能性も

多くの場合データが大量になってきたり消えたら困ると考えた時点でNASサーバでの管理に移行します。そのときにfoobar2000やMusicBeeからNASに直接接続する方と、セットでメディアサーバを導入する方に分かれていきます。

PCはともかくスマホから使いたいだけならデータをNAS管理するだけだよね、というのは非常に良い考えです。少なくとも将来的に無駄にならない有益な作業です。

ただしブラウジングやソート、検索は、データの要件ではなくアプリケーションの要件です。あらゆる環境で同じ動きをさせたい場合には以下の2つ以外に選択肢はありません。

• サーバで一元管理してコントロールする。サーバの仕様に従うクライアントを使用する
• 全てのクライアントで同一仕様のブラウジングやソート、検索を行う

後者の方法は非現実的です。Jpsonicのようなサーバがあれば、日本語に適したブラウジングやソート、検索を様々なアプリから使用できます。

また大抵のストリーミングサーバは、元の音楽をリアルタイムで別のファイル形式に変換して送信することが可能です。好みの音質やクライアントの仕様にあわせて、フォーマットやビットレートを自動変換し聴けます。このような仕組みがない場合、プラットフォームを変えるたびに手動で変換をしたり、元の音源と別に圧縮版を二重管理したりという手間が発生します。曲の転送を都度手動で行うのは非常に面倒です。

ミュージックストリーミングサーバは、視聴の利便性と保管管理の恒久性を両立したいときに役立つ機能を提供します(これを定額有料でレンタルできるのがSpotify等のサブスクです)。

これらの似たようなサーバと比較して、Subsonicは楽曲管理が得意であると評価されることが多いです。楽曲管理はSubsonic系サーバで動画は別のサーバ、という使い分け派もよくいらっしゃいます。

• オープンソース界隈で楽曲管理に強いという評価を受けているサーバは少ないです。明らかに設計が複雑化するため
• あらゆるメディアを高度に扱える万能サーバはそもそもありません(各種別毎にプロユースの専門サーバがある世界)
• (Webでは誇張されるけど)楽曲管理サーバに比べれば動画サーバが必須というライフスタイルの方は少ない
• 日本にはDTCP-IPという特殊事情があるため、動画サーバがフル活用できるわけではない
• DTCP-IPの問題をクリアしても、汎用のハードでは耐久寿命維持費といったコスパで専用のデッキに太刀打ちできない
  (逆に楽曲管理の分野は、汎用NASでも機能性や汎用性において音楽専用NASに勝利できる)
• 動画の場合、ニーズによってはそれこそ日本向けの有料動画サービスで足りてしまうことがある

KodiやPLEXの楽曲管理が便利と感じる方はそれで問題はありません。動画をNASに大量に蓄積していく習慣がない、楽曲特化がよいという方はSonic系サーバが向いているかもしれません。

AirsonicでプレイヤーやJavaScript、CSS、HTMLの改善が行われ、Airsonicの10.4.0-RELEASEで正式にDoctypeにHTML5の宣言が追加されました。
Jpsonicではv104.0.0でHTML5対応済みです。

と思いきや。

Airsonicのコードはなかなかにレトロで、ぶっちゃけた話大昔のHTMLにDoctypeを追加しただけです。
v109.3.0以降に行われている画面修正が実質のHTML5対応になります。

Ahmed Alrasheed
2018-07-30
why not give ampache a look.
https://github.com/ampache/ampache

it supports subsonic api, has a bunch of other features, already partially translated in japanese, but do lack the active dev community.
so join in.

Webmaster
2018-08-01
I value the API compatibility and implementation compatibility of the Subsonic API.

Unfortunately, I am not very interested in communities where not providing information on the current specification at all.
Information on ampache’s external API has not been updated for years.
(Authentication is an implementation of API 1.3 or earlier, so it can not be recommended to others)

つかさ
2019-06-02
質問なのですがArtistが複数登録されている場合の挙動はどうなりますか？

MusicBeeでは表示されるアーティストとは別にアーティスト情報を持てるようで、この管理機能を使っています。
(チームAにA,B,Cとメンバーがいたときに、「チームA」を表示しつつアーティストタグには「チームA」「A」「B」「C」のタグが存在している、というような状態です。適切に登録されていれば「高坂穂乃果」や「新田恵海」で検索しても「μ’s」のアルバムが出てきます)
挙動を軽く調べたところ、MP3tagではアーティスト名のところに「チームA\\A\\B\\C」と表示され、タグを編集を開くとArtistタグのフィールドが4つ存在していました。また、表示用の「DISPLAY ARTIST」が追加されていました
Windowsのプロパティから詳細を確認するとアーティスト名は「チームA;A;B;C」となっていました

Webmaster
2019-06-02
近日中に、そのあたりの情報をまとめた記事を追加します。
現段階で簡単に御回答いたしますと「元のデータの登録方法による」ということになるかと思います。

ある項目に対して複数値の登録を行う方法は色々ありid3仕様でも定められています。
ですが、ソフトが採用している方法はまちまちです。
できるだけ多くのソフトに対応させたい場合は、Mp3tagの編集を開いたときに

ARTIST=チームA;A;B;C

と登録する方法が無難な方法です。
Mp3tagの編集を開いたときに

ARTIST=チームA
ARTIST=A
ARTIST=B
ARTIST=C

このように登録する方法もありますが、少し古い方法です。
ソフトが対応しているかどうかはそのソフトがどういった実装をしているかによります。

タグの複数読み込みに対応しないソフトは一つ目のみを読み込み他は破棄するのが普通で、Subsonic/Airsonic/Jpsonicはこの動きをすると思います。

MusicBeeはタグの複数読み込みに対応しているようですが、ご提示されている情報によると表示については結合ではなくやや独自性の強い表示用のタグを使用して解決しているようです。
DISPLAY ARTISTに相当する名称はALBUM_ARTISTに登録するのが一般的です。
(もしくはMusicBeeは現在はALBUM_ARTISTも使用できるようになっていて、昔独自に使用していたDISPLAY ARTISTが後方互換用に残されているか)

Windowsはさすがに柔軟性が高く、タグの複数読み込みをしたときに内部的に文字を結合して今風の仕様にあわせて「チームA;A;B;C」と見せていることになります。
(Mp3tagが「チームA\\A\\B\\C」と表示しているのも同じ理屈です)

Jpsonicでは、もし以下のように登録されている場合

ARTIST=高坂穂乃果;新田恵海

「高坂穂乃果」や「新田恵海」で検索した場合、曲の検索が可能です(アルバムの結果には出ません)。
ただしWeb画面上では曲の検索結果の表示項目にアルバム名が含まれるので、曲からアルバムにジャンプすることは可能です。

つかさ
2019-07-07
ここに書いていいのかわからないのですが、バグ？を見つけたので報告させていただきます。
メディアスキャン時に、以下の画像のようにNullPointerExceptionを吐いて止まってしまいます。
このとき、再スキャンをするとWEB画面上では一覧が表示されますが、外部アプリ(DSub)から一覧、検索、ランダムが見られない状態になってしまいます。(Recently addedの欄は見られます。)
この現象はjpsonic v102.0.0以降すべてのバージョンで起きています。データフォルダを削除し再構築しても同じようにエラーが出てしまいます。
また、Airsonic 10.3.1では発生しないためjpsonic固有のものかと思います。
https://pbs.twimg.com/media/D-onsfGUYAECUze.jpg

Webmaster
2019-07-08
ご報告ありがとうございます。
ご指摘の箇所は当面はAirsonicに持っていく予定のない固有処理です。

この画像だけでは固有の環境もしくはデータによる可能性が排除できないので少し厄介かもしれません。
(私の環境では発生しません。)

調査を行い必要があれば修正をします。
ただし現在のところAirsonicで少しヘビーな作業をしているので近日中にということで。

DSubは使ったことがないのでわかりませんが、今まで見聞きした情報から推測するとMusicBeeと似た作りをしているのかなと想像しています。
Music Streamerのようなものだと、このような障害が起きても検索シャッフル以外は使える可能性が高いです。

不具合報告は英語であればIssuesにしていただいても構いません。
面倒であればどこでも構わないので今回のようにこのサイトに書き込んでいただければありがたいです。
あまりに報告が多いようであればまとめて不具合報告ページを作ろうかなと思います。

つかさ
2019-07-08
返信有難うございます。よろしくおねがいします。
補足というか後出しのような情報になってしまうのですが、同現象が起きている状態ではWEBでもランダムページが真っ白、検索ができないなどの不具合が起きています。

Webmaster
2019-07-08
了解いたしました。

v104で暫定対応しました。
副次的な問題が発生する場合ご報告ください。

つかさ
2019-07-18
スキャン時のエラーを報告していた者です。
v104.0.0へのアップデートで無事に解消されました。ありがとうございます

Webmaster
2019-07-19
それはよかったです。
検証ありがとうございます。
今後似たような問題があればまたご報告ください。

Laplace
2019-10-21
恐れ入ります。
jetty 9.4.21.v20190926 を使用して、 jpsonic-105.2.0 の jpsonic-jetty-embed.war を
JpsonicをJettyコンテナで動かそうのページの手順のバージョンを読み替えて構築したところ、
(https://tesshu.com/jpsonic/how-to-run-jpsonic-on-linux)
HTTP ERROR 500が発生しました。
jettyのRequest型との非互換が出ているようです。
使用ブラウザは、Firefox 69.0.3 になります。
報告をこちらにするのが妥当かわかりませんが、報告させていただきます。
申し訳ありませんが、よろしくお願いいたします。

以下ブラウザに表示されたエラー内容を記載します。

HTTP ERROR 500 javax.servlet.ServletException: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.ClassCastException: org.airsonic.player.filter.ParameterDecodingFilter$DecodingServletRequestWrapper incompatible with org.eclipse.jetty.server.Request
URI: /jpsonic/login
STATUS: 500
MESSAGE: javax.servlet.ServletException: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.ClassCastException: org.airsonic.player.filter.ParameterDecodingFilter$DecodingServletRequestWrapper incompatible with org.eclipse.jetty.server.Request
SERVLET: dispatcherServlet
CAUSED BY: javax.servlet.ServletException: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.ClassCastException: org.airsonic.player.filter.ParameterDecodingFilter$DecodingServletRequestWrapper incompatible with org.eclipse.jetty.server.Request
CAUSED BY: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.ClassCastException: org.airsonic.player.filter.ParameterDecodingFilter$DecodingServletRequestWrapper incompatible with org.eclipse.jetty.server.Request
CAUSED BY: java.lang.ClassCastException: org.airsonic.player.filter.ParameterDecodingFilter$DecodingServletRequestWrapper incompatible with org.eclipse.jetty.server.Request
Powered by Jetty:// 9.4.21.v20190926

サーバーのjavaバージョンは以下になります。
java -version
openjdk version “1.8.0_212”
OpenJDK Runtime Environment (build 1.8.0_212-b03)
Eclipse OpenJ9 VM (build openj9-0.14.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190417_286 (JIT enabled, AOT enabled)
OpenJ9 – bad1d4d06
OMR – 4a4278e6
JCL – 5590c4f818 based on jdk8u212-b03)

Webmaster
2019-10-22 04:44
ご報告ありがとうございます。
近日中に調査します。

Laplace
2019-10-22
返信有難うございます。よろしくお願いいたします。

Webmaster
2019-10-25
調査いたしましたところ、jetty 9.4.21.v20190926 固有の不具合のようです。

https://github.com/eclipse/jetty.project/issues/4141

これは現在解消されているため、不具合バージョンを避け
以前のバージョンもしくは最新のバージョンのjettyを利用することで回避が可能なようです。
当方で前後のバージョンを確認したところ動作いたしました。

〇 9.4.20.v20190813
× 9.4.21.v20190926
〇 9.4.22.v20191022

（´-｀）.｡oO（ご報告の次の日だったようです・・・）

Laplace
2019-10-25
ご対応ありがとうございます。
9.4.22.v20191022にて動作を確認いたしました。

お、おぉ、しかし・・・
ピンポイントに不具合バージョン引くとか・・・
しかも翌日に対策版出ているとは・・・
orz…

v105.1.0 -> v105.2.0 Migration failed with PostgreSQL (embed JDBC)

修正版としてパッチを適用したv105.2.1をリリースします。

v105.2.0までのバージョンで外部DBを使用していない方は、v105.2.1へのアップグレードは必要ありません。
v105.2.1はバグフィクスのみであり、この内容はv105.2.1より後のバージョンにも含まれる予定です。
(アップグレードしても問題はありません。)

WikiのSuppressed or Removed Featuresに記載があります。

現在は公開していません。
AirsonicでDockerイメージ作成の自動化に関する試行が行われており、導入されればJpsonicも同じように公式イメージを作る可能性があります。

サーバの運用にDockerは必須ではなく、Dockerが必要かどうかは状況によります。
またDockerを使用する場合、結局のところ自分のプラットフォームに合わせ好みの機能を付加して作ることになります。
シンプルなものであればAirsonicが公開しているようなものになりますが、Let’s Encryptや外部DB、ListenBrainzなどと組み合わせることもできます。

自環境にベストとなるようアレンジして公開してくれる方がいらっしゃるので、好みに近いものを探したり組み合わせて作成するのが良いと思います。
よいものができたら公開してください。

Googleさんで検索
docker hubで検索

Dockerのスクリプトの安全性についてはご自身でご確認ください。

つかさ
2020-05-24 21:30
109.0.0にアップデートしたところ、起動オプションで「-Dserver.context-path=/subsonic」を指定しているのですがこれが適用されなくなってしまいました
localhost:8080/subsonicにアクセスするとlocalhost:8080/loginにリダイレクトされるような挙動をします(今までのバージョンでは/subsonic/loginとなっていました)

また、この問題が起きたため108.0.0に戻したところadminアカウントが管理者から一般アカウントに変更されてしまい、ほとんどの設定にアクセスできなくなってしまいました
(これが109.0.0にアップデートした際に起こったのか、108.0.0に戻した際に起こったのかは確認できていないので不明です)

申し訳ありませんが調査と対処のほうお願いできないでしょうか。よろしくお願いいたします。

Webmaster
2020-05-28 02:22
了解いたしました。近日中に対応します。
ご返答遅くなり申し訳ありません。
wordpressが謎のスパム判定を行っていた模様・・。

取り急ぎ、109.0.0から-Dserver.context-pathはservlet.contextPathに変更になっています。
(アナウンス不足でした。)
書き換えのみで動くので109.0.0で試してみていただければ幸いです。

重要なお知らせに記載しました。

つかさ
2020-05-29 18:15
返信ありがとうございます。
「-Dservlet.contextPath=/subsonic」に変更して起動してみたのですがやはり同様にリダイレクトされるような挙動をします。
また、画面に表示されるログを追ってみたところ
「LOGBACK: No context given for c.q.l.core.rolling.SizeAndTimeBasedRollingPolicy@xxxxxxxxxx」(xxは起動するたびに変わる数字列)
というような表示を見つけました。何かしらの参考になれば幸いです。
よろしくお願いいたします。

Webmaster
2020-05-31 22:19
むむ。そのようなログを見たことがないのですが、キャッシュが悪さをしているという可能性はないでしょうか。
(tomcatの場合webappsのjpsonicディレクトリを削除する等..)

つかさ
2020-06-01 12:13
ディレクトリまるまる消して試してみましたが状況変わらずですね…

Webmaster
2020-06-18 09:25
LOGBACKのログに関しては、起動時に不要な通知が出るという不具合がSpringで報告されているようです。これについては追跡し今後対応が必要になれば改善していこうと思います!

Orumin
2020-06-25 02:03
私も同様の状況に遭遇し，-Dservlet.contextPath=/jpsonic を追加しても期待通りの動作をしませんでしたが，-Dserver.servlet.contextPath=/jpsonic と変更したところ期待した動作をしました。

つかさ
2020-06-28 00:00
全く別の環境でも試してみましたが、やはりリダイレクトされてちゃんと表示されない状況が続いています。(109.1.0にアップデートしても同様でした)
上にOruminさんが書いてくれたように-Dserver.servlet.contextPathとしても同様の動作をしました。
不思議なのは/jpsonicと指定した場合に、localhost:8080/subsonicにアクセスしても同じようにリダイレクトされることです(ステータスコードは302でリダイレクトされていました)

以下に詳しく環境を書かせていただきます。よろしくおねがいします。
OS:Windows 10 Pro 2004 、Windows Server 2016 Enterprise 1607
java:openjdk version “11” 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

つかさ
2020-06-28 01:02
すいません解決しました。起動オプションの位置が悪かったようです。-Dserver.servlet.contextPath=/subsonicで動きました。
-jarの前に入れなければいけないんですね、ずっと末尾で動いていたので確認していませんでした。お騒がせしました。

Webmaster
2020-06-30 08:36
よかったです・・・ナルホド。
私の出しているサンプルが雑すぎるのかもしれません。
Javaオプションは順序でたまに混乱しますが、-jarは大体末尾にきます!

沢田
2020-08-31 03:50
連携して使用している者です。
MusicBee側でローカルメディアのオートプレイリストを作成すると、jpsonic側に同名+.xautopfの空プレイリストが生成されるのですが、これは仕様でしょうか？

Webmaster
2020-08-31 21:03
MusicBeeの仕様のようです。
https://musicbee.fandom.com/wiki/Playlists#Playlist_Folders

Jpsonicのプレイリストはデータベース内でユーザアカウント毎に管理されています。

沢田
2020-09-07 03:20
仕様でしたか…。
プラグイン側でいじれないか探ってみます。ありがとうございます。

飯田

初めまして
いまはSynologyのNASでSubsonicを使ってます。
可能性としてNAS向けって・・・・ありませんか？

webmaster
ありがとうございます。

私自身がさまざまな製品でテスト可能なわけではないので特定の製品向けというのは考えていないのですが、AirsonicではDockerの自動ビルドが検討されています。
それが実現した場合、Jpsonicでも公式のDockerイメージを作成すると思います。
(Synologyの場合Dockerであれば使いやすい・・・模様?)

既にSubsonicが動いているということなので動かすことが可能なはずですが、環境が手元にないため具体的な手順まではわかりません。。。
すみません。

NAS向けへの配備というのは、個人的には割とマジメに考えている命題です。
設定ファイル書いてコンパイルすればDockerで動かすことは可能でしょう。
ただサーバサイドやインフラに詳しい人であれば「Dockerってそれだけじゃないよね」と考えると思います。

NASで快適に使用するには処理の高速化も施した後であれば万々歳かな、と考えています。これはNASに限らず全プラットフォームに対して恩恵があるためいずれ行います。極端な話、速度が半分のマシンでも、アプリの処理速度を倍にする対策を施した後に突っ込めば帳消しにできます。

現状は遅いマシン環境ではスキャンする曲数をいくつかに分割し段階的に増やすという作戦があります。
(スキャンに時間がかかるのは初回取り込みなので)

Ryo Fujii
2021-06-19 15:32
いつも便利に使わさせていただいております。
ありがとうございます。

つい先日までは動作していた Rest API の getNowPlayin について、曲名が空白で返されるようになってしまいました。
抑制された又はなにか設定に原因があるのでしょうか？

curl “http://192.168.1.xxx:8080/rest/getNowPlaying?u=admin&p=xxxx&v=1.15.0&c=myapp&f=json”
{
“subsonic-response” : {
“status” : “ok”,
“version” : “1.15.0”,
“nowPlaying” : {
}
}
}

返信
Webmaster
2021-06-19 17:12
了解いたしました。
近日中に調査とテスト追加を行い、必要であれば修正バージョンをリリースしようと思います。
ご報告ありがとうございます!

返信
Webmaster
2021-06-29 22:50
調査、修正いたしました。

> 抑制された又はなにか設定に原因があるのでしょうか？

確かに設定により回避は可能なのですが、おっしゃる通り「抑制された機能」のひとつを追加する際に設定画面が改悪されたことが原因です。

曲の演奏やブラウジングといった最上位の機能にかかわる不具合ではないため、修正版はリリースしないものとします。ただし修正とテストケースを含んだSNAPSHOT版は既にマスターマージされており、ダウンロードが可能です。

[背景] getNowPlayingは、検索やリスニングなどの基本機能とは密接に関連しておらず、ほとんどのクライアントアプリはこれを使用していません。(サーバではクライアントの演奏状態監視、特に終了検知が不可能です。そのためNowPlayingというほどリアルタイムでステータスを正確に表すものではなくminutesAgoは16h agoになったりします。) RESTでgetNowPlayingを使用する動機は、サーバ稼働中に音楽を再生したユーザーの一覧表示のようなものに限定されます。音楽を再生しているユーザーのリストは、Jpsonicが積極的な使用を推奨していない機能です。削除はしていませんが、管理者とユーザがそれぞれ意図的に有効にする必要があります。

[経緯]

(1) v109.3.0 において「個人設定 > 追加の表示機能 > 自分が再生中の曲を他のユーザに通知」 のデフォルト値をtrueからfalseに変更。もともと個人設定のこの設定項目によりgetNowPlayingはON/OFFが可能です。AirsonicやSubsonicはデフォルトで有効。Jpsonicではv109.3.0からデフォルトで無効に仕様変更しました(Subsonicとは逆で「他のユーザが何を聴いているか分からない」というケースを基本と考えているため)。これ自体は問題がないかと思います。
(2) v109.4.0において「サーバの基本設定 > 抑制されているレガシー機能 -> 演奏中の曲リストを使用する 」という項目を追加。Webツールの「音楽を再生しているユーザーのリスト」をデフォルトで非表示にするための措置。これもないかと思います。
(3) v109.4.0の変更で、「個人設定 > 追加の表示機能 > 自分が再生中の曲を他のユーザに通知」の設定項目も同時にデフォルトで非表示に変更された。これが問題です。

また個人設定で設定変更をした際、「抑制されているレガシー機能 -> 演奏中の曲リストを使用する」がfalseの場合、「自分が再生中の曲を他のユーザに通知」の値はfalseに変更されます。
よってRyoさんのご指摘のように、v109.4.0以降において、ユーザから見ると「何もしていないのにgetNowPlayingが使えなくなった」という現象が発生します。

[対応] ・v110.1.0において「抑制されているレガシー機能」の設定に関わらず個人設定で「自分が再生中の曲を他のユーザに通知 」をオンオフできるように再度変更します。

返信
Ryo Fujii
2021-07-02 09:40
お忙しいところ調査・修正いただきありがとうございました。
詳細な調査内容までいただき、とてもよく理解できました。

今後も我が家のメイン音楽管理ツールとして愛用させていただきたいと思います 🙂

返信
Webmaster
2021-07-04 15:33
こちらこそ。また何か問題がございましたらご報告ください。

Hiroyoshi Aoki
2021-07-20 00:01
平素お世話になります。jpsonic 110.0.0 Rasberry pi 4にインストールしました。

ブラウザでの管理画面を表示した後、ミュージックフォルダをスキャンすると、以下のメッセージが表示されます。

java.lang.NullPointerException: null
at org.jaudiotagger.tag.mp4.field.Mp4GenreField.build(Mp4GenreField.java:111) ~[jaudiotagger-2.2.6-SNAPSHOT.jar!/:na] …

ミュージックサーバは初めてで、あまり詳しくなく恐縮ですが、原因についてアドバイスを頂ければ幸いです。

返信
Webmaster
2021-07-22 15:40
こんにちは。
さすがに情報が少ないのですが、ファイルが破損しているのでなければ、登録されているタグの内容が不正な可能性があるように思われます。たとえばタグの仕様上数値が入力されるべきフィールドに、仕様外の形式のデータや値が登録されている、など。タグ編集ソフト等を利用して内容をご確認ください。

タグ編集ソフトは機能特性上、誤ったデータも読み込んだり、またソフトによっては誤ったまま素直に書き込む機能を有していることがあります(「自分の手持ちのソフトで読めるので」「ファイルは正しい」かというとそうでない場合も多々ございます)。この仕様はソフト毎に異なりバリエーションが非常に多く複数のソフトを経た場合複雑化します。申し訳ありませんがファイル個別の問題にお答えすることは難しいです。
(Jpsonicが解析に使用しているライブラリがもう少し丁寧なログを吐いてくれると楽ですが、残念ながら全てのケースでそうなっているわけではないようです。またそれが根本の問題かといえばそういうわけではありません)

もし同時に大量のファイルをスキャンしているのであれば小分けにして試してみて、全てのファイルで発生するのか特定のファイルで発生するのか切り分けをするとよいかもしれません。問題を絞り込む負担が小さくなるかもしれません。

Jpsonicへのインプットへの入り口はJAudiotaggerというライブラリになるので、何か問題があればログにこれに関するエラーが出る場合がほとんどです。傾向としては読み込ませようとしているファイル側に問題がある可能性の方が高めと考えてください(もちろん反証PRは歓迎です)。

正確に把握しようとすれば

• 「どこのヘッダのどこのフィールドのことですか?」
• 「どのソフトのどのバージョンでそのファイルを作りましたか?」
• 神対応する場合は「サンプル提出できますか?」

私に限らずこのようなやりとりが必要になりますが、外部のバグ調査に似た作業になる可能性が高くなります。ここに時間を消費するのは本意ではありません。

リッピング/タグ付けのようにやり直しコストが高い作業を不確かなソフトに委ねると、数年後に問題が発覚したときにリカバリが困難、あるいは膨大な修正作業が必要になる場合があります。

ですが、あらかじめこのようなリスクを抑えることは可能です。どちらかといえばリカバリする方法よりも「重要なファイルを書き出すソフトをどのように選ぶべきか」を知っておくと楽です。

前工程で結果的にひどいデータができたとして、それを後ろのソフトのせいにするのは勘違い、というのはエンジニアっぽい考え方です。そうでなければトラブルの切り分けや対応はできません。とはいえ不親切っぽく見えてしまうので「最初からちゃんとリッピング/タグ付けすると一生涯幸せ」という話題に全力ですり替えようと思います。

リッピング/タグ付けでは色々なソフトウェアが使われますが、それら全てのソフトが正しく動作するという保証はありません。ですので、リスクを避けるにはこの工程で優良なソフトのみを使用すればよいだけです。
優良ソフトの第一候補はMusic Centerです。CDリッピングとタグ付けに関してはSONY発のソフトという時点でスペシャルです。機能レビューをするまでもなくSONY発のソフトとそれ以外のソフトというのがまず最初のグルーピングになります。

同ブランドでデバイスや楽曲ファイルを販売し、何十年も楽曲データを整備している企業の提供するガチ日本語対応プロダクトと、個人が作成した同種の無保証ソフトを同格に語るのは無理があります。

本物のCDDBを使う

データの整合性を重視するのでGracenoteしか使ったことがない、という方も多いかと思います。料金体系が変わったときに使えなくなったソフトも多いですが、Music CenterはGracenoteを使用可能です。

(現在は一定のダウンロード数があるクライアント毎に開発元が料金を収める方式。とはいえボーダーはかなり低いので正規契約するのかしないのか、事実上の踏み絵になっている。一次顧客は必然的に名の知れたデバイスベンダーなりコンテンツホルダーである有力企業で、それらの企業から提供されるプロダクト経由でユーザはデータを無料利用できるという図式。ちょっと違うけどJASRAC -> Googleさん -> 一般ユーザのような階層関係)

本体の実装に加えCCDBのデータ品質もトラブルの原因になりうる点に注意してください。CCDBのデータが壊れていればローカルのファイルにも悪影響が出る場合があるということです。OSSのCDDB(もどき)もありますが、20年かけてもプロプライエタリとそれに追随する企業から一定の主導権を奪えていない点を見ると互換品を作るのは厳しいでしょう。日本語圏データはなおさらハードルが高めです。CCDBを利用するソフトウェアはPC、車、スマホ等、様々なプラットフォームに存在します。それらと共通のデータを取り扱いたい場合、Windows上のリッピングでも正規のGracenoteのDLLを使用しているソフトウェアを採用するのが妥当です。

マスターデータのフォーマットに多様性は不要

あれこれ悩まずFLACに自動でタグをつければよいです。

Music CenterはUXしか言わない人からヘイトスピーチを受けやすいソフトですが、本来は複雑なはずのリッピングやタグ設定に関しては破格のシンプルUXです。どのプロダクトでもこれができるというわけではありません。バックボーンが弱いソフトウェアから順に設定項目が増え、逆説的にそれをウリにするしかなくなります。一般的にヒト一人が生涯のうち使用すべき音楽のフォーマットはメジャーな数パターンで事足りるはずです。

色々なフォーマットの特性や規格に習熟して様々なソフトを渡り歩けるようになるというのも一つの方法なのですが、おそらく大半の方にとって非効率な行為です。フォーマットについてお勉強する時間が余分にかかりますし、書き出しに使用するソフトを安易に増やせば不具合に引っかかるリスクは相対的に上がります(心中覚悟ならOKですが)。Web上では色々なソフトの比較記事がありますが、プロによる動作確認済みソフトウェアのリストではないことに注意してください。Googleさんでよく見かけるリッピングソフトであれば安心かというと、特に因果関係はありません。

結局は市場に多く流通したフォーマットが生き残ります。ミュージックフォルダを長期的に安定運用していくには、数十年スパンでのサポートが見込める企業のソフトウェアを使って全フォーマット統一しておくのが安全です。あるいは数多あるフォーマットの中央値は、画期的な技術革新がない限り長期的にはその付近に集約されます。そのようなフォーマットであれば、PCのみならずスマホやカーオーディオ、あるいは今後出てくる未知のデバイスでも大抵使用可能です。また仮に大きなフォーマット革命が起きた場合であっても、変革期には安全なコンバート手段が提供されることが期待できます。

そういったことを念頭に大規模なエコシステムを作り上げてきたリーディングカンパニーのプロダクトは、客観的に見て信頼性が高いと評価できます。体制を築くために巨額の資金投入を行い、一番早く一番多くの壁にぶつかり解決をしてきた実績があるためです。リッピングソフトやCDDB以前にそもそもSONYがCDを作ったことを考慮すると、創成期から現代まで関連製品やコンテンツ流通網を全てカバーしている稀有な企業です。その企業がこれからはハイレゾだというのであればなおさら、これからもマスターデータに最適なフォーマットはFLACということになります。また、CDから市場のデファクトスタンダードである楽曲フォーマットのファイルを生成するソフトウェアを放棄する可能性は、SONYの場合は他企業よりも低く今後も安定供給されるのではないかという仮定もできます。

先人が築いたレールを嫌い、盗んだバイクで走りだしたい若者もいるでしょう。それでも良いのですが、トラブったときのために王道を明確化しておくとよいです。自己責任において冒険して問題があれば、自己判断で王道に戻ればよいです。

選択肢がたくさんありそうで、そうでもありません

無難なソフトウェアはMusic Centerだけというわけではありませんが、中高生でも使えるくらい誰にでも分かりやすく、入手しやすく、低リスクで日本語が壊れないという条件で候補を上げるとすればMusic Centerは頭一つか二つ抜けます。ちなみにMusic Centerは予備知識やトラブル解決経験の少ない方が最初に使うリッピングソフトとして、総合的に必要十分な機能を備えつつ敷居が低いですよ、匹敵するソフトは他にあまりありませんよ、というお話です。リッピング以外の機能に関してはまた別の意見がございましょう。長くなるので、ここでは最も替えのききにくい機能について話しています。

スキャン時には、JAudiotaggerとFFMpegを利用してタグ解析が行われます。動画はFFMpeg:ffproveが利用されています(実装時にはそれがベストチョイスだったのでしょう)。JAudiotaggerのドキュメントにある通り、一般的なタグ形式は網羅されています。

JAudiotaggerは歴史が長くJavaでは有名なライブラリであり、現在もメンテナンスが続けられています。Mavenでの最終リリースは2.0.3ですが、Jpsonicで使用されているのは2.2.6-SNAPSHOT(2020/1時点のもの)です。バージョンではなく期間で言えば9年と10か月、約10年の世代差があります(Mavenから引っ張る方は御注意を)。Airsonicでは2.2.5が採用されていますが、Jpsonicはそれよりも新しいライブラリが使用されています。これは新しいJVMに適応していくための必須措置です。JAudiotaggerではGraalVMへの対応も検討に上がっておりソースコードのメンテナンスに精力的です。そのため今後さらに新しい修正を取り込むことはありますがロールバックすることはありません。

Jpsonicでは完全にJAudiotaggerへ丸投げというわけでなく、日本の商圏に合わせSONYのFLACとAppleのMP3のタグについて追加検証が行われています。itunesのMP3は20年近く前のバージョンまでカバーします。FLACはMusic Center最新のみの検証ですが、非公式参考として私のライブラリ自体はSONYのソフト数代を経ておりノートラブルです(ずっとSONY使っている方は4代目?)。この範囲に加えAirsonicでテスト用に用意されていたファイルも含めてデグレードは一度もありません。この体制で大半のまともなファイルはカバー可能と考えており、ここから外れた部分に関してはJAudiotaggerの仕様が尊重されます。

さすがにこれらから漏れた範囲のデータ形式においてはイレギュラーデータの可能性が高くなります。そのためユーザの手持ちのファイルで読み込めないものがあっても関与しない方針です。もし問題があれば、まずご自身の使用されているファイルが広く受け入れられているフォーマットであるかどうかを御確認ください。

• 有力なコンテンツホルダーやデバイスベンダーの使用しているフォーマットがまず参考になります
• それらに追随しようとしているプロダクトが2次的な対応を行なうでしょう。もちろん皆がよく使うフォーマットはサポートされていくはずであり、時代にあわせたものが採用されていくはずです。非技術者のブログよりも合理的で確度が高い合意形成がなされ、それを元にソリューションが提供されていると想定できます。戦いたい方は場外乱闘せずこのような土俵に乗ってください。きっと世の中の役に立つでしょう
• 長期的には、腐ったミカンが排除されることも考えられます。これは後方互換を軽んじるという意味ではありません。単純な「古さ」ではなく、かつて不当なフォーマットが流通していた時代もあり、現在それらをどのように扱うかはプロダクトによります。ソフトウェアによっては不当なフォーマットや壊れているファイルは弾かれる可能性があります。入力を扱うライブラリはなんでも読み込むのが優秀なわけではなく、早期に拒絶するのも仕事のうちです。プログラムの設計ではフェイルファストといった言葉で表現されます。
• 一方腐ったミカンをサポートするプロダクトもあるでしょう。どちらが優れているかではなく、用途によります(次代に合わせた編集/修正/コンバートの為読み込むのか、高速化や省メモリのため現代ではイレギュラーとなった仕様は省くのか、等々)。特定のソフトで腐ったミカンが読めたからといって、腐ったミカンが必ずしも支持されているというわけではないことに注意してください。タグ編集をできるソフトにはこの辺りの説明は何もないとは思いますが、ユーザが修正できるようになっている場合や、ただ単にソフトが腐っている場合があります。
• 本分に注力するため、インプットはごく一般的なソフトの出力を基準に置いているということをご了承ください。仕様のバージョンや規格云々以上に、世間一般のストライクゾーン、つまり実質的な相互互換性が重視される分野であるためです。一見SONYにロックインしているように見えますが逆です。出力仕様はフツーの範疇なため、適切なソフトであれば同様のファイルも作成可能です。もし出所不明のファイルが読めないのであれば、ロックインを視野に入れタグの状況を調べてください。面倒な場合、少なくとも書き出しの行程においては一定以上の品質が担保できるソフトウェアを使用するというのも一つの方法です。

沢田
2021-10-04 06:26
お世話になっております。

久々にUpdateをかけたところ、どうやらいつのまにかライブラリの自動更新が止まってしまっているようです。
110.1.1ではJava11/17版どちらも自動更新されず。
110.1.0版ではJava17版でのみ確認しましたが、やはり自動更新されず。
過去のVersionは上書きしてしまっており、jarファイルも公開されていないようですので試せておりません。
環境はWindows10Proです。
なにかこの間に設定の変更などありましたか…？

返信
Webmaster
2021-10-08 01:59
> なにかこの間に設定の変更などありましたか…？

ここ最近はバックグラウンドのデータに大きな影響がある更新はなかったように思います(直近v109.5.0)。
データの更新についても、データベースのメジャーバージョンが異なるv108.xからも自動コンバートは可能です。

もしログ等で上書きする前のバージョンが御確認可能であれば、こちらで以前のバージョンを再ダウンロード可能にいたします。
(常時セキュリティ更新を含むため基本的に古いものを残していません。ローカルコンパイルも可能ですが遡ってのコンパイルは大抵の場合検証のスキップが必要になります。)
もしエラーログ等ございましたら、ご指摘の問題が再現性のある問題なのかどうか追加検証するのに有益な情報となります!

返信
沢田
2021-10-14 05:30
お返事ありがとうございます。
以前使っていたバージョンなのですが、なにぶん手動スキャンすることも多く
“私が使い始めた2020年８月ごろは動いていた”というおぼろげな記憶しかございません。

そして実はエラーが出ておらず、”Automatic media library scanning scheduled～”で指定した日時は表示されるものの、
その時間になっても動き出さない…というタイプのものでございます。

手詰まり感が強いのですが、昨年夏ごろのjarファイルで検証させて頂いてもよろしいでしょうか…？

返信
Webmaster
2021-10-14 08:24
了解いたしました。

> 自動更新が止まってしまっているようです。

データ移行中に止まったというような問題ではなく、スキャンの定時実行がおかしいというお話と理解しました。

フレームワークの更新に伴い、スキャンのスケジューラ実装は以前に変更されています。
動作確認はそのときに行った為、フレームワーク側が仕様変更されていなければ動きは変わらなそうですが、確信は全くありません。
(自動実行のテストは行っていないため)

自動実行のスケジューリングはもともとの仕様の複雑さもあります。
起動時から起算して24時間経過後の指定された時間から24時間毎とかそんなかんじだったので、確認時は大体2日位日付をずらす必要があったりします。
これにフレームワークのスケジュールの設定の仕様が加わるため、今どうなっているか(例えば指定時間とずれて実行されないか等)はソースを見ながら動作確認が必要で、即答できなかったりします。

少しややこしい問題であるため、近日中にこちらで確認してご報告いたします。

返信
沢田
2021-10-18 02:38
お世話になっております。
結論から言うと、問題なくスキャンは動きました。
いくつかこちらの環境でも実験しましたが、よくわからない挙動でした。

こちらの不手際でサーバー再起動が週１から毎日に変わってしまっており、それで予定時間は記載されるもののスキャンがされないと勘違いしてしまっていたようです。
大変申し訳ございません。

>2021-10-15 19:14:41.740 INFO — .t.j.s.MediaScannerScheduleConfiguration : Automatic media library scanning scheduled to run every 1 day(s), starting at Sat Oct 16 08:00:00 JST 2021
(サーバー起動時・16日はログ無し)
>2021-10-17 08:00:02.373 INFO — .t.j.s.MediaScannerScheduleConfiguration : Automatic media library scanning scheduled to run every 1 day(s), starting at Mon Oct 18 08:00:00 JST 2021
>2021-10-17 08:00:02.420 INFO — c.t.j.s.MediaScannerService : Starting to scan media library.
以下正常の挙動でした。

又、別件ではあるのですがプレイリストのm3uファイルを取り込んだ際
頭行に拡張m3u用のタグ”#EXTM3U”が入っていると、その後の取り込みには問題ないもののログにエラーが吐かれます。
こちらは仕様ということでしょうか。

返信
Webmaster
2021-10-21 09:33
大変遅くなりました。
スキャンについてはいずれにせよ元々良いコードではなかったため、再実装してテストを追加しました。全く問題ありません。

https://github.com/tesshucom/jpsonic/issues/1208

Subsonic/Airsonicの自動スキャンの設計は好ましいものではなかったため、Jpsonicでは処理を書き直しています。その際多少仕様が簡略化されており、画面上でスケジュール変更をしても即座に反映されません。次回実行時の決定は、「起動時」以降「自動スキャン実行時」に都度再計算してループする仕組みになっています(あまり頻繁に変更する項目でないためシンプルにしている)。このあたりもわかりにくい点のひとつだと思いますので、次回リリース時にはちょこっとヘルプを足そうと思います。

Extended M3Uに関してはあまり見ておりませんが、Airsonicのオーナーが作成したライブラリ内のお話のようです。コードの日付が2008となっているのでEXTM3Uはおそらく考慮されていなかったのではと思われます。
ご指摘の箇所について確認してみます。抑制が可能であれば抑制します。

返信
Webmaster
2021-10-22 22:11
EXTM3Uの件については再現しないようです。ログやインポートファイル等ございますでしょうか?

返信
沢田
2021-10-23 12:20
素早いご確認＆変更ありがとうございます。

こちらのエラーも、なる時とならない時があるようです。(恐らくプレイリストに更新のない場合読みにすらいっていない？)
ログの該当部分のみですが貼っておきます。
アクセスできん！って吐いてるだけなので大きな影響はないかと思うのですが、もしかすると存在しないファイルパスを指定した場合すべてこうなるのでしょうか…？

2021-10-20 02:03:34.224 INFO — c.t.j.service.PlaylistService : Auto-imported playlist D:\Drive\Playlist\Playlist1.M3U
2021-10-20 02:03:34.372 ERROR — c.t.j.s.p.DefaultPlaylistImportHandler : Unauthorized access to media files :

java.lang.SecurityException: Access denied to file D:\Program Files\jpsonic\#EXTM3U
at com.tesshu.jpsonic.service.MediaFileService.getMediaFile(MediaFileService.java:130) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.MediaFileService.getMediaFile(MediaFileService.java:107) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.playlist.DefaultPlaylistImportHandler$1.beginVisitMedia(DefaultPlaylistImportHandler.java:106) ~[classes!/:110.1.1-RELEASE] at chameleon.playlist.Media.acceptDown(Media.java:123) ~[core-1.2.1-RELEASE.jar!/:na] at chameleon.playlist.AbstractTimeContainer.acceptDown(AbstractTimeContainer.java:141) ~[core-1.2.1-RELEASE.jar!/:na] at chameleon.playlist.Sequence.acceptDown(Sequence.java:39) ~[core-1.2.1-RELEASE.jar!/:na] at chameleon.playlist.Playlist.acceptDown(Playlist.java:293) ~[core-1.2.1-RELEASE.jar!/:na] at com.tesshu.jpsonic.service.playlist.DefaultPlaylistImportHandler.handle(DefaultPlaylistImportHandler.java:70) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.PlaylistService.importPlaylist(PlaylistService.java:206) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.PlaylistService.importPlaylistIfUpdated(PlaylistService.java:323) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.PlaylistService.doImportPlaylists(PlaylistService.java:296) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.PlaylistService.importPlaylists(PlaylistService.java:275) ~[classes!/:110.1.1-RELEASE] at com.tesshu.jpsonic.service.MediaScannerService.doScanLibrary(MediaScannerService.java:235) ~[classes!/:110.1.1-RELEASE] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[na:na] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[na:na] at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na]

返信
Webmaster
2021-10-24 15:16
> もしかすると存在しないファイルパスを指定した場合すべてこうなるのでしょうか…？

そのようです。またURI書式が誤っている場合にもこのエラーを出すようになっているようです(パス区切りがスラッシュでなく\になっているなど)。

演奏している曲をプレイキューのメニューから「プレイリストで保存」をし、プレイリストのページからエクスポートできます。そのファイルはおそらく読めるので、そのファイルを開いてみて書式を確認すると良いかもしれません。

Takumiboo
2021-12-29 03:35
初めまして。Airsonicからの乗り換えを検討しています。
Airsonicと同じデータフォルダを読み込ませているのですが、英数字以外で始まるアーティスト名のフォルダにあるファイルが読み込めていないようです。
内部詳細ではロケールの部分に
Javaのデフォルト文字セットがUTF-8をサポートしていないようです。国際文字は部分的にサポートされる場合があります
JavaのファイルエンコーディングがUTF-8をサポートしていないようです。国際文字は部分的にサポートされる場合があります
と表示されています。
こちらは何か対処方法がありますでしょうか？

Java: 17.0.1, OS: Windows 10

返信
Webmaster
2021-12-29 18:46
> 内部詳細のロケールの部分

これはAirsonicで機能レビュー時から存在する既知の不具合です(特にアナウンスされていませんが)。
ほとんどの場合無視して問題はありません。またLinuxでは発生しません。
気が向けば修正する可能性がありますが、致命的でもないので即修正する予定はありません。

> 英数字以外で始まるアーティスト名のフォルダにあるファイルが読み込めていない

これはご提示されている情報だけでは状況が掴めないかもしれません。

> Airsonicと同じデータフォルダを読み込ませている

JpsonicはAirsonicのソースを利用してはいますが、Airsonicのデータフォルダに対する後方互換性、直接的な移行については特に保証していません。
データフォルダを新たに空の状態から試すのが無難かもしれません。

返信
Takumiboo
2021-12-30 02:33
返信ありがとうございます。

データフォルダについて誤解を招く表現でしたが、AirsonicのDBなどを読み込ませているということではなく、同じ音楽ライブラリフォルダ、という意味です。

また今気が付きましたが、
データベースにアクセス不能なミュージックフォルダに格納されているファイルが存在します
メディアファイルデータベースにパスが不正なメディアファイルが含まれています
アクセス不能なメディアファイル数 2
パスが不正なメディアファイル数 2533
というアラートも出ています。おそらくこれらが表示されていない英数字以外で始まるフォルダとその中の楽曲かと思われます。

改めてAirsonicの同じ画面を見てみるとたしかにこちらでもロケールのエラーが出ていました。なのでこちらは関係がないのかもしれないですね。

返信
Webmaster
2021-12-30 20:49
了解いたしました。

私なら以下のような手順で確認を行うと思います。

・何かエラーが記録されていないかログを確認
・Music Center for PCで作成したファイルのみを用意しローカルマシンで正常にスキャンできるか確認。CDからリッピングするのが手っ取り早いですが、ライブラリがミュージックフォルダと分類の方法にあるようなディレクトリで構成されている場合、CDからでなくてもタグを付与できます。たとえばYoutubeからダウンロードしてきたようなファイルでも、ディレクトリ構成を一致させればCDDBから取得したデータをファイルに付与することが可能です(アルバムを右クリックして「アルバムとして検索」を選択するとGracenoteのデータとの比較ダイアログが開きます)。
・もしMusic Centerのデータの読み込みに問題がなければ、Jpsonicは正常に動作しています
・Jpsonicが正常に動作しているのに読めないファイルがある場合、そのファイルに問題があると疑いをかけます。テスト用にいくつか既存のファイルをコピーし、タグを削除したあとMusic Centerでタグを再付与します。それが読めたとしたら黒です

JpsonicはAirsonicを元に作成されているのですが、対象としているJavaのバージョンや使用されているライブラリは世代の新しいもの、ほぼ最新へ刷新されています。
Subsonic APIの互換性には配慮しますが、Airsonicに対して全機能の後方互換は保証していません。Jpsonicの仕様は、Jpsonicの仕様です。

タグバーサについては特に各プロダクトの非互換や不具合がとても多い部分です。
粗悪なデータも含め対象範囲(使用しているソフトや、そのバージョン≒いつぐらいにそのファイルを作成したか)を定めずに読めないインプット系トラブルの調査を行うことは悪魔の証明です。
そのため、Jpsonicでは「Music Centerの出力が正解」という仕様にしています。ご了承ください。

もちろんそれ以外のソフトも使用可能ですが、多くのオープンソフトウェアのライセンスには「無保証」と書いてあるはずです。
そのソフトウェアがMusic centerと互換性を持つタグを扱えて、バグがないことが前提になります。

返信
Takumiboo
2022-01-01 02:57
メディアスキャン時にエラーが出ていたようです。

2021-12-29 03:04:19.717 ERROR — scan-task-pool-1 : An error occurred in the pooling thread.

java.lang.UnsupportedOperationException: Not available for this field DISC_NO
at org.jaudiotagger.audio.generic.GenericTag.getValue(GenericTag.java:198) ~[jaudiotagger-2.2.6-SNAPSHOT.jar!/:na] at org.jaudiotagger.tag.wav.WavTag.getValue(WavTag.java:311) ~[jaudiotagger-2.2.6-SNAPSHOT.jar!/:na] at org.jaudiotagger.tag.wav.WavTag.getFirst(WavTag.java:316) ~[jaudiotagger-2.2.6-SNAPSHOT.jar!/:na] at com.tesshu.jpsonic.service.metadata.JaudiotaggerParser.getTagField(JaudiotaggerParser.java:161) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.metadata.JaudiotaggerParser.getRawMetaData(JaudiotaggerParser.java:111) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.metadata.MetaDataParser.getMetaData(MetaDataParser.java:50) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaFileService.applyFile(MediaFileService.java:634) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaFileService.createMediaFile(MediaFileService.java:624) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaFileService.updateChildren(MediaFileService.java:519) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaFileService.getChildrenOf(MediaFileService.java:263) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaScannerService.scanFile(MediaScannerService.java:280) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaScannerService.scanFile(MediaScannerService.java:284) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaScannerService.scanFile(MediaScannerService.java:284) ~[classes!/:111.0.0-RELEASE] at com.tesshu.jpsonic.service.MediaScannerService.doScanLibrary(MediaScannerService.java:189) ~[classes!/:111.0.0-RELEASE] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[na:na] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[na:na] at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na]

楽曲をiTunesで管理しているのでMusic Centerでの動作確認にはちょっと後ろ向きですね…アドバイスいただいたのにすみません。
ライブラリの違いなどで同じデータでも読み込めない可能性があるということですね、承知しました。

Webmaster
2022-01-01 12:45
ログありがとうございます。
ファイルが手元にあれば再現できそうですが、今のところ対応予定はありません

少々気になる点があるため調査します。
致命的かというとそうでもない部分であるため、即何かが改善されることを保証するものでないことをご了承くださいm(_ _ )m

Takumiboo
2022-01-07 18:40
お手数をおかけいたします。
ちなみにエラーメッセージでは「パスが不正」とのことでしたが、これがファイルに付与されたタグに起因するものということはあるのでしょうか？
一般的にパスと言うとファイルパスのことを指すかと思い、またどうやら格納フォルダ名（=アーティスト名）が日本語で始まる楽曲が軒並み読み込まれていなかったので、そちらの問題かと思っておりました。

返信
Webmaster
2022-01-08 02:17
ちょっぴり長いですが経緯を解説します。

>そちらの問題かと思っておりました

これは「内部詳細」がWindows上ではイマイチな動きをすることが原因かと思います。

ご指摘のある「内部詳細」ですが、ここで行われているチェックロジックはスキャンのロジックとは独立しています。
ざっくり言うと、データベースに登録済みのレコードに対して、後追いで「このデータあってるのかな?」とチェックする方式です。
このチェックが品質の高いものかというとそこまでガチではなく、速度重視の簡易実装です。
本来このチェックがきちんと動作しているか証明するにはOSと主要なDBのマトリクスでテストする必要があります。

レビュー時にその点を指摘し実装者も把握していますが、結果的には現状の状態でマージされています。
(個人的には特にそこの方針に固執する気はありません。私が管理していたプロジェクトではないので)
またこの機能が見切り発車で役に立たないものかというとそうではなく、多くの方が配備するであろうLinuxでは問題が顕在化しません。
ですので、完全な実装でないにしても現実的には一定の有用性がある機能だとは思います。

Windowsの場合「Windowsじゃこのチェックちゃんと動かないかもね」とメッセージ表示する位ご丁寧な方が日本人向きかもしれませんが。
私なら本格的にWindows向けへプロダクト展開するならその時点で不具合を修正します。
プログラム的に2次被害を発生させるような不具合ではないので、修正の緊急性は高くないと見ています。

> ファイルに付与されたタグに起因するものということはあるのでしょうか

紛らわしくて恐縮ですが。
上記のような経緯があるため、内部詳細の画面で表示されている内容は、ファイルが読み込めない件とは無関係です。

ログを見る限りでは日本語であるかどうかもおそらく関係がなく、ディスクナンバーが登録されていないという単純なタグ不備があるように見えます。
ですので、お手数でなければいくつかのファイルにディスクナンバーを書き込んでみて挙動の変化を見るというのもアリかと。
(他のタグで同じようなことが起きなければ、すんなり読めたりするかもしれません)

___

現在Jpsonicは、Airsonicよりも若干タグの要件が厳しめになっているかと思います。

これは厳しいマゾ仕様が私の好みだから、というわけではなく、一応の理由があります。

どことはいいませんが、頻繁にメモリオーバーフローの報告があるAirsonic派生プロダクトがあります。
Airsonicはずさんなエラー処理が割と多いので、検証をおろそかにして強引に機能追加をしていけば、より深い沼にハマることもあるでしょう。

そのためJpsonicはまず、ありとあらゆるエラー処理をAirsonicよりも厳しめに書き換えるという修正を行っています。
メモリオーバーフローを発生させる疑いのある処理の対象には、がっつりとタグ解析の処理も含まれています。

・一端エラー処理を厳しめに極振りする (←今ココ)
・あまり厳しすぎるなら慎重に書き換えを行う

幸いにもJpsonicでは今まで一度もメモリオーバーフローの報告がありません。
これ自体は致命的によいコトです。

一方エラー処理を厳しめにしたのはプログラムの全範囲ですが、幸いにもちょっと厳しすぎる箇所は現状タグ解析くらいのように見えます。
多少強引な進め方ですが、結果的にはこのような事実が明確化されている分、レガシーサーバに比べ前進しています。

今後の流れとしては、ちょっと厳しすぎるんじゃないかナー?という箇所は、重点的に検証を追加し仕様変更を行うことになるでしょう。

ただし厳しいといっても、不合理なほど厳しいかというと「別に厳しいというほどでもないのでは」という捉え方もあることに注意してください。
フォーマット仕様上必須でなくても「現実的に楽曲データ管理するには半ば必須」というタグはあると思います。

現状Music CenterでFLACにタグ付けしているような場合ではエラーが発生していないと思います。
これは一般的なソフトウェアで必要とされやすいタグ項目はMusic Centerが埋めているためだと思います。
CDを作ってCCDBも管理してきたSONYですので、その仕様にはそこらのフリーウェアよりも視野の広い含蓄が含まれています。
そのレベルでタグ管理されているライブラリでは、Jpsonicはエラーを吐かないと思います。

これらの仕様はファイルフォーマット毎に異なるため、確認に案外と手間のかかる作業です。
ですのでボチボチ、となります。
今後スキャンの並列化云々にまつわる様々な修正を行う際に、おそらく比較的先の順位で着手することになるでしょう。

ものすごく先の話になるのですが、もしいったんスキャン仕様を甘めにしたとしてそのずっと後に。
タグチェックのような機能をもし仮に作るとしたら、タグ項目の仕様はSONY仕様に寄せると思います。
たとえば「ディスクナンバーが登録されていないよ!」というような注意喚起を出すようなチェックが作られると思います。
今はその過程にあるとお考え下さい m(_ _ )m

返信
Takumiboo
2022-01-23 15:34
試行錯誤の結果原因らしきものがわかりました。
日本語アーティスト名の楽曲がすべて表示されていなかったのでそれが原因かと思っておりましたが、よくよく見てみるとアルファベットのYやZから始まるアーティストも表示されていないことに気が付き、索引タブで見ていくと、とあるフォルダ内の楽曲がすべて表示されていないことがわかり、さらに索引順でそれより後ろのアーティストがすべて表示されていないことがわかりました。
いったんその不完全なアーティストフォルダを退避したうえでスキャンすると日本語アーティスト名の楽曲を含めた曲がスキャンされました。

該当のフォルダをはwavファイルとmp3ファイルが混在しているフォルダだったのですが、Jpsonicで表示されていない楽曲以降をMp3tagで見てみると、タグ情報が付与されているwavファイル（RIFFタグ？のものとID3タグのものがありました）で引っかかっているようでした。これらのファイルからタグ情報をすべて削除して再度スキャンしたらこれらのファイルも読み込まれました。
おっしゃる通り（詳細な原因は不明ですが）タグ情報の不備と思われるファイルが原因でした。お騒がせいたしました。

特にこれらのファイルにディスク番号などは付与されていなかったので、何か別の原因でタグの読み込みがうまくいかず、ログにはDISC_NO云々というエラーが出ていたのかもしれません。

これはおそらく開発上の方針にもよるとは思うのですが、利用者側の希望としては、何かしらの原因でパース出来ないファイルに遭遇した際には、そこで処理がエラー落ちして終了するのではなく、スキップして継続したり、どのファイルのパース中にエラーが発生したかをログに出力していただくなどすると原因追求しやすいなと思いました。
（ログでは今まで”Scanned media library with 2250 entries.”のあとにDISC_NO云々のエラーが発生し、そこでパース処理が終了していましたが、ファイル修正後は”Scanned media library with 3212 entries.”まで表示されており、エラー以降は処理が停止してしまっているようでした。）

これで移行に際しての問題は解決したので、Airsonic-advancedからJpsonicへの移行を本格的に検討したいと思います。
ありがとうございました。

返信
Takumiboo
2022-01-23 21:00
すみません追記です。
他に多数ディスク番号の無い楽曲データがあり、それらを読み込んでもエラーは出なかったため、ディスク番号タグの有無が原因ではなかったようです。

返信
Webmaster
2022-01-24 01:48
回避方法が見つかったようで良かったです。

パーサの問題点は概ね把握しておりまして。
レガシーサーバのコードがどうなっているかというと、どんなファイルであろうが決められたタグを読みに行きエラーが返ってきたら握りつぶすという実装をしています。結果的に問題があってもスルーされるだけ、という動きになります。
これがユーザの望むべき理想的実装かというとそうでもなく、解析中にもっと深刻なエラーが起きたら?という点まで考慮されていないため修正対象になります。

現在は応急処置的に、ログを出力し解析処理を止めています。
結果的に一般的に使用されるようなタグがサポートされないようなファイル混じりのライブラリでは、ご指摘のような現象が起こる可能性があります。
全てFLACやMP3で管理しているような割と一般的っぽいライブラリでは再現しないため、後続処理で長期放置されていたより目立つ不具合(特定条件でFLAC再生できない問題等)を先に潰していたという次第です。

パーサは後のバージョンで正攻法の実装に改善予定です。が、メモリオーバーフローのような深刻なエラーが一回でも検知されれば即座に処理は停止されなければならないというのがマストの仕様になります。それ以外がどのような仕様になるかは今のところ未定です(善処しますが使用しているライブラリの設計次第の部分も含むため、現段階では細かい部分まで確定していません。SubsonicやAirsonicが設計放棄した部分なため)。

お手数ですが、しばらく凌いでいただくという方向で・・
ご報告ありがとうございました m(_ _ )m