FMPS

[Jeff Mitchell]

On 01/27/2010 12:47 PM, Steven Robertson wrote:
> On Mon, Jan 25, 2010 at 3:35 PM, Jeff Mitchell <mitchell at kde.org> wrote:
>> On Mon, 25 Jan 2010 13:08:03 -0500, Steven Robertson <steven at strobe.cc>
>> wrote:
>>>> And if you don't, reply and say what you feel needs to be changed.
>>>
>>> I'd like to see a few additional statistics standardized, particularly
>>> "lastplayed" timestamp, and optionally a "laststarted" timestamp,
>>> "added" (or "firstplayed") timestamp, and "skipcount"
>>> ...
>> Interesting idea. Do you think this belongs in an algorithm section (i.e.
>> algorithms can specify their own subidentifiers, like at e.g.
>> FMPS_Rating_Algorithm_QuodLibet_laststarted) or at a more global scope?
>> ...
>> Granted the result would be more player-specific,
>> but that might be better than relying on global values that aren't always
>> properly being kept up-to-date.
> 
> Well, I imagine that users who really rely on this feature (myself
> included) would be fairly interested in using players that track and
> write this information. Those that don't use first- and lastplayed
> times to keep track of their listening habits won't care if a few
> values don't get updated. The meaning of these terms should be clear,
> and independent of any particular recommendation algorithm. These
> reasons make me prefer an optional general tag (FMPS_laststarted)
> rather than the more complex one listed above. They certainly don't
> need to be required, but it would be useful to have their identifier
> and value format defined in the spec.

Good points. I agree. I'll put them in in the next draft. (If I forget,
poke me.)

> In other words, I imagine nearly everyone developing a
> music player application is at least a little fussy about their tags.
> ;)

Heh. I think you're right.

>> The latest draft of the spec (which is in progress, not published as a
>> draft yet, but viewable at the same URL) takes this into account -- it
>> makes it clear that the cases specified are suggested for consistency and
>> that converting strings to all uppercase/lowercase when performing
>> comparisons is a good idea. This should keep case-based interoperability
>> issues from occurring. The RFC-style language will help clarify that
>> further, when I add that in.
> 
> That's entirely satisfactory.
> 
> Support for FMPS in the next major release of Quod Libet is now planned.

Great! As you may be aware, the inspiration for some of the spec came
from your guys' in-house spec in the first place...so it's nice to see
it coming full circle.

Happy to have you on board,
Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xdg/attachments/20100127/84c9a141/attachment.pgp