asjdy6dkf9dfd6


以前、こちらでお伝えしたバッテリーの以上消費の原因にもなっているメディアサーバーの暴走についてですが、どうやらこの記事で紹介した原因以外にも(というかこれら以上に)怪しい容疑者が浮上しました。

ずばり、新」最重要参考人はm4aファイルっぽいです。

別の調べ物をしていてたまたま見つけたこの投稿なのですが、要約&意訳をすると:
ICSのリリース以来、メディアサーバーがバッテリー消費の50-60%を閉める状況が続いていましたが、原因はm4aスキャナー/デコーダーにあったようです。

m4aはmp3とは違うアルゴリズムを使用するため、スキャンとデコーディングは別々に行われます。
私の場合、内部ストレージのファイスブックの通知音がスキャンで引っかかり、他のメディアファイルをブロックしていたようです。

また、他のm4aファイルも同様に問題を起こしていたようですが、いずれもファイルが破損していたわけではありませんでした。どうやら、m4aファイルはmp3ファイルよりも優先的にスキャンをされるようで、これが障害を起こす傾向があるようです。

つまり、m4aそのものに原因があるということではなく、それをスキャニング、もしくはデコーディングするプロセスで何らかのエラーが起き、暴走の原因となっているようです。

また、この投稿をされた方によると、改善方法は:

①PCなどにバックアップを取った上で、通知音などを含む、すべてのm4aファイルを端末上から削除。 
AACファイルもm4aなので、同様に削除。

②削除したm4aファイルを一つずつ戻し、その度にバッテリー状況をチェック。もしメディアサーバーが50%以上のバッテリー消費をしているようならば、そのファイルが原因である可能性大。

③もし、削除したm4aファイルが原因でない場合は、mp3、wav、aiffなど、全てのオーディオファイルを削除。mp3についてはリペアソフトを使ってチェックをし、問題があった場合は修復。


これ、人によっては恐ろしく手間と時間がかかる作業になります。
また、m4aファイルは元から端末に入っている通知音などである可能性もありますので、その辺は自己責任でお願いします。

また、同じソースを見た方かもしれませんが、価格.comでも同様の指摘をされている方がいました。これら全てを試しても改善しない場合は動画もしくは画像ファイルに問題がある可能性もあるようです。
実際に、価格.comではFLVファイルが原因となっていたケースも報告されており、m4aだけが原因とは限らないようです。

もちろん、前回の記事でお伝えした原因である可能性もありますが、直感的にこちらのm4aの方が可能性は高いような気がします。

ちなみにこれらは早いものでは去年の4月の時点で出ていた情報です。
私が完全に見落としていました。お恥ずかしい限りです・・・

WindowsユーザーでもiTuneなどを使用している方は、結構このm4a形式で音楽をダウンロード、保存している方も多いようなので、この問題にお悩みの方は時間のある時にでも徐々にでもテストをするこことをお勧めします。