Better management of CD-R entries in library

[bufordsharkley]

I've been paranoid about this for a while, but we've unfortunately not done much on it:

CD-Rs are especially prone to bitrot, have surprisingly short lifetimes, and yet are making up an ever-increasing percentage of what we have in the library

At present, we have "Media" = CD represent all CDs in our system, when really we probably should have something more akin to:

• CD (unknown provenance) -- what "CD" represents now, can probably be just "CD"
• CD (officially pressed) -- real CDs with more resilience against bitrot, better name probably needed
• CD-R

And ideally, we probably would benefit from a field for CD-Rs to track when last burned, given that re-burning a CD-R is something we really oughta be doing on some sort of time frame, and often will depart substantially from "added to ZK" date, if we do it right

Too, the CD-Rs would benefit from better integration with a URI for where the files live, accessible for only logged-in clients (currently we're attempting to build this up for new releases via google drive, though this is now introducing much, much larger scope to the issue, I mention this only as a peripheral thought)

[bufordsharkley]

After some discussion in the music department, we think that "Factory CD" may be the best name for the officially-pressed type of CDs, it's a relatively terse name, but which explains the difference pretty well (and is apparently increasingly common as a label)

[RocketMan]

I suppose starting them all with CD would make sense, though. For example,

• CD (unknown type)
• CD (factory pressed)
• CD-R (recorded)

In addition, at minimum, we will want to extend the /api/v1/album endpoint to support media queries, inclusive eventual constraint for the last-burned date. I don't foresee much UI impact, except to the combo list in the Library Editor, but do let me know if you have something in mind here in the way of reporting, etc.

the CD-Rs would benefit from better integration with a URI for where the files live, accessible for only logged-in clients (currently we're attempting to build this up for new releases via google drive, though this is now introducing much, much larger scope to the issue, I mention this only as a peripheral thought)

We already have this to some extent. For example, see Arya, Anthony / Road, The (Tag #1144785). Only logged-in DJs see the links. This facility is currently configured to work only with URIs for files hosted on google drive or within the stanford.edu domain.

[bufordsharkley]

Yeah, we might use "factory CD" as a shorthand elsewhere (especially in fields where auto-fill make it somewhat annoying to share a prefix), but these terms look good

I agree that a "last burned date" would be a great extension, for now we probably should assume that "added to library date" and "last burned" is similar, but these could definitely depart going forward

let me know if you have something in mind here in the way of reporting, etc.

I should talk to Francis to see how the library dept feels, but I think I could imagine two ways to integrate it which would be helpful:

• We may compile ZK numbers of a bunch of CD-Rs, and would wish to batch-update; if this is already doable via API and a script, we may be set (I need to acquaint myself with the API better...)
• Generate report of all CD-Rs, featuring dates of added to library (ideally last burned, but as said above, this is an almost perfect proxy)