各種デフォルトディレクトリの起動オプションのキー名は変更されています。
他の類似サーバと並行稼働させる際に、設定ミスによる万が一の競合を避けるため。
Jpsonic開発開始当初からの仕様です。

Airsonicと同じ起動オプションが存在しますが、少し仕様が異なるものです。

v107.0.0以降導入されたDLNA起動ポートの仕様が、AirsonicとJpsonicでは異なります。

• SubsonicはDLNAの起動ポートは自動割り当て
• Airsonicはデフォルト4041固定。起動オプションUPNP_PORTによって明示指定可能
• JpsonicはデフォルトWindowsで自動割り当て。Linuxでは起動オプションUPNP_PORTによって指定必須

SubsonicからJpsonicへ移行した方が混乱しない仕様に変更されています。
Airsonic仕様では自動構成機能を持つWindowsの場合設定にてこずる場合があり、回避方法がWindowsのバージョンによって変わります。競合が発生した場合のリカバリはLinuxよりもWindowsの方が面倒なためSubsonic仕様にあわせています。

Spring Frameworkの最新化によりコンテキストパスの指定方法が変わります。
起動引数によりコンテキストパスを指定している方には影響があります。

初回起動時にスキャンを行うかどうかの仕様が、Subsonic/AirsonicとJpsonicでは異なります。

• Subsonic/Airsonicは初回起動時にスキャンを自動で開始する
• Jpsonicは初回起動時にスキャンを自動で開始しない

レガシーサーバが起動時にスキャンを強制するのは、全ての機能が索引データが存在する前提で設計されているためです。一方ストレージのマウントのタイミングが予測しにくいケースでは自動スキャンを行いたくない場合もあります(レガシーサーバではDocker等の起動時にトラブルが発生したという前例がある)。そのためJpsonicでは自動スキャンを選択制とし、デフォルトはオフに変更してあります。

DSDのMIMEを変更可能です。大抵のDSD対応サーバにはこのような設定項目があります。

JpsonicのDSDのMIMEは、dsf/dffのいずれもデフォルト値は「audio/x-dsd」です。AndroidのBubbleUPnPはこの値で認識するため、Jpsonic側の設定を変えなくてもローカルレンダラへdsfを渡すことができます。

DSDのストリーミングは一般的でないためMIMEには統一見解が存在しません。そのためデバイスベンダー各社が各々に都合のいい値を使用しているのが現状です。おそらくDSDをストリーミングしている方は使用されている機器の仕様を把握していると思われるので、audio/x-dsdで問題がある場合は適切な値に書き換えてください。

BubbleUPnP Serverには、プロクシを建てる際に元のサーバのDSDのMIMEをオーバーライドする機能があります(2021年12月)。そのためもし多くのサーバを建てている場合、BubbleUPnP Serverでグローバル管理するというのもひとつの方法です。

JpsonicではフォントにJavaの論理フォント(間接的に参照するシステムのフォント)を利用します。v111.4.0以前ではフォントのトラブルを回避するため埋め込み日本語フォントが利用されていました。強制的に以前のフォントを使用したい場合、オプションで切り替えることができます。

おおまかに以下のようになっています。

• Webレイヤの遮断。既に開始済みのセッションを除き新規リクエストには503がレスポンスされる
• 開始済みのリクエストの終了を一定時間待ち、強制終了(接続中のブラウザやアプリを全て終了することで待ち時間をなくせる)。
• 処理中のバックグラウンドプロセスの停止処理。サウンドデバイスは即時クローズ、他のほとんどの処理は一定時間終了待機。Podcastやスキャンのダウンロードの場合、再起動後に再実行したときに完全復帰できる「できるだけキリのよい」ポイントでのキャンセルを試みる。一定時間内に中断できなければ強制終了。
• キャッシュマネージャのシャットダウン(バックグラウンドプロセスが終了するまで停止できない)
• データベースのシャットダウン

スキャン中にシャットダウンを実行した場合の挙動は、従来のサーバは完全にデータベースまかせの仕様となっています。Jpsonicは、この辺りを特に説明しなくてもなんとか使えるであろう仕様になっています。

• Subsonicの場合、実際のところどうなるか不明(データベース破損の報告が多い)。
• Airsonicの場合、スキャン終了後または自動デフラグ実行時にCHECKPOINTが実行される。そのためスキャン中にシャットダウンした場合でも、あとから意図的にROLLBACKを実行し再スキャンを行うことができる(整合性はスキャン終了タイミングで保証されている。強制中断による整合性の回復のためにROLLBACKが必要となるかならないかは運次第だがほとんどの場合必要)。あるいはそのようなフローを期待した設計と実装。スキャン以外についての整合性は考慮されていない。
• Jpsonicは異常終了/正常終了時はAirsonicと同じ仕様。スキャン中にサーバのシャットダウンが開始されスキャンがキャンセルされた場合、分かりやすく言えばスキャン途中のアルバムはスキャンしきってから処理を終了する。またキャンセル時にはCHECKPOINTが実行されない。ほとんどの場合直前のコミットまではDBにフラッシュされるので、次回起動後のスキャンは、前回までの内容をスキップし次のアルバムからスキャンが開始されるイメージ。前回スキャン中にシャットダウンを行い、特にエラー等の記録がなく終了できている場合、ロールバック等の操作なしにスキャンの再実行で整合性が回復できる。正常終了時にはAirsonic同様CHECKPOINTが実行されているため、意図的に前回の正常スキャン終了段階までROLLBACKすることも可能