キャッシュデータの状態を表示するようにしました。
といってもアイコンがまだなので、いまのところ文字です。
SD:ストレージデータ
CD:クラウドデータ
1−100:作成状態のパーセンテージ
それと、アルバムアートのクイック検索機能を追加しました。
右上の検索ボタンをおすと、タイトル名、アーティスト名から該当するカバーアートを設定します。
あともうひとつ、けっこう以前から実装していたのですが、報告し忘れていました。
設定画面から、例外のレポートを送ることができます。
アプリが落ちたあとに、やると落ちたときの例外メッセージを添付できるので、なにか問題があったときはこれを使っていただけると助かります。
Monday, September 15, 2014
Sunday, September 14, 2014
ストリーミング再生と、次の曲のキャッシュ作成のパスを分けてみた
いろいろ工夫してみたけど、ストリーミング再生用のデータ取得処理と、次の曲のキャッシュ作成を同じような作りでやっているのは無理がでてきたので、大きな修正になるけど別々の処理として行うように変更してみました。
Boxにかぎらず、ほとんどのクラウドサービースはダウンロードをしないでずっと止まっていると、ネットワークが切断されたと勘違いして接続を切断してきます。
ストリーミング処理の場合、とくに音楽再生の場合再生するバッファだけクライアントが取得したら次の取得は、必要になるまで開始されません。
Androidの端末によっては、このバッファの取得サイズが違うようで、たくさんとるものや少ないものもあるように思います。(ここは憶測です)
問題はこの大きいバッファの場合で、この場合長い間通信が止まった状態になっているのだとおもいます。
今回特に問題になっているのは、次の曲の再生処理です。
今までは、曲の切り替わりを素早くするために、次の曲を事前に読み込んでおく処理をいれていました。
しかし、これをMediaPlayerにまかせていたため、再生されない状態でずっとほっとかれるため、バッファの読込処理もずっと止まった状態になります。
これが、次の曲の読込で失敗する原因です。
一つ前の修正でひとまずMediaPlayerにまかせっきりで処理をしていた部分を自分で行うように変更してみました。
これで、ある程度解決できたのかなとおもっていたのですが、まだ失敗する場合があるようなので、さらに原因を調べてみていたのですが、、ここまでずっと修正修正ときていたので、問題の箇所のコードが難しくなりすぎ、理解しずらくなっていました。
なので、ここは思い切ってリファクタリングをすることにし、処理を別々に分けることにしました。
ということで、今回の修正はプログラムを最適化したリリースになります。
ダウンロード専用のコードを書いたので、前より早くなっていると思います。
今回の修正でダウンロードの事前処理を容易に行えるようになったので、長らくほったらかしになっていた、「デバイスに保存」機能の実装にとりかかろうかと思います。ついでにダウンロード中か、どうかのステータス表示もいれます。(だけどアイコンで悩み中、、)
Friday, September 12, 2014
Boxのファイルを連続再生していて途中で止まる現象に悩む
Boxの再生について前回の修正でだいぶましになったと思っていたのですが、やっぱり途中で止まる不具合が発生しています。
しかもとまるだけじゃなく、延々とリトライをする始末。
どうして、このような事がおきるのかというと、Boxにファイルをダウンロードリクエストすると、途中で失敗するケースがあるので、続きは途中からのリクエストを作成するようにする必要があります。(ここは前回の修正の範囲)
だけど、これだけでもまだ問題があるようで、途中からのリクエストをした場合には途中からのリクエストを返しました、とBoxから返事がくるはずなのですが、なにを勘違いしたのか、特定のファイルでは最初からダウンロードを要求したのと同じ結果をかえしてくる場合があります。
そのため、こちらは混乱してしまいます。
最初からのデータを返してくるというのなら、それなりに正常系の処理として対処の使用があるものの、ヘッダ情報だけはいっていて中身がありません。
それで、データのチェックの際、上記でおかしな点がみつかりエラー処理をするのですが、今度はMediaPlayerがそれに納得いかないのか、もう一回、もう一回と再リクエストをしてしまい、ずっと読み込み中の画像がでてくる状態になっています。
この問題について、手元のバージョンでは強制的にMediaPlayer側に停止をするようにプログラムで回避する修正をしました。
といってもMediaPlayerが諦めてくれるまでに30秒ぐらいはかかる感じです。
しかもとまるだけじゃなく、延々とリトライをする始末。
どうして、このような事がおきるのかというと、Boxにファイルをダウンロードリクエストすると、途中で失敗するケースがあるので、続きは途中からのリクエストを作成するようにする必要があります。(ここは前回の修正の範囲)
だけど、これだけでもまだ問題があるようで、途中からのリクエストをした場合には途中からのリクエストを返しました、とBoxから返事がくるはずなのですが、なにを勘違いしたのか、特定のファイルでは最初からダウンロードを要求したのと同じ結果をかえしてくる場合があります。
そのため、こちらは混乱してしまいます。
最初からのデータを返してくるというのなら、それなりに正常系の処理として対処の使用があるものの、ヘッダ情報だけはいっていて中身がありません。
それで、データのチェックの際、上記でおかしな点がみつかりエラー処理をするのですが、今度はMediaPlayerがそれに納得いかないのか、もう一回、もう一回と再リクエストをしてしまい、ずっと読み込み中の画像がでてくる状態になっています。
この問題について、手元のバージョンでは強制的にMediaPlayer側に停止をするようにプログラムで回避する修正をしました。
といってもMediaPlayerが諦めてくれるまでに30秒ぐらいはかかる感じです。
Thursday, September 11, 2014
イコライザを修正しました
イコライザで未実装だった箇所を実装し、UIを見直しました。
画像はひとまず適当なものを当てているので見た目は地味なかんじです。
正式リリースまでには良いものに変更したいと思っています。
画像はひとまず適当なものを当てているので見た目は地味なかんじです。
正式リリースまでには良いものに変更したいと思っています。
Wednesday, September 10, 2014
あー、いろいろバグいれこんでしまってるみたい
とりあえず既知のバグとして
・SDカード内の音楽の再生で次の曲にいくときに停止してします。
・キャッシュが作成された音楽なのに先読みが実施されてなくReplayGapが効果してない。
あと他にもあったら追記しておきます。
次のリリースで修正されます。内容が内容だけに次のリリースは早めになるとおもいます。
・SDカード内の音楽の再生で次の曲にいくときに停止してします。
・キャッシュが作成された音楽なのに先読みが実施されてなくReplayGapが効果してない。
あと他にもあったら追記しておきます。
次のリリースで修正されます。内容が内容だけに次のリリースは早めになるとおもいます。
Tuesday, September 9, 2014
ブックマーク機能をひとまず実装してみました。
えーと、ブックマークというのは任意の音楽のある一部分をブックマークし、曲のように扱う機能のことです。
ブックマークというのが妥当な名前なのかどうかは分かりませんが、他にこのような機能を持っているアプリがないので、分かりやすい言葉がしっくりくるだろうとこの言葉にしました。
ブックマークというのが妥当な名前なのかどうかは分かりませんが、他にこのような機能を持っているアプリがないので、分かりやすい言葉がしっくりくるだろうとこの言葉にしました。
クライアントのバッファリング処理の実装を見直してます。
BoxのAPIを更新してから頻繁にコネクションが切れる現象に悩まされています。
切れるだけならまだしも、何度か失敗するとAudioManagerがハングアップして音が一切ならなくなる不具合に見舞われてるのでかなり問題。
原因はなんなのかなぁーといろいろコードを見なおしてみてるけど、よくわからなかったのですが、もしかしたら、という仮説を考えています。
その仮説というのは、MediaPlayerのバッファリングがいつまでたってもReadしてくれないのでサーバーがコネクションロストと判断して切断してるんじゃないのかなということです。
理由は、だいたい決まって30秒程度で失敗しているのとStackTraceのエラー内容から、、
MediaPlayerは再生分よりも多めにバッファリングしてますが、ある程度再生しないと次のバッファを読み込もうとしません。だからかなぁ、、
対応策として、ダウンロードのラインとMediaPlayerに供給するラインを別々にすることだとおもうので、ちょっと試しにこの実装をいれようかなとおもってます。
というわけで、次のバグ修正版のリリースが遅れると思います。
明日作業を見積もって長くかかりそうだったら、一旦現時点でバグを潰したバージョンをリリースします。
切れるだけならまだしも、何度か失敗するとAudioManagerがハングアップして音が一切ならなくなる不具合に見舞われてるのでかなり問題。
原因はなんなのかなぁーといろいろコードを見なおしてみてるけど、よくわからなかったのですが、もしかしたら、という仮説を考えています。
その仮説というのは、MediaPlayerのバッファリングがいつまでたってもReadしてくれないのでサーバーがコネクションロストと判断して切断してるんじゃないのかなということです。
理由は、だいたい決まって30秒程度で失敗しているのとStackTraceのエラー内容から、、
MediaPlayerは再生分よりも多めにバッファリングしてますが、ある程度再生しないと次のバッファを読み込もうとしません。だからかなぁ、、
対応策として、ダウンロードのラインとMediaPlayerに供給するラインを別々にすることだとおもうので、ちょっと試しにこの実装をいれようかなとおもってます。
というわけで、次のバグ修正版のリリースが遅れると思います。
明日作業を見積もって長くかかりそうだったら、一旦現時点でバグを潰したバージョンをリリースします。
Subscribe to:
Posts (Atom)
