Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: NowPlaying
#1
General Description

This thread is for discussion of the NowPlaying device class. This class is for sources of now playing metadata, where the source device is neither a media repository nor media renderer, but provides current metadata for consumption and display. So it's not unlike the current item metadata interface of the media renderer, though without any of the CQC'isms since this will just be raw data.

We define a reasonable set of fields that are likely to be available. Of course any deriver implementing providing this functionality MAY implement fields above and beyond this device class if it wishes. This class just defines those values that would be made use of by generic logic and interfaces.

Cover Art

There are only two sorts of data involved. One is text or numeric data, which represents the vast bulk of the metadata, and then there is cover art. The non image data will be provided by way of fields. The cover art MUST be served up via the backdoor driver interface used by the 'Driver Image' widget, which provides a simple, generic way for drivers to serve up images for display.

The Driver Image widget allows for a 'data name' to be passed to the driver to indicate which image to get, if multiples are provided. Two such keys will be used by drivers of this type:

CoverArt - The current cover art image, which SHOULD be where possible a moderate sized image, something in the 128x128 to 320x320 range, since it will be used to show the currently playing cover art, often in bottom bars or side bars. It's not a large preview type image.
PosterArt - If supported, this SHOULD be a larger format poster image, but will generally only be used for music media, not music. If the source doesn't provide such an image, just return no image data.

If the source doesn't provide image data at all, then the driver MUST implement the interface but just never return image data.

Fields Provided
[INDENT]The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in the form:

NWPLY#fieldname

where NWPLY# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. There will never be multi-unit considerations for this type of device class. Except where noted otherwise, all of the fields MUST be string type, and must be empty when no media is playing or the value is not available, with the exception of ImgSerialNum. They are all read-only.
  • AspectRatio. The aspect ratio of the currently playing media. If music or not provided, it MUST be Unknown. If at all possible the values SHOULD be just straight x:1 ratio values, since these are machine understandable values and can be used to set screen masking and such.
  • Artist. The artist associated with the currently playing media.
  • Cast. Only used for movies, this contains a comma separated list of cast members. By convention, the first member SHOULD be the lead actor if such a determination is possible.
  • CollectName. The name of the currently playing collection (album.)
  • Description. Generally only used for movies, this contains a short description of the media currently playing.
  • ImgSerialNum. This field MUST be a string field. Any time new cover or poster art is available, this MUST be changed. It MAY just be an ever increasing number formatted to text, some unique track id provided by the source, whatever suits the needs of the driver. This is required by the Driver Image widget, and tells it to come get new image data. The user will select this field when setting up the widget.
  • ItemName. The name of the the currently playing media item (track.)
  • PBPercent. The percent of the current media that has played so far. This field MUST be a Card type. If not supported the driver MUST set it to zero.
  • Rating. This MUST be a Card field, with a numeric range limit of 0 to 10. If not supported, set it to zero and leave it there.
  • Year. This field MST be a Card field and contain the year of production of the media playing. If no media, or the value is not available, it should be zero, in order to support hiding the display if not available.

Note that we assume that most general metadata sources will not provide any sort of structure beyond album/track (Collection and Item in CQC terms.) So no field is defined here that corresponds to the TitleSet name, in the interests of generality. Any given driver MAY of course define a non-V2 field that contains that information if it is available.
[/INDENT]

Multi-Unit Considerations

[INDENT]This device class does not expect there to ever be multiple metadata sources within one controllable device, server, etc... at least not any that are considered to be of a piece.[/INDENT]

Backdoor Commands/Queries

[INDENT]As mentioned in the opening commentary above, drivers which implement this device class MUST implement the backdoor commands supported by the Driver Image widget.[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#2
(Reserved)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
A question elsewhere on the forum prompted the thought that we need a device class for things that provide current metadata info, but which are not formal media renderers.

A driver might only implement this class. Or, perhaps it might implement the Media Player class and this class, for instance. Does this seem like a reasonable definition for such a class?

Of course it's tempting to say that the media renderer should implement this, as a way to provide access to basic metadata. But I dunno if that's wise. For one thing, it would require changing the media renderer class, which is one of the few really well established ones currently. And it would also mean inconsistent device class prefixes for the metadata, since this class cannot provide all of the info that the renderers do. So probably best not to attempt such a thing.
Dean Roddey
Software Geek Extraordinaire
Reply
#4
So, I'm going to start on a driver for the Myro:Air device tonight, and it will be the first one to use this device class, so I'm updating the release to include this as an available class. I'll need to do a device class description XML file for it as well, for validation purposes.

I think the current definition is reasonable, and I'm just going to go with it as is, unless something comes up during this driver that proves it's not right.
Dean Roddey
Software Geek Extraordinaire
Reply
#5
Oops, it didn't have separate fields for album and song names. It only had a single Title field. So I changed it to have ItemName and TitleName fields.
Dean Roddey
Software Geek Extraordinaire
Reply
#6
Dean,

I always get the terminology confused, but what if I have the following hierarchy:

The Best Of Xyzzy (Collection)
...The early years (Album)
......The first (Song)
......The second (Song)
...The middle age crisis (Album)
......the third (Song)
......the fourth (Song)
...The last years (Album)
......the fifth (Song)
......the sixth (Song)

This is how it works in a CQC music repository (names may be wrong) so don't you want to support this model?

[edit - The spaces don't work for indents, I replaced with ...)
Mark Stega
Reply
#7
This one is for devices that don't fit into the CQC mold, i.e. they can't be renderers and in some cases they aren't even players of any type they just expose current metadata. I'm guessing most of them probably won't provide more than album and track name, so I stuck with that.

We could of course have a field for it and not have it set, but since this stuff needs to drive generic templates and logic, you couldn't really use the top level because it would be so likely not to be available.

Of course it is an issue of what we call them. In CQC technically I guess we probably should call them CollectionName and ItemName, since that would be the equivalent of an album and track. But, since this is for devices that aren't really CQC compliant, I'm not sure if really makes a difference or not?

I guess any given driver could have a non-V2 compliant TitleSetName if it can provide it, and this device class could call the two V2 compliant ones CollectName and ItemName.
Dean Roddey
Software Geek Extraordinaire
Reply
#8
Dean Roddey Wrote:I guess any given driver could have a non-V2 compliant TitleSetName if it can provide it, and this device class could call the two V2 compliant ones CollectionName and ItemName.
I like this; Keep the names the same as the other V2 drivers and have the option (as always in a V2 driver) of an aaditional field to handle the TitleSetName.
Mark Stega
Reply
#9
OK, I made that change.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,358 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,618 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,363 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,484 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,331 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,205 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,007 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,131 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,357 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 917 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)