I'm not sure what the implications are of removing the shared_prefs directory. If all you are doing is testing codecs, it is probably benign.
On Feb 10, 10:03 am, chrisk <[email protected]> wrote: > Thanks Dave, I will try this. > > In the meantime, I am able to workaround this by clearing the previous > state of Music app by clearing the app data under the Settings app- > > >Applications->Manage Applications->Music->Clear Data > > I have found that this simply deletes the /data/data/com.android.music/ > shared_prefs/Music.xml file. > <?xml version='1.0' encoding='utf-8' standalone='yes' ?> > <map> > <int name="curpos" value="5" /> > <long name="seekpos" value="0" /> > <int name="shufflemode" value="0" /> > <int name="repeatmode" value="0" /> > </map> > > This allows me to reboot with a clean enviroment for Music app. Can > you think of any detriment in doing this? > Also, I have added a one shot service in my init.rc to rm the > shared_prefs directory. Is there any larger impact in doing this? > This is only meant to be a short term workaround while the codecs are > under test/development. > > Thanks for the feedback! > > On Feb 10, 1:34 am, Dave Sparks <[email protected]> wrote: > > > You can simulate this behavior under a test program by the following > > sequence: > > > MediaPlayer mp = MediaPlayer.create(); > > mp.setDataSource(path_to_test_file"); > > mp.prepare(); > > mp.seekTo(offset_in_msecs); > > > It could be that the OMX h/w decoder isn't getting all the > > configuration data it needs under these circumstances. We don't > > currently have an AAC h/w decoder to test it internally, the G1 is > > using the OpenCore software codecs. > > > On Feb 9, 6:59 pm, chrisk <[email protected]> wrote: > > > > Yes, I am seeing a problem. When resuming a session, the OMX component > > > will need to be re-loaded and > > > configured correctly again. With AAC, for example, opencore will send > > > a config buffer at the beginning of the file. > > > Does the config buffer get sent again? > > > > I think for my debugging purposes, you have already given me the info > > > I need to work with. Resuming this playback > > > after rebooting the device is essentially the same as starting a new > > > decode session (loaded->idle->executing for OMX) > > > but starting from the saved location in the file. > > > > I am not sure how opencore handles the reposition required for this to > > > work consistently. > > > Perhaps, the same port parameter negotiation is done again and all > > > needed config buffers > > > are sent again to the OMX component? I can verify this easily enough. > > > > I do know that a the typical ff/rewind type of reposition works well, > > > so I am not sure what the difference is > > > when doing a reposition immediately if trying to resume a previously > > > terminated session. > > > > On Feb 9, 4:33 pm, Marco Nelissen <[email protected]> wrote: > > > > > On Mon, Feb 9, 2009 at 1:06 PM, Chris Kelly <[email protected]> wrote: > > > > > I have noticed that when booting up after this has happened, then > > > > > navigate > > > > > to Music player application, the previous session (song and song > > > > > location on > > > > > progress bar) are restored. I assume this is done by some entry in > > > > > /data? If > > > > > The music app stores its state in a SharedPreferences and restores it > > > > from there. > > > > > > the app was killed to free resources after a pause, then why would > > > > > this > > > > > playback session data need to be stored. > > > > > I don't understand what you're asking. The music app restores its > > > > previous state so that, from the point of view of the user, it looks > > > > like it's always there, even if it got killed while the user wasn't > > > > using it, or after restarting the phone. > > > > > > It seems that the OMX/opencore implementation does not like to start a > > > > > decode session in the middle of a file. > > > > > All the music app does when it restores its state is to open the file > > > > for playback and then seek to the saved position. > > > > Are you seeing any problems with that? Does it happen with any > > > > particular file or file type? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
