Runtime Database (planned), to store all runtime info.
To be able to provide a proper playlist-creating interface:
"create me a playlist of all rocksongs of the 80's and 90's, that last longer than 3 minutes, that have been played at least 5 times"
How its supposed to work
The runtimedatabase has a static size, and a record for every song in the tagdatabase. you can get the rundb record of a song by calculating its song record number in the tagdb (its the 768th song in the tagdb, for example), and then take the rundb record with the same record number (768th rundb record)
In the same way, you can get a tagdb record of a song by taking its rundb record number.
Files that are not in the tag database can not have runtime data.
Also, i want to propose some sort of time-passed thing in order to be able to keep track of when a song was last played.
we could simply keep track of the passed time, write it to the rockbox config on shutdown, and read it back on bootup, to keep track of the total amount of passed time. We would then be able to use that standard of passed time to implement "Recently played songs" and "Least recently played songs"
Stuff that would need to be in the TagDatabase before we'll be able to do nice searches (imho)
Length of a song (milliseconds)
Year of the track
| Magic || 4 || "RRD#" where # is the database version, 0x01 |
| Dirty || 1 || 1 if RuntimeDatabase needs to be synchronized with tagdb, 0 if runtimedatabase is okay. |
| records || 4 || Amount of Records in the database (Unneeded data, but whatever, must be the same as the amount of songs in the tagdb) |
| Hash || 4 || Hash (CRC ? md5? prolly crc..) of the first ? bytes of a song with offset ? (needs to be decided upon) |
| Rating || 1 || Track Rating |
| Play Count || 4 || Play count of the track. |
| Last time played || 4 || Last time this track was played, probably in some relative format. |
| Volume adjustment || 2 || Volume adjustment, applied to track on playback |
# amount of Rundb Records
If two files with the same hash exist on the filesystem, what will happen during a runtime database sync?
you could say those files should have the same runtime info, but our current format does not allow that, it
forces runtime info for every song in the tag database....
Please add any suggestions on this...
MichielVanDerKolk: what we could do is add a field to the runtime db that says "no, the runtime info for this file isn't stored here, its there! *points*" for duplicate hashes... (assuming the hash is good enough to not produce duplicates of files that aren't actually a copy on disk) however, this would create problems when looking up tagdb info if you have a runtimedb entry.
Copyright © by the contributing authors.