普段はあまり気にしていなかったのですが、先日に foobar2000 本体やコンポーネントをアップデートした際に異様に起動が遅い…foobar2000 をインストールしたディレクトリを覗いてみると custominfo_sqlite.db のサイズが 6MB 超えている…
なんでだろうと思い、一旦 foobar2000 を終了し SQLite Database Browser にて custominfo_sqlite.db の中を見てみると、同じ曲の fieldname が PLAYED_TIMESTAMP のレコードがやたらとできてる…多分コレのせいでしょう…
Preferences › Playback Statistics Custom › Playback Statistics Custom Settings の Play Stamp をチェックしていると Playback Statistics Update Timing に合致する度にレコードが挿入されてしまう。要はコレは再生履歴なんですが、foobar2000 じゃこのデータを使う手段や使い道がないのでチェックオフにしておく
で、PLAYED_TIMESTAMP フィールドは UI の中でも使用していないので、このレコードを削除する事にします。SQLite Database Browser で行ってもいいんですが、PHP で以下のような簡易ダイエットスクリプトを作成して実行
- <?php
- $dbf = './custominfo_sqlite.db';
- $dbh = new PDO( 'sqlite:'.$dbf );
- $stmt = $dbh->query( 'DELETE FROM quicktag WHERE fieldname = "PLAYED_TIMESTAMP"' );
- echo 'row count: '.$stmt->rowCount()."\n";
- echo 'error code: '.$stmt->errorCode()."\n";
- $stmt = $dbh->query( 'VACUUM' );
- echo 'error code: '.$stmt->errorCode()."\n";
- ?>
上記スクリプトを実行する事によって、約 25000 レコードが削除され、6.02MB だったファイルが 1.19MB までに小さくなりました。小さくなった custominfo_sqlite.db を foobar2000 のディレクトリに戻し、起動…サックリ起動するようになりました
使用しているフィールド PLAY_COUNT, FIRST_PLAYED_TIMESTAMP, LAST_PLAYED_TIMESTAMP が UI 側で正常に表示される事を確認して終了です
この記事は foo_custominfo で保存先を SQLite database に設定している事を対象としています。 foo_custominfo(foo_custominfo.dll) と Playback Statistics Custom(foo_playback_custom.dll) を 使っていると、データベースがだんだんと大きくなって、foobar2000 のバージョンアップや 音楽ファイルの移動などでデータベースのメインテナンスが必要となってきますが、 ここではそのデータベースの簡単な保守の方法をメモとして書いておきます
データベースのファイルは foobar2000 のディレクトリの中に custominfo_sqlite.db というファイルがあります。 これを別の場所等にコピーしてバックしておきます。で、このデータベースを操作する為に SQLite Database Browser なるものをダウンロード、解凍します。 SQLite Database Browser を実行して Open Database にて custominfo_sqlite.db を開きます
File メニューから Export > Table as CSV file を実行すると CSV 形式のテキストファイルが生成されるので、 テキストエディタを使用して編集し、同じ様に File メニューから Import > Table from CSV file を 実行するとデータベースに反映されます
custominfo_sqlite.db を定期的にバックアップを取っておけば、大量の音楽ファイルの移動や foobar2000 設定構築の際に Export した CSV ファイルを編集、Import を行えば、レイティング、再生回数などの情報が引き継げます