アップデート方法

Jpsonic 更新履歴

直近数バージョンの変更点が記載されています。全ての履歴はCHANGELOGに記載があります。
スナップショット版の利用等、注意点はJpsonic ダウンロードに記載があります。

jpsonic v114.0.0

無事Spring Bootというフレームワークの大ボスを最新版に移行完了したバージョンになります。v113とv114でデータに関する変更はありません。そのため単体起動の場合はwarの交換、Dockerの場合はタグを変えるだけでOKです。TomcatやJettyに配備している場合はバージョンが変わりますので、リリースページをご覧ください。

ユーザ視点では、v113とv114で機能差がありません。内部的には以下のような点が変わります。

  • UPnPのライブラリがclingからcling派生のjupnpに代わりました
  • より精確に動作するように同期処理が改善されました
  • Java21の場合、一部の処理が仮想スレッドを使用するよう修正されました

もちろんサーバにとっては良修正ではありますが、目に見えるような機能変更ではないので気づかれないかもしれません。

一応簡単に解説
jupnpは、現在のUniversal Media Serverが使用しているライブラリです。clingと処理はほぼ変わっていませんが、セキュリティ修正が含まれています。Spring Bootをメジャーバージョンアップするとclingが古いライブラリに依存しているのが明るみに出てしまう箇所があり、UPnPクライアントとサーバを自前で書き直す必要がありました。そこまでやるともうcling使ってもjupnp使っても大して変わらんレベルなので、移行してしまおうという算段です。jupnpは近々メジャーバージョンアップが予定されておりまして、それには一部リソース改善が含まれています。jupnpの次期バージョンが公開されたら取り込む予定です。

同期処理やら非同期処理やらは話がややこしいのですが … Subsonic/Airsonicは処理競合を防ぐsynchronized処理があります。ただその書き方だと意味ない、というのが多かったりします。これらはJpsonicでは全部ロック処理に書き換えられています。一見複雑なのですけれども、Javaのソースコードというのはインタプリタ言語と違って実行時にJVM側で最適化がされます。ですので、複雑に書いたからといって一概に遅くなるわけではなく、むしろ見た目の印象に反して速くなることもしばしばあります。大体ちゃんと動くように書いておいたほうが幸せになれます。たくさんカバーアートを表示するような場面では体感できる速度差が出るでしょう。かつ、他のメディアサーバに見られるような画像の欠落や誤作動も今のところない、のではないかと思います。

仮想スレッドに関しては、Jpsonicはもともと短期処理を扱うデーモンスレッド用のスレッドプーリングが設計されていたので、それが仮想スレッド化されました。それほどあちこちで使われているわけではありませんが、例えばLast.fmにscroblingするような処理はデーモンスレッドにぶん投げとけばよいわけです(サーバのシャットダウン時に停止されたところでどうということはない)。そういったどうでもいい系の処理は仮想スレッドで処理されます。またUPnPのディスカバリ処理も仮想スレッド化されています。

というわけでSubsonic/Airsonicの不具合を修正しつつ … Servlet バージョン6.0、Java21、Dockerで特にトラブルなく動作可能というイマドキ構成に追いつきました。ぼちぼち機能を改修していきます。

v114.x.x以降で行われること

v115ではPodcastの全改修が行われる予定です。これはほぼ新規開発と同じですので多少の時間がかかるでしょう。Podcastをあまりご使用されたことがない方のために説明しますと。

Podcastプレイヤーはスマホアプリでもわんさかあります。ほしいのは、サイズを気にせず決められたチャンネルを粛々とNASにアーカイブしつづける機能です。Podcastは意外と公開期間がまちまちです。NHKであれば日に3回更新ですし、隔週のチャンネルですと割とずっと公開されているものもあれば、短期で消されてしまうものもあります。逆に番組がなくなっても数年公開されているチャンネルもあったりします。全然バラバラなんですね。

気に入ったものを毎度すぐ聴くスタイルなら簡易プレイヤーでOKです。でも実際のところ、好きな有名人の番組でも隔週15分のチャンネルなんかは忙しいと案外聞き逃したり。そんなのは思い出したときに数か月分まとめ聴きしたい、みたいな使い方もしたいわけです。ので、チャンネルごとに保存期間を設定できたり、失敗したら自動でリトライする機能が必要です。そして全体的に信頼できる動作をしてくれれば結構なことでございます。

私が使いたいので作りますけれども、いくらか分割するにせよ作り始めたら中途半端に終われない感じの機能群になります。というわけで、それする前にv114.x.xでは即効性の高い機能改善をしておきましょうと。いくつか機能拡張が行われるのですが、大きなところではメニューの再編成が予定されています。

メニューの再編成

修正はUPnPが先に行われます。メニュー項目の有効化/無効化、順序、名称のカスタマイズができるようにします。UPnPの場合以下のような方向性。

  • Folder、Album Artist、Album、Genre、Podcast、Playlists、Recently、Shuffle、Yearのようなメニューアイテムがデフォルトで用意されます
  • メニューアイテムは有効化/無効化、順序、名称のカスタマイズができます。設定画面でカスタマイズするとスマホアプリ側ではそのとおりの表示になる、ようなイメージです。Album Artist表記をArtistに短縮したり、母国語に変更したりできるメリットがあります。たったこの程度のことができるものがなかったりする。
  • 今現在存在しているUPnPの項目は、全てこれらの子アイテムに変更されます。子はチェックボックスで有効化/無効化できます。グループ内で一つしか選択されていない場合、ダイレクトにそれが使用されます。複数選択された場合階層表示
    • 例えばArtistは索引表示で表示したほうがいい場合と、索引でなく直列で表示したい場合があります。これはスマホアプリ側のUIにもよるかもしれないですし、曲数にも依存します。一生どちらかひとつでいいという方もいますし、使い分けたい方もいます。ですので選択制が優れています
  • 初見の方がウェッとならないようにできるだけフツーっぽい組み合わせになるリセットボタンが追加されます
    • SubsonicのGenreは特殊なのですけれども、それとは違うフツーっぽい動きをするGenreを今後新設したりします
  • こういう作りにしておくと、あとから新たなメニューアイテムの追加がしやすいです。新しい項目はWebページよりもUPnPで先に作成されます。UPnPで動くデータフローを作っておけば、大抵は他のプロトコルに転用が可能なためです
  • 自分が視力を失ったことのことを考えますと、ここまでできてればBubbleUPnP + TalkBackでなんとかなると言える水準かなと。日本語ソートも音声入力の検索も使えますし。備えよ常に

Webページ側もUPnPのメニューとほぼ同じ項目になりますが、UPnPほど多くの子項目は作られません。ブラウジングはフォルダとID3で、それぞれ作り直す予定ではいます。ドロワーに索引表示するスタイルは廃止される予定です。

jpsonic v114.0.0 Alpha 2.1

現在マスターで公開されているv114.0.0 Alpha 2.1は、一部仮想スレッドへの置き換えと、同期実装の修正が行われています。Dockerのlatestタグではv113.xの最新が使用されますが、114.0.0.alpha.2.1のタグを使用することでお試し版が使用可能です。

といいましてもそれは、形式的なものでして。タグはlatestかeaを切り替えて試すという方が多い気もします。まぁ私がいつもしていることです。バグ少ないからeaでええやろ、みたいなご判断であれば光栄ではありますけれども…

一応、開発用のDockerイメージは目的や使用用途が決まっているのでHow to use ea (Early Access)という記事をWikiに追加しました。今更ですが、無保障ですし、ポートはひとつ余計に空いてます、といったところが注意点になります。(無保障→リリース版はデータの仕様がかわりフルスキャンが必要な場合に公知されます。このときLuceneとDBのバージョンアップのいずれかまたは両方を、一回のフルスキャンで同時にマイグレートします。eaは開発中なのでタイミングによってはそうはなりません。大抵はフルスキャンで辻褄が合うのですが。)

それと。開発中にメモリとかCPUの動きを見るのですけれど、こういったもろもろの作業をするのにJDKを積んだりポートを開けたりが必要です。ダウンロードサイズも結構(100Mb位)変わってきます。そのためlatestやナンバリングバージョンはスリム構成版、eaは武器搭載版、と切り分けています。

jupnpの次期バージョンではメモリ消費が少し改善すると思っているのですが、どんくらい変わるかなーとかそういったことの確認にeaが利用されます(OSコマンドいくら叩いても、こういうのは把握不可能です)。注意点としてはJMX接続中はこれ自体のメモリ消費も載ってくる点です。Jpsonic位のサイズ感ですと無視できない位の量にはなりますので、ピンポイントで特定箇所を調査するとかざっくり見るときに使います。

スキャン中の変動を見るときなんかはやり方がまた違います。GCログをしかけて、条件を変えたものを何度も何度も計測するような形になります。それにDocker側のcgroupsを足したものが今Jpsonicで出している曲数とメモリの目安のマトリクスです。曲数多くないからメモリ少なくしよっかな、みたいなことは可能なのですが、感覚頼りで小さくしすぎると、Javaの場合は動きはするけれどGCの頻度が上がる、長期的にはメモリの使い方が効率悪くなっている、みたいな本末転倒なことになります。ピークタイムであるスキャン中のGC Activityを基準に調整するとよいです。そうするとDS220+位のスペックの場合ですと、普段音楽聞いてるときなんかはCPU利用率1%以下みたいなサーバになると思います。

前回までのあらすじ

v114ではフレームワークのメジャーバージョンアップが行われます。修正・動作確認の範囲が膨大なため、4段階位に分けて先行リリースするということをしています。これ以外のトピックもあるのですが、さほど大事ではないのでv114以降でOKという扱い。

バージョン 主な内容 ねらい
Alpha 1 Spring を 3.2x に移行、UPnP ライブラリの刷新(jupnp) とにかく最新のライブラリ構成をマスターにマージする
Alpha 2 スレッドの再実装 仮想スレッドありきの実装に適応していく
Beta 1 アップロードの再実装 実装が相当古く非推奨指定になっているので書き換える
Beta 2 権限の再実装 無理矢理動いてはいるけど、現在のお作法に書き換える

普段はこういったことはしないのですが、最新構成をマスターにマージするというのがかなり大事なのですね。簡単にいうと私が楽なのです。一番大事な要素じゃん。

仮想スレッドは銀の弾丸ではない

既存の処理の一部が仮想スレッドに置き換えられています。これによって今までと次元の違う動きをする!ということは基本ないです。もともとWebアプリはマルチスレッドで動いていますし、主要箇所はスレッドプールされています。仮想スレッドはその想定を超えていくようなトラフィックが発生する規模でないとあまり活きないかもです。個人で音楽ストリーミングする程度の規模のアプリではスケールメリットがほぼないといえます。ここで劇変しようものなら、今まで何やってた…となります。

もともと仮想スレッドとほぼ同じ用途のため作成していたデーモンスレッド用のプーリングと、UPnPのディスカバリ処理が仮想スレッドで非同期実行されるよう修正されています。違いに気づく方はほぼいないのでは、と思います。

ただし仮想スレッドと関連しているロック関連の修正でms単位で影響しそうな修正も含まれています。ですので音ゲーが得意という位の敏感な方ですと、少しレスポンス上がったなーという気分になるかもしれません。

半面いいこともある

大規模開発じゃないと意味ないものかというとそうでもなく、使いようかなと。旧来の方法では割と煩雑になりがちだった実装が、仮想スレッド前提であれば簡易化されるようなことはあるかと。特にファイルスキャンの並列化とは相性がよいでしょう。本来は、いくつあるかわからないファイルを並列で読んだり読まなかったり、みたいなことをゴニョゴニョする必要があるのですが、トリッキーなコードを書かなくても大丈夫になるかなと。と思ったからほっといたのですけれども。

それとOracleさんのドキュメントにあるように、仮想スレッドを有効活用するには同期実装自体をかなりきちんと整備する必要があります。それらを書き直すだけで動作品質は上がるという面はあるでしょう。

Jpsonicの場合、画像のキャッシュ作成の速度は体感差があるかもしれません。(全体的にマズい)Subsonic/Airsonicの同期実装の問題の中でも、比較的気づきやすいのは画像キャッシュです。特定条件で黒画像が表示されることがあったので、Jpspnicではグリッチの発生確率を抑えるため事実上シングルスレッドで動かしていました。おかげでたくさん画像を表示するとパラパラ、パラという表示速度だったのですが、v114 Alpha 2では精確に速く表示されるよう修正されています。一度データディレクトリ直下のサムネイルのキャッシュ(thumbs)を削除して、アルバムの一覧を表示してみると以前との差がわかりやすいかと思います。

次期バージョン(Beta)で行われること

アップロード機能のマイナーな修正と、権限の部分のマイナーな修正が行われたら、v114.0.0がリリースされる予定です。ですので、今の状態からv114.0.0は動作がほぼ変わりません。ですので何かお気づきの点がございましたらご指摘ください。多分どうもないと思うのですけれども。色々と新しいこともやりたくなりますけれども、とりあえず当初の予定通りv114.0.0をリリースしてからにしましょー。

jpsonic v114.0.0 Alpha 1

Jpsonicの開発が始まって以来の「お試し版」のリリースになります。Jpsonicの場合の定義としては、「アルファ版はあまり使わない機能だけれど、機能制限があるよー」「ベータ版は正式版とほぼ変わらないけど、ユーザの目に見えないとこ直してるよー」といった区分けです。

お試し版とは

v114.0.0では、数年に一度規模のフレームワークの更新があります。JpsonicはJava21 + Spring Boot 3.2 + 埋め込みTomcatとJettyのクロスコンパイルが可能、war配備も可能といった、欲張り構成です。ネットで事例が探せない程度にはぶっちぎり最先端の構成であり、サーティワン換算した場合、およそ4段タワーに匹敵すると言われています。詳細はこちらです。

さすがに動作確認項目が多いので、多少のとりこぼしも想定せざるを得ないところです。どういうことかといいますと、Jettyでは過去にちょくちょくあったケースですが「バージョンアップをしたら今までみたことない警告がログに出るようになった」みたいなレベルのことまで確認するのはさすがに一定期間必要です。そうするとリリースがどんどん遅くなります。何か見落としていそうな部分が見つかれば、ご指摘ください、という方向性で。OSSですからね。データがぶっ壊れるかもしれないとか、そういったリスクはありません。

お試し版の使い方

Dockerイメージはこちら

  • v113と次期バージョンは、データの仕様は同じです。Dockerの場合、タグを書き換えればお試し版が使えます。またv113に戻せます
  • アルファ、ベータ版は自動更新の対象外です。「latest」タグを使用している場合、アルファ、ベータ版は使用されません。「latest」タグで取得できるのは今のところv113の最新です。もちろんv114が正式リリースされるとv114に切り替わります
  • これ以降、基本的にはv113に機能更新はなく、メンテナンスモードです。ただし現状は安定版としての位置づけですので、世間をゆるがすセキュリティ問題が公表されたときには対処をします

既知の機能制限はあるのですが、普段使いに影響はないというご判断であれば、v114メインでお使いいただいて問題ありません。今のところアップロードが使えないだけです。(Windows Media Player12で接続ができない件は114.0.0.alpha.1.1で修正済みです。

アルファ、ベータ版の明らかな優位点として疑陽性も含めCVE警告が0件という点が挙げられます。v113は疑陽性を引いて考えるとCVE警告が1件あります。最後の1件は処々の理由から部分的対処が面倒なため、v114のリニューアルの際に関連ライブラリを丸ごと入れ替えるという方式で解決しています。基本的に私は「お試し版」リリースを好まないのですが、多少の機能制限が発生してもv114のマスターマージを急いでいるのはこの辺りが理由です。

フレームワーク(Spring Boot 3.2)更新のメリット

ユーザ視点で、何か直近の恩恵があるかというと、あまりないかな、と思います。HTTP/1.0やHTTP/1.1はもちろん、やろうと思えばHTTP/2、HTTP/3が扱えたりするのですけれども。一般的な音楽アプリ使ってストリーミングするときに関係あるかというと、今のところはないです。ブラウザならできるといえど、どんだけバッテリー消耗させてそれやるの?みたいな話になります。

ゲームボーイと同じです。他社のカラー液晶ゲーム機が電池6本使って2-3時間の頃、4本で白黒液晶を3-40時間動かしてしまうと。結局みんなゲームボーイしか使わなくなるんですね。ブラウザ上での動作を極めるみたいな方針はメディアの分野では効率悪いかなと。ブラウザやハードウェアが超進化したら話は別ですが、間違いなく新たなゴミにリソース割くようになりますしね。

フレームワーク経由で利用可能な新しい機能でJpsonicと関わりがありそうなのは、仮想スレッドくらいかな?と思います。これはもちろん使っていくつもりです。ただ世界が変わるレベルかというと、やってみないとわからないかな?と。海外の事例だと900倍速くなったわwみたいなのを見かけましたが、業務用のつよつよハードでのお話ですので。家庭用NASみたいな環境だと検証しないとわからないし、逆効果になるケースもあるかなと。ただそういったことを試すための準備は段階的に行われていますし、機能向上が見込める箇所もあります。マルチスレッド対応は、全部機能やらスレッド単位で考えています。

個人的には、古いライブラリや実装が入れ替えやすくなった点と、場合によって仮想スレッドが活きる、程度だと思っています。生産性が上がる? 関係ないと断言できますね。フレームワークとかプログラミング言語はすぐ「〇〇より生産性が高い」みたいな話になりますけれども、メディアサーバなんて大学生がポンポン作り出すくらいの変化を生み出せないと画期的とは呼べないと思うのですね。生産性が上がる上がるってずっと言ってる割に、むしろソフト開発して公開する日本人は減ってる気もしますしね。

UPnPクライアントとサーバの刷新

どうしようかなーと思い、ずーっと先延ばしにしていたUPnPライブラリが最新化されます。

今まで使っていたのは、clingというライブラリです。初期のBubbleUPnPなんかがこれを使っていたはずです。これはとっくにEOLが表明されていました。後継者を探しているのですが話は進んでいない模様。Jpsonicがこれから使用するのはjupnpというcling派生のライブラリです。Universal Media Serverが今これを使っています。文字化けの不具合が一点あり回避コードを書かざるを得なかったのですが、Issuesを挙げたらすぐにBugのマーカーがついていました。現在メジャーバージョンアップの準備中だそうで、もりもりメンテナンスされています。

ここから先はちょっと技術的な無駄話になりますけれども。UPnPの実装方法というのはプロダクトによってかなりまちまちです。BubbleUPnPがclingを使用していたのは、clingがAndroidサポートをしていたためだと思います。BubbleUPnPの製品群は広範なプラットフォーム対応をしているので。

jupnpは化石化しつつあるAndroidサポートを除去することを引き換えに、新しいJavaに追随していく方針のライブラリです。Androidの代わりにOSGIサポートが手厚くなっています。OSGIというのはアプリケーションコンテナのプラグイン機構みたいなものです。サービス単品をJettyやらTomcatで動かしたときに、うまいこと動かしてくれる古典的技術です。ただ問題点がありまして、jupnpでなくOSGIプロジェクト自体のサーブレット対応がやや遅れ気味です。多分需要は低いのでしょう。コンテナでマイクロサービス乱立みたいなことができなかった頃の技術ですので。

JpsonicはOSGIを使用せず、UPnPクライアントとサーバを自前で作っています。Universal Media Serverも似たような方針です。ただしUMSはSubsonic系列よりもゴリゴリな設計をしています。通常のWebページなんかもUPnPと同じポートで受けて、独自にフィルタリングした上でレンダリングする実装になっています(多少フィルタ設定できるぽいように実装されてるように見えますが使ったことはないのでよくは知らない)。

Jpsonicは普通のWebページはSpring実装、UPnP通信用のHTTPサーバはSpringと別口の実装、と別れています。冗長な設計に見えますけれども「UPnP用のポートをWANに公開する必要がない」という、ルーティングがわかりやすい構造になっています。ファイアウォールの設定とかを理解している方であれば、外部接続用のSubsonicのHTTPポートと、LAN用のUPnP用HTTPポートが分かれているよ、という仕組みに安心感を覚えるかもしれません。ビギナーの方にとっても、うっかり穴あけちゃうリスクが減るのでよいのではないかなと。どこのポート公開すればいいの!?ってときはブラウザで見てるポートだけ公開すればいいよで話が終わります。

v114.0.0 用のproduction.synology.ymlには、このUPnPの待ち受けに使用するサーバを多少チューニングできるよう設定項目が追加されています。

jpsonic v113.0.0

長らく続いたスキャンの改修が大詰めとなり、このバージョンはスキャン処理にアーティスト索引の生成を組み込むという改修が行われています。以前のバージョンと見た目が変わる部分はほぼないのですが、今後改修していくための布石がいくつか組み込まれています。

アップデート時の注意点

今回のアップデートではフルスキャンが必要です。スキャンボタンの下にある「タイムスタンプを無視する」というチェックボックスを有効にして保存した後、スキャンを実行してください。

本来これは自動で行われるはずですが、若干見落としがありスキャンボタンを押しただけではID3の検索索引が更新されません。Webページの検索に支障はありませんが、アプリから検索が行えない場合があります。起動後に普通のスキャンをしちゃったよ!という場合でも、「タイムスタンプを無視する」を有効にすることで通常の状態に戻せます。スキャンが終わったらチェックボックスはオフにしてください。

v113.0.1で改修済みです。v112.xから直接v113.0.1に更新した場合、通常のスキャンを行うだけで移行が完了します。すでにv113.0.0を使用している場合、「タイムスタンプを無視する」が必要になります。

バグ修正

3つ目の修正はユーザさんからのご指摘があったものです。スキャンに関する問題は、レアケースであってもよくないものは修正しますよという方針です。何かお気づきの点がございましたらご指摘ください。

送信バッファサイズを修正 #2377
Postgres でスキャンが失敗するバグを修正 #2380
ドットで終わるファイルまたはディレクトリの処理を回避するように修正 #2492
ドットで終わるファイルまたはディレクトリについて

「ドットで終わるファイルまたはディレクトリ」はWindowsのエクスプローラでは作成もできず開くこともできません。コマンドやプログラム経由だとそれができてしまいます。現実的にはレアケースにあたるとは思うのですが「ドットで終わるファイルまたはディレクトリ」はスキャンをスキップするよう修正されました。

リッピングソフトはどのようになっているかといいますと。ファイルは大体.flacや.mp3のように拡張子がつきます。ディレクトリの場合はT-SQUAREのYES,NO.のようなタイトルがドットで終わるようなCDをリッピングしたときに、ソフトウェアによっては妙なディレクトリを作成する場合があります。これに関しては仕様はまちまちです。強制的にドットを削除したり何かに置換したり、あるいは置換するパターンを指定できるようになっていることもあります。

この問題が発生するときは、ユーザ側がその問題に気づいていない場合も多いです。そのためログに警告を出すようになっています。Jpsonicがこれをスキップしないで処理できるようにする、というのは悪手です。結局のところ手持ちのライブラリがOS依存になってしまい、いずれどこかで問題が起きるためです。

ユーザさんとのやりとりにもあるのですが、ディレクトリ名をUNICODEに置き換えるのがよいのではないかなと。なんでもよいのですが例えばドットは以下当たりが候補です。

  • … (Horizontal Ellipsis)
  • ․ (One dot leader)
  • 日本人はアポストロフィはあまり気にしませんが色々と論争があります。フランス語だと1単語にアポストロフィ2個入ってくることもあるので死活問題。

特に上記のものである必要もありません。句読点や記号はうまいこと処理されます。音楽関係の文字列は新聞等と異なり、多数の国の文字や特殊文字が使われます。UNICODEはどんどん拡張されていきます。信頼性と保守性を確保するためJavaとLuceneが使用されています。

最近のPodcastはこんなカンジです。おじさんびっくりだよ。

UNICODEの話は難かしい雰囲気になりがちなので、実例で見てもらった方が早い。

Horizontal Ellipsisも普通に使われているようです。半角カタカナ交じりでも検索やソートが使えなくてはいけないと。ファンシーな文字使った程度でパニック落ちするような造りはしていないのでUNICODEを活用してください。

機能改善

v113.0.0のテーマはログイン読み込みが遅いという問題を解決していくための修正、といってほぼほぼ差し支えありません。ログイン一発目がもったりする原因の中で一番根が深いのが索引です。v113.0.0では索引生成の高速化により、この問題が半分くらいは解決します。残り半分はWebページ側の改修が必要なのでぼちぼちやっていきます。

Web ページの微修正 メモリの表示桁数を変更 #2377
内部詳細の改善 #2341#2376
スキャンの進行表示を改善 #2485
Subsonic API getAlbumList2のソートで大文字と小文字を無視するように修正 #2441
Docker の改善 production.synology.yamlの更新 #2361
DSM タスク スケジューラを使用したインストール手順を追加 #2385
索引の高速化 スキャン時にMusixIndexを登録する修正 #2423
音楽インデックスの生成を高速化 #2431
UPnPの改善 設計の改善 #2436
実装の改善 #2446
索引の高速化

どのくらい速くなるのかということですが。
DS220+のスペックでは、40万曲(アーティストが8,000、索引数を70)に調整した索引の場合、以前のバージョンを使用して起動直後の索引の生成時間(サーバ側でオブジェクトが生成されるのにかかる時間)を計測すると以下のようになります。Airsonicではログインに1分かかる場合があるとのことですが、Airsonicの実装では条件次第で十分あり得る数値かと思います。

6,493 ms
2,126 ms
1,977 ms
1,843 ms
1,625 ms
1,522 ms
1,548 ms
1,555 ms

v113.0.0からは大体10倍くらい早くなります。10倍というよりも、実用速度の閾値に収まりやすいようにボトルネックが改善された、ということに意味がある。

893 ms
228 ms
179 ms
177 ms
164 ms
164 ms

この修正により、特に大きなライブラリに対してSubsonicアプリを使って索引を取り出すときの速度も向上します。実際にはもっとたくさんアーティストが入ってくる、なんてことも想定できます。ここは速度にこだわらないとまずい部分です。索引をトップページから他のところに持っていくというだけでは根本解決にならないので、索引生成自体が高速化されています。

UPnPの改善

以前からUPnP側でも索引は利用可能です。ただDLNAには速度規定があるので、遅い索引はキャッシュが行われていました。あまりやりたくはなかったのですが必要悪として。このバージョンからは索引がノーキャッシュになります。

それとUPnPでは索引 > アーティスト > アルバム > 曲のような階層表示が行われているのですが、これらは全部裏でSQLを使って実現されています。UPnPのデータ通信の仕様はちょっと面倒で、ほとんどのリスト取得にCount/Offsetがついてきますし、親オブジェクトのプロパティには子のCountが含まれていたりします。どういうことかといいますと。

今現状、WebページとSubsonic APIでは索引を取得するときにライブラリ全体の索引を丸々生成して取得する仕組みになっています(APIの仕様でそうなっているからです)。UPnPでは既に索引の部分取得や、索引をキーにしたアーティスト検索が実用されています。音韻索引が使用されるような国の言語も含め、この処理ができるメディアサーバはJpsonicだけです。

バックグラウンドがこういう設計になっているので、応用してWebデザイン改善できますよね!?という具合に話がつながっていきます。

WebページでID3とFile Structure(タグとフォルダ)の両方のツリーが使えると便利なんだけどなー、と考えられる方もいらっしゃるかと思います。まぁ私もそう思ってはいますが、障壁となるSubsonic/Airsonicの問題が2点あります。

  • ID3の解析が誤っている
    • Subsonic/Airsonicはフォルダ構造を解析する際に、メディアファイルの入っているフォルダをFile Structureのアルバムとします。で、そのアルバム単位でID3のレコードを作成するので色々と困ったことが起きます。きっちり3階層管理している場合には問題がありませんが、ひとつのフォルダに異なるアルバムタグを持つ複数の曲を配置していると問題が顕在化します。(一番キモイのは、ID3に存在しないデータがノイズとして作成されるケースが存在すること)
  • 索引の生成が遅すぎる
    • 速度については上に具体的な数値が出ているので割愛しますが。全体取得の場合最低でもJpsonicくらいの速度が出せないときついです。部分取得もできないと、遅延処理が実現できなくて詰みます

これらを解決しないと、フロントエンドだけでユーザビリティを向上するなんてことは不可能です。スキャンを再設計するしかないというところで止まったのがSubsonic/Airsonicの系譜。Jpsonicでは、このバージョンまでで上記2つは解決済みとなります。個人的にはものすごくあかん部分だと思っていたので、終わってから言うスタイル。

メンテナンス

これらは現在の機能に直接どうこう、といったものではありません。メジャーバージョンアップでデータベースのスキーマを変更しているので、ついでに今後必要となるスキーマ変更も先行で行っておく、ということをしています。

今後の改修の布石 Daoの依存関係を逆転する #2378
menu_item テーブルを追加 #2473
archivedフィールドをmusic_folder テーブルに追加 #2463
プラットフォームを最新化 CI から Java11 を削除 #2327
Java 17 構文への書き換え #2338
「Rewrite」を使用して Java 17 構文に書き換える #2370
temurin-jdk-17 を temurin-jdk-21 に更新 #2403
jpsonic/jpsonic:ea に JDK が使用されるように修正 #2391
Lucene の更新 #2478
Dao関連
JpsonicのSQLは色々なDBに差し替えることができるようにやや古めのANSIで記述されています。データベースを限定すれば、スキャンの差分更新なんかは多少は速く行えます。実際のところ外部DBで使う人はあまりいないとは思うので、HSQLDB特化のクエリに書き換えればもっと速く動くよ、となるかと思います。そういったことがやりやすいように仕組みが作り変えられています。

こういった方法を実現するフレームワークも色々とあるのですけれども、この規模でそれしたらかえって保守性下がるかなと。のでSpringで適当にインジェクトするライトな方式です。

menu_item テーブル
WebページとUPnPのメニュー項目が整理される予定です。有効無効、並び替え、名称変更等が行えるようになる予定です。

それに伴いWebページもUPnPも構成が変わるのですが、一気に修正するのは負担が大きいです。ですので修正したものから使えるようにし、足りていないものをあとから追加できるような仕組みになる予定です。基本的にはUPnP優先になります。UPnPできちんと設計されているなら、他のプロトコルに持っていくのはさほど困難なことではないためです。

archivedフィールド
ミュージックフォルダの設定ページで、ディレクトリごとにアーカイブ機能をつける予定です。これを有効にするとスキャンがスキップされるようになります。曲がたくさんあって「もうこの曲はタグの編集しないし、ずっとNASにおきっぱだなー」というのがわかっているのであれば、ディレクトリ単位でまとめておいて上書き禁止にするようなイメージです。

スキャンは既に差分更新に対応できるようなフローに設計変更されています。とはいえ少し変えないといけない部分もあるはずで、動作確認もそこそこ面倒なので後のバージョンにまわします。

スキャンは幾分速くなるとは思いますが、どちらかといえば上書き禁止という機能が重要かと。まだ先の話ですが、Podcastもアーカイブ機能をつける予定です。期間を過ぎても自動削除されない、とかそんなのを指定できるようにします。

今後の予定

このバージョンをリリースする前の想定では、Podcastの改修が予定されていました。現時点では3つの選択肢がテーブルにのってます。優先順位はこの順番になるかなーと。

  • SpringBootのメジャーバージョンアップ
  • WebページやUPnPの改修
  • Podcastの改修

SpringBootというのはJpsonicにも使われているJavaの超有名フレームワークです。これ使えないとJava使えるとは言えない、くらいの基本ツールです。これをメジャーバージョンアップしないと依存ライブラリが更新できなくなってしまう等の不都合が発生してきます。不可避の作業です。滅多にあるわけではないのですが、Subsonicが使用していたのは1.x(あー嘘。確かSpring直)、Airsonicで2.x、Jpsonicで3.xの切り替え時期がやってきた、というところです。多分自動ではできないので、面倒な作業になるでしょう。やってしまえばJava21 + Spring3というイケイケなサーバになります。ユーザ的には特に恩恵はありません(ドヤア)
ライブラリとかこれからもちゃんとメンテされるのねー、とかそういった地味な部分で重要になります。

Podcastの改修は私の中では絶対やるタスクの一つです。私が使うから、というのもあるのですが、これを終わらせないとスキャンが完成しないのですね。Jpsonicではスキャンが8割方書き換えられていますけれども、残りの2割がPodcast、くらいの感覚です。Jpsonicでスキャンがマシになっている、というご評価が頂けるのであれば、Podcastも同水準の設計と実装になるはずです。

WebページやUPnPの改修は、メニューをカスタマイズできるようにして、既存のものを作り替えたり足りないものを足したりといった作業になります。上にもちらっと書きましたが、WebページでもID3形式で閲覧ができるようにする予定です。フォルダビューも刷新されます。

システムの設計的には、Podcastを優先すべきかなと思います。Podcastをダウンロード中にシャットダウンしてしまったら、というケースがまだ保証されていないためです。ただPodcastはWebページでの管理機能からバックグラウンド処理までほぼ別モノを作るみたいなカンジになるので、全体で数か月かかるんだろうなという気がしています。工程をどこかで分割できればいいですけれども。

そうしてしまうとWebページやUPnPの新機能的な部分に到達するのがだいぶ先の話になってしまうので、あまり面白くはないかなと。ですので今のところは、上に列挙したような順番で進めようかなと考えているところです。

コメントはまだありません

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

アップデート方法
Jpsonic ダウンロード(v112.1.1)

Jpsonicのダウンロードとコンパイルに関して記載しています。