MusicBeeからの再生履歴のサーバへの送信

データを眺めていて全体からは気づかなかったのであるが、最近、頻発するようになったせいか、データの抜けが目につくようになってきた。

日付データがNULL値で送信されてしまったり、同じトラックのデータが2回送信されたり（日付だけ前回分と今回分で違う）している。現象としては、再生が完了したトラックの情報が正確に取れていない、ということで間違いないようだった。

MusicBeeの自作プラグインの問題なので、コードを久しぶりに見直すことに。コンテクストメニューからの任意のトラックの強制データ送信は問題が無いので、再生完了時に該当トラックの情報を送信している箇所を見直す。


public void ReceiveNotification(string souceFileUrl, NotificationType type)
{
switch(type)
case NotificationType.PlayountersChanged:
…
break;
}
}


このcase文の中が該当部分になる。イベントの捕捉で、一番トラックの終了に「近い」時間というかタイミングで発生するのがこのイベントなので、これを変更する必要も考えもない。翌見ていると、完全にトラックの再生が終了する前にこのイベントが発生するのであるが（バッファリング終了のタイミングか？）、MusicBeeの最終再生日時は文字列型の上、分単位なので全く問題にならない。

これまで、送信するファイルのタグは、

mbApiInterface.NowPlaying_GetFileProperty(MetaDataType.TrackTitle);

の様に取得していた。現在再生中のファイルのタグを取得する、という書き方である。

これが、ゲームをしたり、バックグラウンドの処理でCPUが追いつかなくなったりしてきたのであろうか？イベントが発生した時のNowPlayingが次のトラックに変わってしまっていた、そのため、同じレコードが連続したように見えたり、未再生トラックを送信してしまった時には再生日時がNULLになってしまったのだと思われる。

問題は対象になるタグをどこから引っ張ってくるのか？であるが、答えは上のパラメータにあった。ReceiveNotificationの第一パラメータのsourceFileUrlを今まで捨ててしまっていたのであるが、これがイベントが発生した時の対象ファイルになる。このファイルからタグを取得すれば、正しい情報になった。現状は問題なく動作している。ファイルURLからのタグ取得はコンテクストメニューからの操作で行っていたので簡単であった。


mbApiInterface.Library_GetFileTag(sourceFileUrl, MetaDataType.TrackTitle);
mbApiInterface.Library_GetFileProperty(sourceFileUrl, FilePropertyType.LastPlayed);


これが今回の解決策になった。トラックタイトルと同様にアーティストとアルバムも取得している。しばらくは様子見であるが、動作している以上、これが解であると見て間違いないであろう。