FeatureCaching
Ampache Side
volmerk has updated his documentation since the last time I looked at it, and has some nice info that I didn’t know about.
Album Art
Nothing really to do server side for this
General
Every single data request has offset and limit options. Quoting the documentation:
All methods except the handshake can take an optional offset=XXX and limit=XXX. The limit determines the maximum number of results returned. The offset will tell Ampache where to start in the result set. For Example if there are 100 total results and you set the Offset to 50, and the limit to 50 Ampache will return results 50 – 100. The default limit is 5000. The default offset is 0.
This means when retrieving any lists from the server we can choose to recieve chunks of them. I’ll comment on the current Amdroid implementation in the next section.
Artists/Albums/Songs Requests
I found something very interesting for the request urls:
add (ISO 8601 Date Format assumed filter method is newer then specified date, however [START]/[END] can be specified to receive only results added between two dates)
update (ISO 8601 Date Format assumed filter method is newer then specified date, however [START]/[END] can be specified to receive only results updated between two dates)
With this I should be able to update a cached copy of songs/artists/albums on demand.
Difference between “add” and “update”:
Add is the time since the last add of songs to the database (each song has its own song add date)
Update is the time since the last update of the songs (each song has its own song update date)
[START]/[END] really means something like this:
2010-04-20/2010-04-28
Any official ISO 8601 date format should work. Just see the right hand column, any of the formats should work.
Things work as expected here, if the date range is too new, nothing will be returned (a very small XML file). Or if its too broad, all it up.
Playlists
Not much I can do here, there is a filter option available, but adding stuff like that, would make the GUI waaaay too complex (unless someone has some neat implementation ideas).
Amdroid Side
The hard part :P.
Current Implementation
Nothing :P
Seriously though, amdroid currently keeps a copy of the songs/album/tags/playlists if it has downloaded it in the current running session of amdroid. This is great, until Android decides to free amdroid from memory.
The song cache from the Media Player royally sucks. Just try playing a song nearly to the end then rewinding it to the beginning, ugh.
Potential Implementation
List Storage
I really don’t want to design a database for stuff like this. So it’ll probably be easiest if I make some adapters to use SQLite. Unfortunately I have almost no experience in this area. So I’ll have to do some learning (not a big problem).
Each type of information should have it’s own table, and seperate databases should be kept for each server in use (multi-server support is something I want for amdroid-h). It should also be possible to put settings into the tables (seperate); perhaps even profile like so that each server has it’s own set of settings.
When to Update
This is the hard part. We need to decide when to update the user’s lists from the server.
Currently my thinking is that when the user firsts goes to say the Artists list there will be a messge prompting them whether or not they want to sync the Artists list.
We do have some info that can be displayed (total number of artists, albums, etc.) to give the user some idea of how long it will take.
Another option for when to update would be to automatically start an update when the user starts browsing the respective list, just like it works now.
As for the actual updating, perhaps in chunks of 50 items (with songs that’s about 40 KB). Then the songs will immediately be added to the list, and the current offset location recorded. So that if the downloading stops, it can be resumed.
Now a few problems (is your head starting to hurt yet :P).
What happens if the server is updated or added to before the complete list is retrieved…I'm going to have see what the capabilities of SQLite are before I really can make an accurate judgement of what’s easy here.
With the add/update operations, the lists just need to be updated/merged.
Now, what about Clear operations…ugh. I'm really not sure on how this will be indicated. What we can do is when a song cannot be played (and the session is valid) remove the song from the database. That should work…
If the list already exists we should have 2 options for updating. One for a complete refresh. The second, just an update (add/update operations).
For the complete refresh (clear the database) it can be in the Settings page as it shouldn’t be required all that often.
Song Caching
There are a few forms of song caching that I want for Amdroid-h.
Pre-Cache Next Song
It’s really annoying to have to wait for your next song to play as you usually already know what the next song is going to be. The idea here is to start caching the next song once the current song has been completely cached say to 10% of the total song.
Unfortunately the Media Player object takes care of all of the caching atm (though it does have some other problems). So I want to build a song caching function directly into Amdroid-h that will then feed the song data into the Media Player object.
My idea is to have 1 specialized ring buffer:
- Fixed total size (defined in settings). Research will need to be done on how big we can make this.
- Up to 2 songs can be added to the buffer
- The starting/ending points of each song will be recorded
- After the buffer of the current song has finished downloading, the next song will start downloading if:
- a. There is still space left in the buffer
b. The song is 75% played
If the current song is larger than the available buffer size:
- a. Fill the buffer to the maximum
- b. Once the song has played up to 50% of the buffer start writing to the beginning parts of the song
c. Once the song has been played 75% and only 50% of the ring buffer is needed, start caching the next song
In the case of a song skip, just treat the buffer as it was the first song play.
- In the case of rewinding the song to the beginning and this part of the song has already be overwritten, stop the current caching, and play at the earliest point. Begin caching again once the caching conditions have been met again.
Local Song Cache
Rather than stream the music from your Ampache server all the time, it would be nice to have a local cache for songs you play often, or want to play when your server isn’t available. Then if Amdroid-h detects this local copy, it will play from there, rather than wasting your bandwidth on something you've already downloaded.
Rather than make things complicated and use the direct song download that is available with Ampache (what if the songs are FLAC, then this is worthless…), we’ll download the downsampled version, name the file like it is on the server and add it to a folder with the scheme: – . Then using the XML song information make sure the tags are properly set.
Now to play the song, all of the playable music on the Android device will be cached into a table by their tag information. Similar to that of the XML Song data being cached. Now when a song is played, a search will be done on the local cache of songs to see if one of them matches exactly by Artist, Album, Song Title, and Track Number. If all of these parameters match, the local song will be used instead of the server version.
The ring buffer will also be bypassed for this song. Once the song has played 75%, the next song will be checked whether or not it has a local copy. If it does, queue it up as the next song (ignoring the ring buffer). If the next song does not have a local copy, then start downloading it to the ring buffer.
Album Art Caching
While the album art isn’t that big, it does lag a bit downloading from the server. Rather than downloading the album art every time it is requested, we should store it locally as long as it is relevant:
- The current song is selected (i.e. playing or is paused)
- Do not delete the image if the next song (or previous) uses the same album art.
