JUST PLAYER2をベータ版として公開をはじめました。
ダウンロードは下記のURLからできます。
https://play.google.com/apps/testing/jp.co.kayo.android.localplayer
ただし、ダウンロードするためにはJUST PLAYERのUserGroupに登録されている必要があります。
登録は以下のサイトから申請できます。
https://groups.google.com/forum/#!forum/justplayer-user
現在、GoogleDrive,Dropbox,SDCard、MediaStoreに対応しています。
これからAmpacheに対応し、その後UIを整えていく予定です。
秋頃までににはなんとか正式リリースしたいとおもっていますが、、テストも山積みですので約束はできません。
Friday, June 20, 2014
Tuesday, June 17, 2014
Artist,Genres,Albumの画像作成中
ちょっと最近仕事が忙しくなって、こちらに手がつけられない状況が続いています。
それでも、数時間ぐらいは当てれるようにやっているのですが、牛歩というか、、
いまとりかかっているのは、MediaStoreの一覧表示処理です。
とりえず、先日一覧表示はできるようになったのですが、ジャンルやアーティスト、アルバムの画像がないものが多いです。
これを見えるようにしたい。
MediaScannerはアルバムアートに関しては、スキャン時にメディアファイルから取得してアルバム情報にアルバムアートのキャッシュのパスを設定しています。
この仕様は助かる反面、コンピレーション・アルバムみたいな複数のアルバムアートが存在する楽曲がある場合うまくありません。
コンピレーション・アルバムの名前で楽曲にタグが設定されているならまだいいのですが、そうでないものは、それぞれ一曲単位でアルバム情報が生成されてしまいます。
メディアストアにはフォルダ単位で情報を管理するものがないので、この部分はプレイリストでフォルダ単位で登録してもらえるとか救済処置があってもよいものですが、、
これはまぁ、仕方がないんだけど。
だけど、アーティスト等はそもそも画像をもっていないので、どうしようもないです。
なので、現状アーティスト、ジャンル、プレイリストは真っ黒です。
そこで、該当する楽曲から複数のアルバムアートを抜き出して２ｘ２程度の四角に敷き詰めるように画像を作成しようと苦労しています。
とりあえず、画像を合体するだけならなんとかできるようになりました。
だけど、処理速度が遅くいまいちイケてません。
なんとか、高速にできるように工夫しているところです。
それでも、数時間ぐらいは当てれるようにやっているのですが、牛歩というか、、
いまとりかかっているのは、MediaStoreの一覧表示処理です。
とりえず、先日一覧表示はできるようになったのですが、ジャンルやアーティスト、アルバムの画像がないものが多いです。
これを見えるようにしたい。
MediaScannerはアルバムアートに関しては、スキャン時にメディアファイルから取得してアルバム情報にアルバムアートのキャッシュのパスを設定しています。
この仕様は助かる反面、コンピレーション・アルバムみたいな複数のアルバムアートが存在する楽曲がある場合うまくありません。
コンピレーション・アルバムの名前で楽曲にタグが設定されているならまだいいのですが、そうでないものは、それぞれ一曲単位でアルバム情報が生成されてしまいます。
メディアストアにはフォルダ単位で情報を管理するものがないので、この部分はプレイリストでフォルダ単位で登録してもらえるとか救済処置があってもよいものですが、、
これはまぁ、仕方がないんだけど。
だけど、アーティスト等はそもそも画像をもっていないので、どうしようもないです。
なので、現状アーティスト、ジャンル、プレイリストは真っ黒です。
そこで、該当する楽曲から複数のアルバムアートを抜き出して２ｘ２程度の四角に敷き詰めるように画像を作成しようと苦労しています。
とりあえず、画像を合体するだけならなんとかできるようになりました。
だけど、処理速度が遅くいまいちイケてません。
なんとか、高速にできるように工夫しているところです。
Saturday, June 7, 2014
MediaStoreからの選択機能を追加
MediaStoreというのは、Andoridが管理している曲データベースです。
AndroidはSDカードを常に監視し、SDカードに曲が追加されたらその情報を拾い出し、Android上の曲データベースに追加します。
情報はインデックス化され、アルバム名、アーティスト名で検索が可能になります。
通常、Androidで音楽アプリをつくる場合はこのデータベース（MediaStore）を参照するのがもっとも手っ取り早いのですが、独自の仕様であるためメディアのフォーマットによって独自の情報があっても捨てられてしまうのが残念なところです。
旧作のJUSTPLAYERではこのMediaStoreをベースに実装をしているため、DropboxやAmpacheの情報を無理やり合わせていました、そのため面倒な問題もでてたので、JUST PLAYER2では、MediaStoreはあくまでひとつの選択肢とし、基本はそれぞれの曲情報を大事にする方針です。
そういう理由があって、MediaStoreからの曲選択の実装が遅れているのですが、次の実装がAmpacheになるので、Ampacheの実装でも共通するMediaStoreの実装をしてみました。
アルバム、ジャンル、アーティスト、メディアから曲選択ができるようになっています。
まだ作り込みが甘く、アルバムアートに関しても工夫がなく、処理に関してももたつくところもあり、階層表示なども考慮していないので使いにくいかもしれません。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060701.apk
AndroidはSDカードを常に監視し、SDカードに曲が追加されたらその情報を拾い出し、Android上の曲データベースに追加します。
情報はインデックス化され、アルバム名、アーティスト名で検索が可能になります。
通常、Androidで音楽アプリをつくる場合はこのデータベース（MediaStore）を参照するのがもっとも手っ取り早いのですが、独自の仕様であるためメディアのフォーマットによって独自の情報があっても捨てられてしまうのが残念なところです。
旧作のJUSTPLAYERではこのMediaStoreをベースに実装をしているため、DropboxやAmpacheの情報を無理やり合わせていました、そのため面倒な問題もでてたので、JUST PLAYER2では、MediaStoreはあくまでひとつの選択肢とし、基本はそれぞれの曲情報を大事にする方針です。
そういう理由があって、MediaStoreからの曲選択の実装が遅れているのですが、次の実装がAmpacheになるので、Ampacheの実装でも共通するMediaStoreの実装をしてみました。
アルバム、ジャンル、アーティスト、メディアから曲選択ができるようになっています。
まだ作り込みが甘く、アルバムアートに関しても工夫がなく、処理に関してももたつくところもあり、階層表示なども考慮していないので使いにくいかもしれません。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060701.apk
Friday, June 6, 2014
曲の追加、置き換えを追加してみました
MediaStoreの選択画面の実装に入る前に、プレイリストやフォルダを選択した際に、今の再生リストを全置き換えとなっているところを、「置き換え」、もしくは「追加」の選択ができるように変更しました。
これに伴い、一曲単位での追加も可能にしました。
けっこうリファクタリングが多くなったので、ここで一旦リリースします。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060601.apk
あと、UIまわりも見直し中です、NavigationDrawerのなかに設定とイコライザをいれました。
設定はまだ未実装だけど、イコライザは基本どこの画面からもいけるようになります。
だいぶ使い勝手がよくなってきてると思うんだけどどうですかね。
これに伴い、一曲単位での追加も可能にしました。
けっこうリファクタリングが多くなったので、ここで一旦リリースします。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060601.apk
あと、UIまわりも見直し中です、NavigationDrawerのなかに設定とイコライザをいれました。
設定はまだ未実装だけど、イコライザは基本どこの画面からもいけるようになります。
だいぶ使い勝手がよくなってきてると思うんだけどどうですかね。
Wednesday, June 4, 2014
「Wake lock not active」これが頻繁にでる
これなんででるのかなぁーと思いつつ、特に実害がないのでほっといてるんだけどやっぱり気持ち悪い
MediaPlayerを使用して、ギャップレス再生を実現しているのだけど、setDataSourceだけしているMediaPlayerにもWakeLock指定をしているのが原因なのかな？
とおもったので、試しにstartするタイミングでWakeLock指定をするように修正してみたのですが変化なし、
Lock周りの実装といったら、Service起動時にWakeLockを取得しているところがあるぐらいだけど、あれは過去の実装でも問題はなかった。
この処理は今回の実装からはいったのでこれが一番あやしい。
ためしにこれ外してみたんだけど、
それでもでる、なんだこれ？
ちなみに端末を変えたらでなくなりました。
機種依存なんかなぁ、気持ち悪い
java.lang.IllegalArgumentException: Wake lock not active
at com.android.server.power.PowerManagerService.updateWakeLockWorkSourceInternal(PowerManagerService.java:794)
at com.android.server.power.PowerManagerService.updateWakeLockWorkSource(PowerManagerService.java:780)
at com.android.server.power.PowerManagerService.updateWakeLockUids(PowerManagerService.java:761)
at android.os.IPowerManager$Stub.onTransact(IPowerManager.java:103)
at android.os.Binder.execTransact(Binder.java:404)
at dalvik.system.NativeStart.run(Native Method)
MediaPlayerを使用して、ギャップレス再生を実現しているのだけど、setDataSourceだけしているMediaPlayerにもWakeLock指定をしているのが原因なのかな？
とおもったので、試しにstartするタイミングでWakeLock指定をするように修正してみたのですが変化なし、
Lock周りの実装といったら、Service起動時にWakeLockを取得しているところがあるぐらいだけど、あれは過去の実装でも問題はなかった。
mMediaPlayer.setWakeMode(mMediaPlayerService.getApplicationContext(),
PowerManager.PARTIAL_WAKE_LOCK);
この処理は今回の実装からはいったのでこれが一番あやしい。
ためしにこれ外してみたんだけど、
それでもでる、なんだこれ？
ちなみに端末を変えたらでなくなりました。
機種依存なんかなぁ、気持ち悪い
Dropboxに対応してみました
GoogleDrive対応の延長になるのですが、Dropboxにも対応しました。
SDKが新しくなってたけど基本的な使い方は同じなので対応は簡単でした。
GoogleDriveと比較して、Dropboxのほうがレスポンス遅い気がします。
一度再生をしてしまえば早いのですが。。
あと、M3Uの対応で間違いがあったので修正をしておきました。
M3Uには#EXTINFという行があって、当初はこれは、ただのコメント的なものでフォーマットは決まりないのかとおもってたけど、
どうやらちゃんと決まりがあるようなので、安心してこの情報からタイトルとアーティスト名を取得するようにしました。
ローカルストレージの場合は、MediaStoreから取得するのでこれはみてないです。
だけど、GoogleDriveや、Dropboxの場合はここに設定をしておかないとファイル名がタイトルになってしまうのでできれば設定しておいたほうがよいでしょう。
Dropbox対応のAPKは下記からダウンロードできます。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060401.apk
SDKが新しくなってたけど基本的な使い方は同じなので対応は簡単でした。
GoogleDriveと比較して、Dropboxのほうがレスポンス遅い気がします。
一度再生をしてしまえば早いのですが。。
あと、M3Uの対応で間違いがあったので修正をしておきました。
M3Uには#EXTINFという行があって、当初はこれは、ただのコメント的なものでフォーマットは決まりないのかとおもってたけど、
どうやらちゃんと決まりがあるようなので、安心してこの情報からタイトルとアーティスト名を取得するようにしました。
ローカルストレージの場合は、MediaStoreから取得するのでこれはみてないです。
だけど、GoogleDriveや、Dropboxの場合はここに設定をしておかないとファイル名がタイトルになってしまうのでできれば設定しておいたほうがよいでしょう。
Dropbox対応のAPKは下記からダウンロードできます。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060401.apk
SDカード、GoogleDriveの曲選択画面をリファクタリング中
次はDropbox対応をする予定です。
そのためには、いまあるプログラムを流用しやすくするためクラスの設計の見直しをしなければなりません。
理想としては、ファイル選択系の画面、メディア選択系の画面で派生します。
SDカード、GoogleDriveはファイル選択系です。
この２つはローカル上のファイルか、ストリーミングのファイルの違いがありますので流用できる箇所はファイル選択画面のUI部分だけなのですが、
Dropboxの場合は、GoogleDriveにかなり近いため流用箇所が多くなります。
大きな違いとしては、GoogleDriveはファイルストリームの取得が専用のHttpRequest、HttpResponsを使うのに対し、Dropboxは標準のHttpアクセスをつかうことになる点でしょう。
だから、Dropbox対応が完了すれば、他のBox.Net、SkyDrive、OwnCloud等の対応はたやすくなるとおもいます。
なので、ファイル選択系の画面はDropboxで一旦終了する予定です。
その後は、メディア選択系の画面の実装になります。
こちらは実ファイルのフォルダの情報を公開はしてなく、アルバム、アーティスト、メディアのように各メディアの検索をサポートしているデータになります。
対象になるのはローカルのメディアストア、あとAmpacheですね。
Ampache対応をするのであれば避けては通れない実装になります。
作り込みも多いのでけっこう時間がかかるとおもいます。
あと地味ですが、曲の先送り、巻き戻しの指定でIndexに１をプラスして移動していましたが、今後、ストリーミングがキャッシュされていないメディアは除外するといったオプションを追加する予定ですので、１をプラスではなく次に大きい、あるいは次に小さいというような指定の仕方に変更しないといけないです。
地味だけど、SQLの組み立てが面倒くさくなるので面倒くさい実装になりそうです。
そのためには、いまあるプログラムを流用しやすくするためクラスの設計の見直しをしなければなりません。
理想としては、ファイル選択系の画面、メディア選択系の画面で派生します。
SDカード、GoogleDriveはファイル選択系です。
この２つはローカル上のファイルか、ストリーミングのファイルの違いがありますので流用できる箇所はファイル選択画面のUI部分だけなのですが、
Dropboxの場合は、GoogleDriveにかなり近いため流用箇所が多くなります。
大きな違いとしては、GoogleDriveはファイルストリームの取得が専用のHttpRequest、HttpResponsを使うのに対し、Dropboxは標準のHttpアクセスをつかうことになる点でしょう。
だから、Dropbox対応が完了すれば、他のBox.Net、SkyDrive、OwnCloud等の対応はたやすくなるとおもいます。
なので、ファイル選択系の画面はDropboxで一旦終了する予定です。
その後は、メディア選択系の画面の実装になります。
こちらは実ファイルのフォルダの情報を公開はしてなく、アルバム、アーティスト、メディアのように各メディアの検索をサポートしているデータになります。
対象になるのはローカルのメディアストア、あとAmpacheですね。
Ampache対応をするのであれば避けては通れない実装になります。
作り込みも多いのでけっこう時間がかかるとおもいます。
あと地味ですが、曲の先送り、巻き戻しの指定でIndexに１をプラスして移動していましたが、今後、ストリーミングがキャッシュされていないメディアは除外するといったオプションを追加する予定ですので、１をプラスではなく次に大きい、あるいは次に小さいというような指定の仕方に変更しないといけないです。
地味だけど、SQLの組み立てが面倒くさくなるので面倒くさい実装になりそうです。
Monday, June 2, 2014
GoogleDriveのRange指定がちゃんと動かないのはもしかして、、
長らくGoogleDrive上のファイルでRange指定をするとフリーズしてしまう問題で苦しんでいるのですが、問題の起きているファイルには特徴があることがわかりました。
まず、ファイルのサイズが大きすぎる件。
テストで使用しているファイルは再生時間が１時間以上のファイルです。
長いもので２時間超の音楽ファイルなのですが、これらのファイルはローカルでは正常に再生できています。
ストリーミング再生でもRange指定で簡単にシーク位置まで移動してくれるものとおもっていたのですが、どうやら、これWebサーバーによってはうまくいかないのかもしれないです。というのも、これDropboxやAmpacheでは経験してないんですよね。
ちなみに、フリーズしている箇所はGoogleDriveAPIのHttpRequestに対して、Executeを実行している箇所です。
Range指定をした場合は、ときどきこの場所でフリーズするんです。
うまくいく場合もあります。これが謎、なのですが。
うまくいく場合は、一発目に限るです。
一度再生用のストリーミング処理をしている最中に、Range指定をするとフリーズします。
この流れですが、MediaPlayerによって再生中のコネクションを切断するのは、Range指定されたリクエストが発行された後のようなので、これが問題になっているのかもしれません。
あと、プログラム側でも考慮するべき箇所がありました。
JUST PLAYERでは状況を把握するために定期的に isPlaying や getCurrentPosition、 seekToなどを行っています。
これ、Prepareされるまえに呼ばれる可能性がありました。
さすがに seekToはなさそうですが、 isPlayingや getCurrentPositionなどは状況をチェックする際に呼ばれます、この処理のためにRange指定のリクエストがどうやら動いているようなんですね。
てことは、頻繁にリクエストが発生すると、GoogleDriveは短い時間の間に何度もリクエストがくるとエラーを返すようなので、これはまずい感じがします。
ですので、とりあえずPrepareが終わってない場合は０なりFalseを返すなりの処理にしておきました。
このような処理をすることで少しは動作が安定したようにみえます、曲の選択でも簡単にフリーズしていたけど今はそれほど問題はおきていません。
もちろん、長いファイルの曲の移動では問題がおきていますので、これは今後の課題になりそうです。
下記のリンクは現時点の最新モジュールです。
シャッフルのロジックの修正、上記問題の修正、MimeType読み込みの修正、MinSDKを１４にするといった修正がはいっています。
あと、共有ドライブの機能は動作が確認できたので一旦無効にしています。
（共有ドライブのリスティングが遅いので、テストだとイライラするため、これは将来オプションですね。）
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060201.apk
＃口調が砕けてきて読みにくい文章になりつつあります。すみませーん。
まず、ファイルのサイズが大きすぎる件。
テストで使用しているファイルは再生時間が１時間以上のファイルです。
長いもので２時間超の音楽ファイルなのですが、これらのファイルはローカルでは正常に再生できています。
ストリーミング再生でもRange指定で簡単にシーク位置まで移動してくれるものとおもっていたのですが、どうやら、これWebサーバーによってはうまくいかないのかもしれないです。というのも、これDropboxやAmpacheでは経験してないんですよね。
ちなみに、フリーズしている箇所はGoogleDriveAPIのHttpRequestに対して、Executeを実行している箇所です。
Range指定をした場合は、ときどきこの場所でフリーズするんです。
うまくいく場合もあります。これが謎、なのですが。
うまくいく場合は、一発目に限るです。
一度再生用のストリーミング処理をしている最中に、Range指定をするとフリーズします。
この流れですが、MediaPlayerによって再生中のコネクションを切断するのは、Range指定されたリクエストが発行された後のようなので、これが問題になっているのかもしれません。
あと、プログラム側でも考慮するべき箇所がありました。
JUST PLAYERでは状況を把握するために定期的に isPlaying や getCurrentPosition、 seekToなどを行っています。
これ、Prepareされるまえに呼ばれる可能性がありました。
さすがに seekToはなさそうですが、 isPlayingや getCurrentPositionなどは状況をチェックする際に呼ばれます、この処理のためにRange指定のリクエストがどうやら動いているようなんですね。
てことは、頻繁にリクエストが発生すると、GoogleDriveは短い時間の間に何度もリクエストがくるとエラーを返すようなので、これはまずい感じがします。
ですので、とりあえずPrepareが終わってない場合は０なりFalseを返すなりの処理にしておきました。
このような処理をすることで少しは動作が安定したようにみえます、曲の選択でも簡単にフリーズしていたけど今はそれほど問題はおきていません。
もちろん、長いファイルの曲の移動では問題がおきていますので、これは今後の課題になりそうです。
下記のリンクは現時点の最新モジュールです。
シャッフルのロジックの修正、上記問題の修正、MimeType読み込みの修正、MinSDKを１４にするといった修正がはいっています。
あと、共有ドライブの機能は動作が確認できたので一旦無効にしています。
（共有ドライブのリスティングが遅いので、テストだとイライラするため、これは将来オプションですね。）
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060201.apk
＃口調が砕けてきて読みにくい文章になりつつあります。すみませーん。
Android アプリのクライアント ID登録の罠に注意
今開発で使っているのはRatinaMacBookProなんだけど、
最近調子悪くて、USBの認識がブツブツ切れてイライラしたり、ときどきスタンバイからの復帰で電源ボタンしかきかずキーボード、トラックバッドが無反応になったりと、
まるで明日開催されるWWDCで新しいMacbookが発売されたらそれを買えとプレッシャーかけてきてる雰囲気を感じています。
今日だってあんまりにもひどいから、古いMacBookAirを掘り出して開発をしているんですが、コーディングをしていざテストをしようとしたら、GoogleDriveの認証がうまくうごかない。
あれぇー先日修正したのになんで、、
もしかして、２段階認証はうまくいくようになったけど、１段階のは逆にだめになったのかなぁーと疑っていたのだけど、ログをみても怪しいところはない。
よーく考えてみて、APIConsoleをみてみたら、この開発PCのAPIキーが登録されていない？
これ先日登録した気がすんだけど気のせいかなぁーと再度登録してみたらエラーがでてきました。
実は今登録されているAPIキーはRatinaのデバッグ用のキーストアで登録をしているのですが、同じパッケージに対してキーストアは一個しか認められないみたいなので、、このPCのキーストアの登録はエラーになっていたようです。
登録できていたというのは僕の見間違いのよう。
てことは、KeyStoreなくしたら最悪ですね、、チームで開発するときにも気をつけないといけないでしょう。
PCを買い換えるときにもDebugキーストアもちゃーんともってこないとテストで苦労するっていうことを知りました。
新しいRatinaMacBookProはよこい。
最近調子悪くて、USBの認識がブツブツ切れてイライラしたり、ときどきスタンバイからの復帰で電源ボタンしかきかずキーボード、トラックバッドが無反応になったりと、
まるで明日開催されるWWDCで新しいMacbookが発売されたらそれを買えとプレッシャーかけてきてる雰囲気を感じています。
今日だってあんまりにもひどいから、古いMacBookAirを掘り出して開発をしているんですが、コーディングをしていざテストをしようとしたら、GoogleDriveの認証がうまくうごかない。
あれぇー先日修正したのになんで、、
もしかして、２段階認証はうまくいくようになったけど、１段階のは逆にだめになったのかなぁーと疑っていたのだけど、ログをみても怪しいところはない。
よーく考えてみて、APIConsoleをみてみたら、この開発PCのAPIキーが登録されていない？
これ先日登録した気がすんだけど気のせいかなぁーと再度登録してみたらエラーがでてきました。
実は今登録されているAPIキーはRatinaのデバッグ用のキーストアで登録をしているのですが、同じパッケージに対してキーストアは一個しか認められないみたいなので、、このPCのキーストアの登録はエラーになっていたようです。
登録できていたというのは僕の見間違いのよう。
てことは、KeyStoreなくしたら最悪ですね、、チームで開発するときにも気をつけないといけないでしょう。
PCを買い換えるときにもDebugキーストアもちゃーんともってこないとテストで苦労するっていうことを知りました。
新しいRatinaMacBookProはよこい。
Sunday, June 1, 2014
GoogleDriveのRange指定が倒せない。
GoogleDriveには、OwnFileとShareFileの二種類へのアクセスがあります。
通常のファイルアクセスではOwnFileだけなのですが、検索条件にsharedWithMeをつけるとShareファイルも検索結果に現れます。
こうして取得したファイルはどちらも同じような扱いができるのかと思っていたのですが、なんとなくしっくりきていないです。
理由は、sharedWithMeで取得したファイルのフォルダ一覧取得では、特定の拡張子のファイルのMimeTypeがOwnFileのフォルダとは違ったり、リクエストに対するレスポンスのやりとりが違ったりなんだかよくわからないです。
今嵌っているのは、そういう問題によってRange指定したリクエストが突然切断されまた、場合よってはフリーズすることがある不具合です。
これを解決しない限りリリースは先になってしまいそうなんですが、うまい回避方法がないものか。
とりあえず、GoogleDrive上におかれたプレイリストに対応しました。
プレイリストは m3u とCueファイルになります。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060101.apk
通常のファイルアクセスではOwnFileだけなのですが、検索条件にsharedWithMeをつけるとShareファイルも検索結果に現れます。
こうして取得したファイルはどちらも同じような扱いができるのかと思っていたのですが、なんとなくしっくりきていないです。
理由は、sharedWithMeで取得したファイルのフォルダ一覧取得では、特定の拡張子のファイルのMimeTypeがOwnFileのフォルダとは違ったり、リクエストに対するレスポンスのやりとりが違ったりなんだかよくわからないです。
今嵌っているのは、そういう問題によってRange指定したリクエストが突然切断されまた、場合よってはフリーズすることがある不具合です。
これを解決しない限りリリースは先になってしまいそうなんですが、うまい回避方法がないものか。
とりあえず、GoogleDrive上におかれたプレイリストに対応しました。
プレイリストは m3u とCueファイルになります。
https://bitbucket.org/yokmama/just-player/downloads/JUSTPLAYER3_v1.0_060101.apk
Subscribe to:
Posts (Atom)