Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The Plugin API has a separate page.
Smaller, Nearer-Term Changes
- Remove or fix mb_artist_id tagging (which currently arbitrarily picks the first credit). A user mentioned that other taggers (Jaikoz and MediaMonkey) fill this field with a null-separated list of IDs, which seems much more useful.
- Shrink the interface size of the metadata backend API by unifying ID lookups with string-based lookups. Currently,
beets.autotag.hookshas four functions per that abstract DB lookups:
_item_candidates. It would be nice to collapse this into just two functions, especially as we look at adding new (non-MB) backends via a plugin API.
Larger Things That Should Happen Soon
- Resolve some strange behavior w.r.t. album-level fields and the update command. When there's an item with an inconsistent item-level field (i.e., two different items in the album have different values for the same album-level field) that is not written by the autotagger, it will get clobbered back to the uniform value even after
beet update. The effect is that just importing and then immediately running
updateshows changes! That's confusing. The importer should probably enforce that all album-level fields are uniform.
- Strict typing and coercions for
library.pyshould specify the desired Python type of each
Itemfield; when setting an attribute, the value should be converted to the given type (e.g., the string
Falsewhen assigned). This will, for instance, make the
modifycommand work correctly for non-string fields (see #323). Additionally, this will put an end to confusing None values, which would be coerced to a "null" value of the appropriate type, solving some weirdness with the
updatecommand. Currently, we're being saved by SQLite's weak typing, which does these coercions for us.
- Find a way to simplify the user prompts in the importer. They're currently running the risk of becoming "alphabet soup" from the point of view of the user: the increasing number of choices has made it less obvious what should be done at each step.
- Asynchronous import decisions. This is an idea due to martian on IRC. When importing, don't necessarily force a user's decision immediately. Importing is a multi-step process: add to library, look up in MB, make decisions, and copy/write files. This way, a fast process could index everything and then decisions could be made offline. Possibly using an alternate interface, maybe a GUI.
- Experiment with a NoSQL-style database. Two good candidates include sqlitedict and sqlite3dbm (or, eventually, a LeveDB binding).
- Experiment with adopting an ORM (SQLAlchemy?) to simplify the library code while maintaining our current schema.
- use some of the newer assertions available in py 2.7 unittest
Clone this wiki locally
Press h to open a hovercard with more details.