LinnDocs - User contributions [en]

Beta:Home

2011-08-11T16:19:51Z

Grahamd: /* How do I participate in the beta programme? */

= What is a beta programme? =

Linn has a beta programme to allow external use and testing of new software and hardware prior to its formal release. Whilst we provide and test against recommended environments, in an open system, there are many different tweaks and changes that DS customers can employ. The beta programme helps ensure that an upcoming release of software works in as many of those different environments as possible.

== Characteristics of a Linn beta release ==

* All intended features of the upcoming release are implemented.
* It functions reasonably well on at least one recommended environment.
* It has had some internal testing against that recommended environment.
* Discussion and support take place on Linn's [http://forums.linn.co.uk/bb/forumdisplay.php?fid=5 '''Development Forum''']
** Beta releases are not upported by the Linn Service Department, this includes downgrading to previous releases
* Bugs can be reported via http://products.linn.co.uk/trac/

= Who should participate in the beta programme? =

Technically advanced DS users who:

* Don't mind if their DS doesn't play any music for a couple of hours, or even a couple of days.
* Don't mind that they can't use all of their current control points.
* Are willing to discuss their experiences on Linn's [http://forums.linn.co.uk/bb/forumdisplay.php?fid=5 '''Development Forum''']
* Are willing to raise bugs on http://products.linn.co.uk/trac/ and then track and test the potential solutions to those bugs.
* Want to ensure their environment has robust support when the software is fully released.

= How do I participate in the beta programme? =

The following products are currently in beta:

* [[Beta:DsDavaar|DS Davaar 3]]

Subscribe to the Beta RSS feed to keep up to date with the latest Beta releases:

* [http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml]

Beta:Home

2011-06-28T16:25:55Z

Grahamd: /* How do I participate in the beta programme? */

= What is a beta programme? =

Linn has a beta programme to allow external use and testing of new software and hardware prior to its formal release. Whilst we provide and test against recommended environments, in an open system, there are many different tweaks and changes that DS customers can employ. The beta programme helps ensure that an upcoming release of software works in as many of those different environments as possible.

== Characteristics of a Linn beta release ==

* All intended features of the upcoming release are implemented.
* It functions reasonably well on at least one recommended environment.
* It has had some internal testing against that recommended environment.
* Discussion and support take place on Linn's [http://forums.linn.co.uk/bb/forumdisplay.php?fid=5 '''Development Forum''']
** Beta releases are not upported by the Linn Service Department, this includes downgrading to previous releases
* Bugs can be reported via http://products.linn.co.uk/trac/

= Who should participate in the beta programme? =

Technically advanced DS users who:

* Don't mind if their DS doesn't play any music for a couple of hours, or even a couple of days.
* Don't mind that they can't use all of their current control points.
* Are willing to discuss their experiences on Linn's [http://forums.linn.co.uk/bb/forumdisplay.php?fid=5 '''Development Forum''']
* Are willing to raise bugs on http://products.linn.co.uk/trac/ and then track and test the potential solutions to those bugs.
* Want to ensure their environment has robust support when the software is fully released.

= How do I participate in the beta programme? =

The following products are currently in beta:

* KinskyTouch for iPad

Subscribe to the Beta RSS feed to keep up to date with the latest Beta releases:

* [http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml]

Developer:Davaar:ProductService

2011-03-18T13:44:09Z

Grahamd: /* Attributes */

= Architectural Overview =

The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.

It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.

== Network Presentation ==

=== Attributes ===
Every product has one or more attributes indicating additional features offered by that product beyond those provided by its sources

=== Manufacturer ===
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Name ====
Name contains the Manufacturer name (example: "''Linn''"). Name is read only.

==== Info ====
Info contains more Manufacturer information (example "''Linn Products Ltd''"). Info is read only.

==== Url ====
Url contains the Manufacturer website address (example "''http://www.linn.co.uk''"). Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Model ===

There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.

==== Name ====
Name contains the Model name (example: "''Majik DS''"). Name is read only.
==== Info ====
Info contains more Model information (example "''Linn Hi-Fi component''"). Info is read only.
==== Url ====
Url contains the Model website address (example "''http://products.linn.co.uk/MajikDS''"). Url is read only.
==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Product ===
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Room ====
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.

==== Name ====
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. By default the Name is the same as the Model.

==== Info ====
Info contains more Product information (example "''Linn Hi-Fi component''"). Info is read only.

==== Url ====
Url contains... Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

== Standby Control==

=== Standby===
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state.

== Source Control ==

=== Source List===
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]

=== Source Index ===

The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.

=== SourceCount ===

SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.

=== Source Specific Parameters ===
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.

==== SourceSystemName ====

SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.

==== SourceName ====

SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceType ====

SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceVisible ====

SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.

Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''

= Actions=

== Network Presentation Actions==
=== Attributes Action ===
The Attributes action reports a string containing a space separated list of all attributes.

=== Manufacturer Action ===
The Manufacturer action returns all four Manufacturer parameters.

=== Model Action ===
The Model action returns all four Model parameters.

=== Product Action ===
The Product action returns all five Product parameters.

== Standby Actions==
=== Standby===
The Standby action reports the current standby state of the product.

=== SetStandby===
The SetStandby action provides a means of setting the current standby state of the product.

==Source Actions==
===SourceXml Action===
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.

===SourceXmlChangeCount Action===
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.

===Source Action===
The Source action returns all source specific parameters for a given source index.

= API Reference =

[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Product1.xml Product Service Description (XML)]

= Migration Guide =

All actions relating to configuration have been removed as part of the migration to the Davaar.

The domain for the Product service has changed to '''av.openhome.org'''.

== Actions ==
=== Changed Actions ===
====Standby====
The arguments have changed their names as follows:
*aStandby -> Value
====SetStandby====
The arguments have changed their names as follows:
*aStandby -> Value
====SourceCount====
The arguments have changed their names as follows:
*aSourceCount -> Value
====SourceXml====
The arguments have changed their names as follows:
*aSourceXml -> Value

====SourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value
====SetSourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value

====SetSourceIndexByName====
The arguments have changed their names as follows:
*aSourceName -> Value

=== New Actions ===
*Manufacturer
*Model
*Product
*Source
*Attributes
*SourceXmlChangeCount

=== Obsolete Actions ===
*SetName
*SetRoom
*SetStartupSourceIndex
*StartupSourceIndex
*SetStartupSourceIndexByName
*SetStartupSourceEnabled
*StartupSourceEnabled
*SetSourceVisible
*SetSourceName
*SourceAttributes

Beta:DsDavaar

2011-03-17T17:13:05Z

Grahamd: /* Songcast */

= DS Davaar Beta =

== What is it? ==

Davaar is a major software upgrade for all DS products. It introduces a number of new features for all DS products and lays the technical groundwork for future improvements. Davaar contains two new headline features:

* OpenHome compatibility
* [[Songcast]]

=== OpenHome compatibility ===

OpenHome is an independent standard for networked home devices. Linn's DS devices are fully compatible with the OpenHome Audio Visual (AV) specification. OpenHome AV allows other manufacturer's digitial streaming products and control points to interact in a seamless way with Linn's DS.

=== Songcast ===

[[Songcast|Songcast]] allows a DS to tune-in to another DS. A DS can [[songcast]] to more than one DS. Further, a DS can [[songcast]] no matter what source is selected.

== Requirements ==

You will need a Davaar compatible control point to utilise the Davaar beta for the DS. [http://oss.linn.co.uk/trac/wiki/KinskyDesktop KinskyDesktop Davaar] has also entered its beta release and you will need it to control your Davaar DS. Other control points are being migrated to Davaar and will become available during the beta phase.

== Where do I start? ==

# Ensure you are aware and agree with the requirements of being involved in Linn's [[Beta:Home|beta programme]]
# Download and install the latest Davaar Linn Konfig application [http://products.linn.co.uk/VersionInfo/Downloads/Beta here] (Available for Windows, Mac, and Linux platforms)
# Go to Tools->Options and select 'Show Beta Versions' from the Updates section of Linn Konfig
# Select your device from the list, go to the update tab, select the latest Davaar beta firmware release, and click update
#* If you have multiple DS devices, you can select Tools->Update All Devices
#* Linn Konfig [[Konfig Manual|Manual]]

== Release Notes ==
* '''[[Beta:DsDavaar1:Release Notes|Davaar 1]]'''

== FAQ ==
=== How do I report a defect? ===
# Login to our [http://products.linn.co.uk/trac defect tracking site]
#* If you don't have a login name and password, please send a request to support@products.linn.co.uk
# Follow the instructions listed for 'Creating a New Ticket'
# Once created, your ticket is assigned an engineer and will be investigated
# All progress made on the ticket will be emailed to you as it is updated

=== What if I have problems updating? ===
''Don't panic, the update process is safe, so you will always be able to recover your device''
* Restart Linn Konfig. If your device reports a Davaar version, the update was successfull and you are done.
* If your device does not report a Davaar version, retry the update process
* If this fails, power cycle your device and try again
* If this fails, put your device into fallback (from the button on the back of the device) and try again

=== What if I want to go back to Cara? ===
# You must first complete the Davaar upgrade process once it has been started
# Put your device into fallback mode from the button on the back of the device
# Download and install the latest Cara Linn Konfig application (3.10.6) [http://products.linn.co.uk/VersionInfo/Downloads/Releases here]
# Select your device from the list and go to the update tab.
# Select device firmware from the dropdown box and select the latest Cara firmware release and update
# Keep in mind
#* Davaar control points will no longer work with your device

== Known Issues ==
* Potential intermittent hiss on outputs when an analog source is active
* Potential time shift when changing tracks between different sample rates over [[Songcast]]
* Webconfig is not yet fully functional
* Initial beta release only provides support for Small-scale [[Songcast]] mode

Beta:Home

2011-03-17T15:45:36Z

Grahamd: /* How do I participate in the beta programme? */

= What is a beta programme? =

Linn has a beta programme to allow external use and testing of new software and hardware prior to its formal release. Whilst we provide and test against recommended environments, in an open system, there are many different tweaks and changes that DS customers can employ. The beta programme helps ensure that an upcoming release of software works in as many of those different environments as possible.

== Characteristics of a Linn beta release ==

* All intended features of the upcoming release are implemented.
* It functions reasonably well on at least one recommended environment.
* It has had some internal testing against that recommended environment.
* Discussion and support take place on Linn's development forum: http://forums.linn.co.uk/bb/forumdisplay.php?fid=5
* Bugs can be reported via http://products.linn.co.uk/trac/

= Who should participate in the beta programme? =

Technically advanced DS users who:

* Don't mind if their DS doesn't play any music for a couple of hours, or even a couple of days.
* Don't mind that they can't use all of their current control points.
* Are willing to discuss their experiences on the development forum (http://forums.linn.co.uk/bb/forumdisplay.php?fid=5)
* Are willing to raise bugs on http://products.linn.co.uk/trac/ and then track and test the potential solutions to those bugs.
* Want to ensure their environment has robust support when the software is fully released.

= How do I participate in the beta programme? =

The following products are currently in beta:

* [[Beta:DsDavaar|DS Davaar 1]]
* [http://oss.linn.co.uk/trac/wiki/KinskyDesktop KinskyDesktop Davaar]

Subscribe to the Beta RSS feed to keep up to date with the latest Beta releases:

* [http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml http://products.linn.co.uk/VersionInfo/BetaVersionInfo.xml]

Songcast

2011-03-17T13:49:48Z

Grahamd: /* Initial Setup */

= Songcast =

== Introduction ==
Davaar sees the introduction of Songcast. Songcast allows a DS to tune into another DS. A DS can songcast to more than one DS. Further, a DS can songcast no matter what source is selected.

== Initial Setup ==
* Your DS must be running Davaar 1 firmware or higher.
* You will require a Davaar compatible Linn Konfig to update and configure your DS
* You will require a Davaar compatible control software to control your DS

== How to Songcast ==

=== Using Kinsky Desktop ===
* text

=== Using Kinsky PDA ===
* Not yet supported

=== Using the handset (REM 019) ===
* text

== Home Plugs and Songcast ==
* Installation scalability may be decreased
* May not reliably songcast studio master quality audio

Songcast

2011-03-17T13:49:26Z

Grahamd: /* Initial Setup */

= Songcast =

== Introduction ==
Davaar sees the introduction of Songcast. Songcast allows a DS to tune into another DS. A DS can songcast to more than one DS. Further, a DS can songcast no matter what source is selected.

== Initial Setup ==
* Your DS must be running Davaar 1 firmware or higher.
* You will require a Davaar compatible Linn Konfig to update and configure your device
* You will require a Davaar compatible control software to control your device

== How to Songcast ==

=== Using Kinsky Desktop ===
* text

=== Using Kinsky PDA ===
* Not yet supported

=== Using the handset (REM 019) ===
* text

== Home Plugs and Songcast ==
* Installation scalability may be decreased
* May not reliably songcast studio master quality audio

Developer:Media Server Extensions

2011-01-18T11:21:31Z

Grahamd: /* Example */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits and display technologies. This means that a control point on a PC might want to display artwork at a high resolution, while a control point on a PDA might want to display artwork at a much lower resolution.

Media servers often try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element tells the control point:

# the media server implements the image scaling extension
# the original size of the image.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:19:07Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits and display technologies. This means that a control point on a PC might want to display artwork at a high resolution, while a control point on a PDA might want to display artwork at a much lower resolution.

Media servers often try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:18:40Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits and display technologies. This means that a control point on a PC might want to display artwork at a high resolution, while a control point on a PDA might want to display artwork at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:17:52Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits and display technologies. This means that a control point on a PC might be capable of displaying images at a high resolution, while a control point on a PDA might only want to display images at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:14:39Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits. This means that a control point on a PC might be capable of displaying images at a high resolution, while a control point on a PDA might only want to display images at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:11:48Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits. This means that a control point on a PC might be capable of displaying images at a high resolution, while a control point on a PDA might only want to display images at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.

The second solution is just an architecturally poor solution, which turns the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.

So, it is proposed that compliant media servers include a '''size''' element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T11:03:18Z

Grahamd: /* Example */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits. This means that a control point on a PC is capable of displaying images of a high resolution, while a control point on a PDA can only display images at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

These systems are fundamentally flawed as they are trying to infer what a control point wants, rather than allowing a control point to ask the media server for the information it wants.

It is proposed that all image URIs allow a parameter '''size''' to be specified, (where the size is the image's largest dimension). This parameter allows a control point to ask for the image at a specified size; It is then up to the media server to try and service this request as best possible.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.

The presence of the size element informs the control point that the media server implements the image scaling extension and informs the control point what the original size of the image is.

Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.

So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Media Server Extensions

2011-01-18T10:40:15Z

Grahamd: /* Image Resolution */

= Introduction =

The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.

= High =

== Image Resolution ==

Control points running on different platforms have different memory limits. This means that a control point on a PC is capable of displaying images of a high resolution, while a control point on a PDA can only display images at a much lower resolution.

Currently media servers try to solve this problem using one of the following two methods:

# A configurable parameter that scales all artwork to a user defined size
# A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile

These systems are fundamentally flawed as they are trying to infer what a control point wants, rather than allowing a control point to ask the media server for the information it wants.

It is proposed that all image URIs allow a parameter '''size''' to be specified, (where the size is the image's largest dimension). This parameter allows a control point to ask for the image at a specified size; It is then up to the media server to try and service this request as best possible.

=== Example ===

If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512; if it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0. Providing this size element in the albumArtURI informs the control point that the media server implements this image scaling extension and informs the control point what the original size of the image is.

== albumArtURI ==

The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.

There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.

It is proposed that an optional property is introduced to the object class called '''albumArtURI'' '''''which may contain an attribute '''title''', e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements. 

= Medium =
= Low =

== Dynamic IP Addresses ==

At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid. 

 

It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.

== Disc Information ==

It is proposed that two new properties are added to the musicTrack item called '''OriginalDiscNumber''' and '''OriginalDiscCount'''

== Replay Gain Information ==

It is proposed that four new properties are added to the musicTrack item called '''ReplayGainAlbum''', '''ReplayGainAlbumPeak''', '''ReplayGainTrack''', and '''ReplayGainTrackPeak'''.

== webURI ==

The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.

 

It is proposed to add an optionally property to the object class called '''webURI '''which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.

Developer:Davaar:Topology

2010-12-02T15:31:10Z

Grahamd: /* Introduction */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Openhome Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.

Control points may optionally provide the user with control of the volume of each product within the tree.

Developer:Davaar:ReceiverService

2010-12-01T13:44:29Z

Grahamd: /* Stop */

= Architectural Overview =

The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:Davaar:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.

A receiver plays audio broadcast from a sender.

= Actions =
== Sender ==
Report the Uri and Metadata of the sender this receiver is currently listening to.

==SetSender==
Set the Uri and Metadata of the sender to listen to.

The Metadata must have originated from a device bearing the [[Developer:Davaar:SenderService|Sender service]].

The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.

==ProtocolInfo==
Report the receiver's protocol info.

==TransportState==

Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.

==Play==
Play audio from the current sender

==Stop==
Stop playing audio from the current sender

= Technical Details =
<code>
Domain : av.openhome.org
Name : Receiver
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Receiver1.xml Receiver Service Description (XML)]

Developer:Davaar:ReceiverService

2010-12-01T13:44:17Z

Grahamd: /* Play */

= Architectural Overview =

The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:Davaar:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.

A receiver plays audio broadcast from a sender.

= Actions =
== Sender ==
Report the Uri and Metadata of the sender this receiver is currently listening to.

==SetSender==
Set the Uri and Metadata of the sender to listen to.

The Metadata must have originated from a device bearing the [[Developer:Davaar:SenderService|Sender service]].

The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.

==ProtocolInfo==
Report the receiver's protocol info.

==TransportState==

Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.

==Play==
Play audio from the current sender

==Stop==
Stop playing the current sender

= Technical Details =
<code>
Domain : av.openhome.org
Name : Receiver
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Receiver1.xml Receiver Service Description (XML)]

Developer:Davaar:ReceiverService

2010-12-01T13:43:45Z

Grahamd: /* SetSender */

= Architectural Overview =

The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:Davaar:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.

A receiver plays audio broadcast from a sender.

= Actions =
== Sender ==
Report the Uri and Metadata of the sender this receiver is currently listening to.

==SetSender==
Set the Uri and Metadata of the sender to listen to.

The Metadata must have originated from a device bearing the [[Developer:Davaar:SenderService|Sender service]].

The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.

==ProtocolInfo==
Report the receiver's protocol info.

==TransportState==

Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.

==Play==
Play the current sender

==Stop==
Stop playing the current sender

= Technical Details =
<code>
Domain : av.openhome.org
Name : Receiver
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Receiver1.xml Receiver Service Description (XML)]

Developer:Davaar:ReceiverService

2010-12-01T13:43:28Z

Grahamd: /* Sender */

= Architectural Overview =

The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:Davaar:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.

A receiver plays audio broadcast from a sender.

= Actions =
== Sender ==
Report the Uri and Metadata of the sender this receiver is currently listening to.

==SetSender==
Set the Uri and Metadata of the current sender.

The Metadata must have originated from a device bearing the [[Developer:Davaar:SenderService|Sender service]].

The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.

==ProtocolInfo==
Report the receiver's protocol info.

==TransportState==

Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.

==Play==
Play the current sender

==Stop==
Stop playing the current sender

= Technical Details =
<code>
Domain : av.openhome.org
Name : Receiver
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Receiver1.xml Receiver Service Description (XML)]

Developer:Davaar:ReceiverService

2010-12-01T13:42:57Z

Grahamd: /* Architectural Overview */

= Architectural Overview =

The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:Davaar:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.

A receiver plays audio broadcast from a sender.

= Actions =
== Sender ==
Report the Uri and Metadata of the current sender.

==SetSender==
Set the Uri and Metadata of the current sender.

The Metadata must have originated from a device bearing the [[Developer:Davaar:SenderService|Sender service]].

The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.

==ProtocolInfo==
Report the receiver's protocol info.

==TransportState==

Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.

==Play==
Play the current sender

==Stop==
Stop playing the current sender

= Technical Details =
<code>
Domain : av.openhome.org
Name : Receiver
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Receiver1.xml Receiver Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:40:51Z

Grahamd: /* Status */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If the sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending audio over the network
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel (mis-configuration)
* Inactive - no audio source currently assigned to this sender
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:40:18Z

Grahamd: /* Status */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If the sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending audio over the network
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - no audio source currently assigned to this sender
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:39:32Z

Grahamd: /* Status */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If the sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending audio over the network
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - no audio source connected to this sender
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:38:43Z

Grahamd: /* Status */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If the sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending audio over the network
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - currently no audio to send on this channel
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:38:14Z

Grahamd: /* PresentationUrl */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If the sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending out audio
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - currently no audio to send on this channel
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:37:58Z

Grahamd: /* PresentationUrl */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.

If this sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending out audio
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - currently no audio to send on this channel
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:SenderService

2010-12-01T13:37:04Z

Grahamd: /* Architectural Overview */

= Architectural Overview =

The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.

An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.

Openhome senders should be discovered independently of the standard algorithm for discovering Openhome products and sources. An independent search should be made for devices bearing the Sender service.

= Actions =
== Attributes ==
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.

Currently defined attributes are:

* Info - this device reports on the current media using the Info service
* Time - this device reports on the current media using the Time service

== Audio ==
Reports whether audio is currently present on this sender.

== Metadata ==
Provides a representation of this audio item in DIDL-Lite format.

== PresentationUrl ==
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application secific way.

If this sender has no presentation page, the PresentationUrl should be empty.

== Status ==
Reports the status of the sender (normally only for debugging purposes):

* Sending - currently sending out audio
* Ready - ready to send audio but no listeners
* Blocked - audio from another sender detected on the same channel
* Inactive - currently no audio to send on this channel
* Disabled - sender disabled by user configuration

= Technical Details =
<code>
Domain : av.openhome.org
Name : Sender
Version : 1
</code>
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]

Developer:Davaar:ProductService

2010-11-29T15:14:02Z

Grahamd: /* Architectural Overview */

= Architectural Overview =

The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.

It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.

== Network Presentation ==

=== Attributes ===
Every product has one or more attributes indicating the key features supported by that product.

=== Manufacturer ===
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Name ====
Name contains the Manufacturer name (example: "''Linn''"). Name is read only.

==== Info ====
Info contains more Manufacturer information (example "''Linn Products Ltd''"). Info is read only.

==== Url ====
Url contains the Manufacturer website address (example "''http://www.linn.co.uk''"). Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Model ===

There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.

==== Name ====
Name contains the Model name (example: "''Majik DS''"). Name is read only.
==== Info ====
Info contains more Model information (example "''Linn Hi-Fi component''"). Info is read only.
==== Url ====
Url contains the Model website address (example "''http://products.linn.co.uk/MajikDS''"). Url is read only.
==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Product ===
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Room ====
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.

==== Name ====
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. By default the Name is the same as the Model.

==== Info ====
Info contains more Product information (example "''Linn Hi-Fi component''"). Info is read only.

==== Url ====
Url contains... Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

== Standby Control==

=== Standby===
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state.

== Source Control ==

=== Source List===
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]

=== Source Index ===

The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.

=== SourceCount ===

SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.

=== Source Specific Parameters ===
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.

==== SourceSystemName ====

SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.

==== SourceName ====

SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceType ====

SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceVisible ====

SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.

Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''

= Actions=

== Network Presentation Actions==
=== Attributes Action ===
The Attributes action reports a string containing a space separated list of all attributes.

=== Manufacturer Action ===
The Manufacturer action returns all four Manufacturer parameters.

=== Model Action ===
The Model action returns all four Model parameters.

=== Product Action ===
The Product action returns all five Product parameters.

== Standby Actions==
=== Standby===
The Standby action reports the current standby state of the product.

=== SetStandby===
The SetStandby action provides a means of setting the current standby state of the product.

==Source Actions==
===SourceXml Action===
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.

===SourceXmlChangeCount Action===
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.

===Source Action===
The Source action returns all source specific parameters for a given source index.

= API Reference =

[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Product1.xml Product Service Description (XML)]

= Migration Guide =

All actions relating to configuration have been removed as part of the migration to the Davaar.

The domain for the Product service has changed to '''av.openhome.org'''.

== Actions ==
=== Changed Actions ===
====Standby====
The arguments have changed their names as follows:
*aStandby -> Value
====SetStandby====
The arguments have changed their names as follows:
*aStandby -> Value
====SourceCount====
The arguments have changed their names as follows:
*aSourceCount -> Value
====SourceXml====
The arguments have changed their names as follows:
*aSourceXml -> Value

====SourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value
====SetSourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value

====SetSourceIndexByName====
The arguments have changed their names as follows:
*aSourceName -> Value

=== New Actions ===
*Manufacturer
*Model
*Product
*Source
*Attributes
*SourceXmlChangeCount

=== Obsolete Actions ===
*SetName
*SetRoom
*SetStartupSourceIndex
*StartupSourceIndex
*SetStartupSourceIndexByName
*SetStartupSourceEnabled
*StartupSourceEnabled
*SetSourceVisible
*SetSourceName
*SourceAttributes

Developer:Davaar

2010-11-24T15:39:04Z

Grahamd: /* Davaar 1 */

Developer:Davaar

2010-11-24T15:38:54Z

Grahamd: /* Party mode support */

Developer:Davaar

2010-11-24T15:38:44Z

Grahamd: /* Known Issues */

Developer:Davaar

2010-11-24T15:38:25Z

Grahamd: /* Davaar 1 */

Developer:Davaar

2010-11-24T15:37:58Z

Grahamd: /* Davaar Developer Documentation */

Developer:Davaar

2010-11-24T15:37:50Z

Grahamd: /* Davaar 1 */

= Davaar Developer Documentation =

= Davaar 1 =
== Services ==

* [[Developer:Davaar:ProductService|Product Service]]
* [[Developer:Davaar:PlaylistService|Playlist Service]]
* [[Developer:Davaar:JukeboxService|Jukebox Service]]
* [[Developer:Davaar:AvtService|UPnP AV Transport Service]]
* [[Developer:Davaar:RenderingControlService|UPnP Rendering Control Service]]
* [[Developer:Davaar:RadioService|Radio Service]]
* [[Developer:Davaar:InfoService|Info Service]]
* [[Developer:Davaar:TimeService|Time Service]]
* [[Developer:Davaar:VolumeService|Volume Service]]
* [[Developer:Davaar:SenderService|Sender Service]]
* [[Developer:Davaar:ReceiverService|Receiver Service]]

== Algorithms ==

* [[Developer:Davaar:Topology|Topology]]

* [[Developer:Davaar:PlaylistService#IdArray|Id Array]]

== Known Issues ==

If you are using a alpha or beta release of the code, bugs, features and performance issues should be expected. Keeping an up-to-date bug log on this Wiki page would be unreasonable, hence only issues which require a work-around to get the code running will be listed here in detail.

== Required Workarounds ==

* None

Developer:Davaar

2010-11-24T15:37:13Z

Grahamd: /* Davaar Developer Documentation */

= Davaar Developer Documentation =

= Davaar 1 =
== Overview ==
Davaar is the name of a Linn [[Software Compatibility Families|software compatibility family]]. It represents a family of on- and off-device software that is interoperable.

This interoperability consists in a stable set of well-defined interfaces and a shared set of software practices, including product discovery and playlist management algorithms.

Davaar contains two new headline features:

* Openhome compatibility
* Party mode support

=== Openhome compatibility ===

Openhome is an independent standard for networked home devices. Davaar brings Linn's DS devices into line with this Openhome standard. Each Openhome service is described below together with a migration guide for its Linn Cara equivalent.

=== Party mode support ===

Davaar allows one DS to play whatever is being played by another DS. This is achieved by coupling the new Receiver source (and associated service) with the new Sender service. A detailed description is given below.

== Services ==

* [[Developer:Davaar:ProductService|Product Service]]
* [[Developer:Davaar:PlaylistService|Playlist Service]]
* [[Developer:Davaar:JukeboxService|Jukebox Service]]
* [[Developer:Davaar:AvtService|UPnP AV Transport Service]]
* [[Developer:Davaar:RenderingControlService|UPnP Rendering Control Service]]
* [[Developer:Davaar:RadioService|Radio Service]]
* [[Developer:Davaar:InfoService|Info Service]]
* [[Developer:Davaar:TimeService|Time Service]]
* [[Developer:Davaar:VolumeService|Volume Service]]
* [[Developer:Davaar:SenderService|Sender Service]]
* [[Developer:Davaar:ReceiverService|Receiver Service]]

== Algorithms ==

* [[Developer:Davaar:Topology|Topology]]

* [[Developer:Davaar:PlaylistService#IdArray|Id Array]]

== Known Issues ==

If you are using a alpha or beta release of the code, bugs, features and performance issues should be expected. Keeping an up-to-date bug log on this Wiki page would be unreasonable, hence only issues which require a work-around to get the code running will be listed here in detail.

== Required Workarounds ==

* None

Developer:Davaar

2010-11-24T15:36:50Z

Grahamd: /* Davaar 1 */

= Davaar Developer Documentation =

== Overview ==
Davaar is the name of a Linn [[Software Compatibility Families|software compatibility family]]. It represents a family of on- and off-device software that is interoperable.

This interoperability consists in a stable set of well-defined interfaces and a shared set of software practices, including product discovery and playlist management algorithms.

Davaar contains two new headline features:

* Openhome compatibility
* Party mode support

=== Openhome compatibility ===

Openhome is an independent standard for networked home devices. Davaar brings Linn's DS devices into line with this Openhome standard. Each Openhome service is described below together with a migration guide for its Linn Cara equivalent.

=== Party mode support ===

Davaar allows one DS to play whatever is being played by another DS. This is achieved by coupling the new Receiver source (and associated service) with the new Sender service. A detailed description is given below.

= Davaar 1 =
== Overview ==
Davaar is the name of a Linn [[Software Compatibility Families|software compatibility family]]. It represents a family of on- and off-device software that is interoperable.

This interoperability consists in a stable set of well-defined interfaces and a shared set of software practices, including product discovery and playlist management algorithms.

Davaar contains two new headline features:

* Openhome compatibility
* Party mode support

=== Openhome compatibility ===

Openhome is an independent standard for networked home devices. Davaar brings Linn's DS devices into line with this Openhome standard. Each Openhome service is described below together with a migration guide for its Linn Cara equivalent.

=== Party mode support ===

Davaar allows one DS to play whatever is being played by another DS. This is achieved by coupling the new Receiver source (and associated service) with the new Sender service. A detailed description is given below.

== Services ==

* [[Developer:Davaar:ProductService|Product Service]]
* [[Developer:Davaar:PlaylistService|Playlist Service]]
* [[Developer:Davaar:JukeboxService|Jukebox Service]]
* [[Developer:Davaar:AvtService|UPnP AV Transport Service]]
* [[Developer:Davaar:RenderingControlService|UPnP Rendering Control Service]]
* [[Developer:Davaar:RadioService|Radio Service]]
* [[Developer:Davaar:InfoService|Info Service]]
* [[Developer:Davaar:TimeService|Time Service]]
* [[Developer:Davaar:VolumeService|Volume Service]]
* [[Developer:Davaar:SenderService|Sender Service]]
* [[Developer:Davaar:ReceiverService|Receiver Service]]

== Algorithms ==

* [[Developer:Davaar:Topology|Topology]]

* [[Developer:Davaar:PlaylistService#IdArray|Id Array]]

== Known Issues ==

If you are using a alpha or beta release of the code, bugs, features and performance issues should be expected. Keeping an up-to-date bug log on this Wiki page would be unreasonable, hence only issues which require a work-around to get the code running will be listed here in detail.

== Required Workarounds ==

* None

Developer:Davaar

2010-11-24T15:35:56Z

Grahamd: /* Known Issues */

Developer:Davaar

2010-11-24T15:35:37Z

Grahamd: /* Davaar 1 */

Developer:Davaar

2010-11-24T15:34:49Z

Grahamd: /* Davaar 1 */

Developer:Davaar

2010-11-24T15:34:36Z

Grahamd: /* Davaar 1 */

Developer:Davaar:ProductService

2010-11-24T15:28:16Z

Grahamd: /* Attributes Action */

= Architectural Overview =

The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.

It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.

A physical product may contain more than one Product and thus be presented as more than one Product service on the network. An example of this would be a preamplifier with an embedded DS source. In this scenario the two Product services are '''''Linked''''' (internally grouped). Linked Products share certain key parameters such as Standby and Room (ie changing Standby on one Product will automatically change the Standby state on all other Products in that '''''Linked''''' group).

== Network Presentation ==

=== Attributes ===
Every product has one or more attributes indicating the key features supported by that product.

=== Manufacturer ===
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Name ====
Name contains the Manufacturer name (example: "''Linn''"). Name is read only.

==== Info ====
Info contains more Manufacturer information (example "''Linn Products Ltd''"). Info is read only.

==== Url ====
Url contains the Manufacturer website address (example "''http://www.linn.co.uk''"). Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Model ===

There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.

==== Name ====
Name contains the Model name (example: "''Majik DS''"). Name is read only.
==== Info ====
Info contains more Model information (example "''Linn Hi-Fi component''"). Info is read only.
==== Url ====
Url contains the Model website address (example "''http://products.linn.co.uk/MajikDS''"). Url is read only.
==== ImageUri ====
ImageUri contains... ImageUri is read only.

=== Product ===
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.

==== Room ====
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.

==== Name ====
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room : Name'''''}. By default the Name is the same as the Model.

==== Info ====
Info contains more Product information (example "''Linn Hi-Fi component''"). Info is read only.

==== Url ====
Url contains... Url is read only.

==== ImageUri ====
ImageUri contains... ImageUri is read only.

== Standby Control==

=== Standby===
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state.

== Source Control ==

=== Source List===
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]

=== Source Index ===

The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.

=== SourceCount ===

SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.

=== Source Specific Parameters ===
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.

==== SourceSystemName ====

SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.

==== SourceName ====

SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceType ====

SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.

==== SourceVisible ====

SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.

Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''

= Actions=

== Network Presentation Actions==
=== Attributes Action ===
The Attributes action reports a string containing a space separated list of all attributes.

=== Manufacturer Action ===
The Manufacturer action returns all four Manufacturer parameters.

=== Model Action ===
The Model action returns all four Model parameters.

=== Product Action ===
The Product action returns all five Product parameters.

== Standby Actions==
=== Standby===
The Standby action reports the current standby state of the product.

=== SetStandby===
The SetStandby action provides a means of setting the current standby state of the product.

==Source Actions==
===SourceXml Action===
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.

===SourceXmlChangeCount Action===
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.

===Source Action===
The Source action returns all source specific parameters for a given source index.

= API Reference =

[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Product1.xml Product Service Description (XML)]

= Migration Guide =

All actions relating to configuration have been removed as part of the migration to the Davaar.

The domain for the Product service has changed to '''av.openhome.org'''.

== Actions ==
=== Changed Actions ===
====Standby====
The arguments have changed their names as follows:
*aStandby -> Value
====SetStandby====
The arguments have changed their names as follows:
*aStandby -> Value
====SourceCount====
The arguments have changed their names as follows:
*aSourceCount -> Value
====SourceXml====
The arguments have changed their names as follows:
*aSourceXml -> Value

====SourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value
====SetSourceIndex====
The arguments have changed their names as follows:
*aSourceIndex -> Value

====SetSourceIndexByName====
The arguments have changed their names as follows:
*aSourceName -> Value

=== New Actions ===
*Manufacturer
*Model
*Product
*Source
*Attributes
*SourceXmlChangeCount

=== Obsolete Actions ===
*SetName
*SetRoom
*SetStartupSourceIndex
*StartupSourceIndex
*SetStartupSourceIndexByName
*SetStartupSourceEnabled
*StartupSourceEnabled
*SetSourceVisible
*SetSourceName
*SourceAttributes

Developer:Davaar:Topology

2010-11-24T15:25:03Z

Grahamd: /* Topology - Room/Source */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.

Control points may optionally provide the user with control of the volume of each product within the tree.

Developer:Davaar:Topology

2010-11-24T15:24:48Z

Grahamd: /* Volume Control */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.

Control points may optionally provide the user with control of the volume of each product within the tree.

Developer:Davaar:Topology

2010-11-24T15:24:34Z

Grahamd: /* Volume Control */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.

Control points may optionally provide the user with control of the volume of each product within this tree.

Developer:Davaar:Topology

2010-11-24T15:22:32Z

Grahamd: /* Discovering An Openhome System */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be that situated nearest the root in the tree structure that contains the current source.

Developer:Davaar:Topology

2010-11-24T15:21:57Z

Grahamd: /* Proper Configuration */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product:1 service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be that situated nearest the root in the tree structure that contains the current source.

Developer:Davaar:Topology

2010-11-24T15:21:18Z

Grahamd: /* Products */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome installation consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using a audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product:1 service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be that situated nearest the root in the tree structure that contains the current source.

Developer:Davaar:Topology

2010-11-24T15:21:02Z

Grahamd: /* Functional Units */

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Products ===

An Openhome consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using a audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product:1 service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be that situated nearest the root in the tree structure that contains the current source.

Developer:Davaar:Topology

2010-11-24T15:20:47Z

Grahamd:

== Introduction ==

Openhome products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of Manufacturer or specific features.

The technologies associated with making this possible are grouped under the term Topology.

If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of Openhome Topology, which is described below

== Topology - Room/Source ==

=== Functional Units ===

An Openhome consists of products from a variety of manufacturers each bearing the [[Developer:Davaar:ProductService|Product service]].

Amongst other information, each product has:

* Room (user configurable, defaults to 'Main Room')

* Name (user configurable, defaults to the model name)

* Source Count (fixed according to the capabilities of the product)

* List of Sources, each with its own Type, Name, and Visibility

* Attributes, identifying additional functionality offered by the product

=== Proper Configuration ===

The name of each product represents its audio output.

The name of each source represents an audio input (either internal or external).

In a properly configured system, if one product is connected to another using a audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.

=== Discovering An Openhome System ===

The correct way to discover an Openhome system is to:

* search for all units bearing the Product:1 service

* subscribe to each Product service

* group these products according to their Room.

* collect the name of all the sources in each product

* match the names of the sources to the names of the products to create a set of tree structures in each room.

=== Source Functionality ===

To determine the kind of functionality available on each source, inspect its type.

If it has type Playlist, it additionally contains the [[Developer:Davaar:PlaylistService|Playlist service]]

If it has type Radio, it additionally contains the [[Developer:Davaar:RadioService|Radio service]]

If it has type Receiver, it additionally contains the [[Developer:Davaar:ReceiverService|Receiver service]]

=== Volume Control ===

Products that offer volume control include the Volume attribute and the [[Developer:Davaar:VolumeService|Volume service]]

The primary volume control offered by a control point should be that situated nearest the root in the tree structure that contains the current source.