RFC: "Demo Use Cases" documentation for the web page

RFC: "Demo Use Cases" documentation for the web page

[Darren Hart]

Media Network Demo
==================
We're looking to have a section on the web site for the demo that
explains what each use-case is and possibly how it can be replicated.
I'm taking the approach of describing each image. Consider the
following:

The Yocto Project launch event at ECLF 2010 featured a
multi-architecture Media Network Demo. All the source for this demo is
available in the meta-demo git repository as a layer for the poky build
system.

The following images made up the demo:
o poky-image-nas
o poky-image-mediatomb
o poky-image-rygel

poky-image-nas
--------------
The poky-image-nas image boots your device as a network attached storage
device. It provides a DHCP service and an NFS server. We used this image
to store all our media.

poky-image-mediatomb
--------------------
The poky-image-mediatomb image adds a UPnP content provider via the
mediatomb package. This image mounts the media share from the NAS and
makes it available to UPnP renderers.

poky-image-rygel
----------------
The poky-image-rygel image provides gupnp tools and the rygel media
renderer along with the sato desktop. The renderer can be controlled 
locally or via any control point on the network. Several devices can run 
this image and stream media from the mediatomb device.


Open Questions
--------------
o Is this more or less what we are looking for?
o Should we modify the mediatomb image to:
   o automatically mount a specific share from the NAS?
   o add something to the config to automatically scan the
     media share?
o The poky-image-rygel description needs to be updated as we finalize
   the package.



-- 
Darren Hart
Embedded Linux Kernel

Re: RFC: "Demo Use Cases" documentation for the web page

[Tian, Kevin]

>From: Darren Hart
>Sent: Friday, October 22, 2010 7:01 AM
>
>
>Media Network Demo
>==================
>We're looking to have a section on the web site for the demo that
>explains what each use-case is and possibly how it can be replicated.
>I'm taking the approach of describing each image. Consider the
>following:
>
>The Yocto Project launch event at ECLF 2010 featured a
>multi-architecture Media Network Demo. All the source for this demo is
>available in the meta-demo git repository as a layer for the poky build
>system.
>
>The following images made up the demo:
>o poky-image-nas
>o poky-image-mediatomb
>o poky-image-rygel
>
>poky-image-nas
>--------------
>The poky-image-nas image boots your device as a network attached storage
>device. It provides a DHCP service and an NFS server. We used this image
>to store all our media.
>
>poky-image-mediatomb
>--------------------
>The poky-image-mediatomb image adds a UPnP content provider via the
>mediatomb package. This image mounts the media share from the NAS and
>makes it available to UPnP renderers.
>
>poky-image-rygel
>----------------
>The poky-image-rygel image provides gupnp tools and the rygel media
>renderer along with the sato desktop. The renderer can be controlled
>locally or via any control point on the network. Several devices can run
>this image and stream media from the mediatomb device.
>
>
>Open Questions
>--------------
>o Is this more or less what we are looking for?

boards list used in this demo.

Also a simple figure is always more intuitive to catch the intention here. :-)

>o Should we modify the mediatomb image to:
>   o automatically mount a specific share from the NAS?
>   o add something to the config to automatically scan the
>     media share?
>o The poky-image-rygel description needs to be updated as we finalize
>   the package.
>

One thought is, could we convert this demo page into something more useful
as the collection for various use cases on Yocto which can be contributed by
any user, and then here UPnP is the 1st example?

Thanks
Kevin

Re: RFC: "Demo Use Cases" documentation for the web page

[Tom Zanussi]

On Thu, 2010-10-21 at 16:00 -0700, Darren Hart wrote:
> Media Network Demo
> ==================
> We're looking to have a section on the web site for the demo that
> explains what each use-case is and possibly how it can be replicated.
> I'm taking the approach of describing each image. Consider the
> following:
> 

This is a good start.  I don't know if this is the place to add it, but
I just wanted to capture the details of what I've done so far to get my
setup working.  For now mainly in case anyone else could use some hints
on how to get everything going...

Basically this is just what I did, and it may be completely wrong -
please do correct anything stupid and suggest improvements if you see
any - at this point I just want to get the basic stuff up and running so
I can pack it all up tomorrow night and not be too worried about not
having anything.

> The Yocto Project launch event at ECLF 2010 featured a
> multi-architecture Media Network Demo. All the source for this demo is
> available in the meta-demo git repository as a layer for the poky build
> system.
> 
> The following images made up the demo:
> o poky-image-nas
> o poky-image-mediatomb
> o poky-image-rygel
> 
> poky-image-nas
> --------------
> The poky-image-nas image boots your device as a network attached storage
> device. It provides a DHCP service and an NFS server. We used this image
> to store all our media.
> 

Rather than using the nas image, since all I have is a laptop and the
two atom boards, I decided to just do the simplest thing for now and
have my laptop host and serve up the images over nfs (I was thinking of
doing the nas image inside of say an arm qemu instance running on the
laptop, and may still if I get time, but as a simple approximation, this
will work.  All this is also just a fallback in case the real demo
system breaks down, so I'm not being too particular).

So on the laptop, install the nfs server and export the media files:

# apt-get install nfs-kernel-server

Put a bunch of music files somewhere - in my case I put some files in:

/home/trz/Music

Add a line to /etc/exports to export that directory:

/home/trz/Music	*(ro,sync,no_root_squash)

restart the nfs server:

/etc/init.d/nfs-kernel-server restart

Let's say the IP address the laptip got was 192.168.1.3.

> poky-image-mediatomb
> --------------------
> The poky-image-mediatomb image adds a UPnP content provider via the
> mediatomb package. This image mounts the media share from the NAS and
> makes it available to UPnP renderers.

ssh into the mediatomb board, in my case, this is a Black Sand, and
mount the exported media share:

# mount 192.168.1.3:/home/trz/Music /media/music

So now the mediatomb box has access to the files it's going to
advertise.  Let's tell mediatomb to do that.

Look in /var/log/mediatomb.log

You should see a line like this:

2010-09-08 10:50:03    INFO: MediaTomb Web UI can be reached by
following this link:
2010-09-08 10:50:03    INFO: http://192.168.1.3:49152/

Point a web browser at that URL and you should see the minimalistic
Mediatomb web interface.  Click on the 'Filesystem link' and you should
see somewhere in there your /media/music mount.  Click on that and you
should see all your music on the right-hand-side.  Click on the '+' and
that should add all your songs to mediatomb (watch out, there doesn't
seem to be any indication as to whether it succeeded or not - I had
duplicates show up in Mediatomb if I did that more than once - just like
iTunes, yeah!).

If you go the 'Database link', you should see a treeview with your songs
somewhere in there.  This is the same hierarchy you'll see and navigate
to play your songs in the rygel image 'AV control point'.

*Note, if mediatomb.log showed errors instead of the URL you need, it's
probably because eth0 didn't come up (working on a fix).  An ifup
eth0; /etc/init.d/mediatomb restart should fix that.

If that step was successful, you should now be able to see and play your
songs from another box...

> 
> poky-image-rygel
> ----------------
> The poky-image-rygel image provides gupnp tools and the rygel media
> renderer along with the sato desktop. The renderer can be controlled 
> locally or via any control point on the network. Several devices can run 
> this image and stream media from the mediatomb device.
> 

On the rygel image, open up a terminal and type:

# rygel

(the latest image takes awhile to display anything - it's not graphical,
will display a couple lines of text - one of which is an error message,
but the 'playbin' plugin should say it's available, and things should
still work.)

Navigate back to the Desktop and find the 'UpnP Universal Control Point'
and click on it.  That should open up a graphical UI showing available
data sources (but is not where you play media from)...

Navigate back to the Desktop and find the 'UPnP AV Control Point'.
Click on that, and you should see something more familiar, something
that looks like it can actually do something useful, which is play a
song.  Click on treeview in the app, and eventually you should see some
songs.  Click on a song, and hit the 'Play' button, and it should play
the song - it couldn't be easier!

NOTE: make sure you have speaker connected to the board you're rendering
the music on.  If that doesn't work, try opening a terminal window and
using amixer to play around with the volume e.g.:

amixer set Master on
amixer set Master 75

For extra credit, install gupnp-tools and try the AV Control Point from
your laptop, or any system - you should see the same media and should be
able to control it from anywhere.  Choose a different song and send it
to any other renderer running on any other box, etc.  The possibilities
are endless!

> 
> Open Questions
> --------------
> o Is this more or less what we are looking for?
> o Should we modify the mediatomb image to:
>    o automatically mount a specific share from the NAS?
>    o add something to the config to automatically scan the
>      media share?
> o The poky-image-rygel description needs to be updated as we finalize
>    the package.
> 
> 
> 

Re: "Demo Use Cases" documentation for the web page

[Stewart, David C]

>From: Darren Hart [mailto:dvhart@linux.intel.com]
>Sent: Thursday, October 21, 2010 4:01 PM
>
>
>Media Network Demo
>==================
>We're looking to have a section on the web site for the demo that
>explains what each use-case is and possibly how it can be replicated.
>I'm taking the approach of describing each image. Consider the
>following:

At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend.  I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.

I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.

>The Yocto Project launch event at ECLF 2010 featured a
>multi-architecture Media Network Demo. All the source for this demo is
>available in the meta-demo git repository as a layer for the poky build
>system.
>
>The following images made up the demo:
>o poky-image-nas
>o poky-image-mediatomb
>o poky-image-rygel

"Note that the goal of these recipes was to demonstrate example functionality and the flexibility and power of Yocto. The goal was not to produce a production-ready image."

What might be better here would be a little additional info with each of these. Some examples below.

>poky-image-nas
>--------------
>The poky-image-nas image boots your device as a network attached storage
>device. It provides a DHCP service and an NFS server. We used this image
>to store all our media.

"The filesystem called /<blah> is exported via nfsexport <or whatever>. To make use of this for our demo setup, put your *.mp3 or *.ogg files into the /<blah> directory. You need to make sure your system is on a network, and the TCP/IP stack is configured correctly to be visible by the other client systems."  

(I am sure you can fix this up to make it better).

>poky-image-mediatomb
>--------------------
>The poky-image-mediatomb image adds a UPnP content provider via the
>mediatomb package. This image mounts the media share from the NAS and
>makes it available to UPnP renderers.

"You need to edit <this file> to nfsmount the filesystem from the NFS server in the previous example or use a local disk or another file server."

>poky-image-rygel
>----------------
>The poky-image-rygel image provides gupnp tools and the rygel media
>renderer along with the sato desktop. The renderer can be controlled
>locally or via any control point on the network. Several devices can run
>this image and stream media from the mediatomb device.

"To activate the media renderer, type <something> at the command line as root." You get my drift.

Let's go through one more round on email with these enhancements and by then the wiki should be set up.

>
>Open Questions
>--------------
>o Is this more or less what we are looking for?
>o Should we modify the mediatomb image to:
>   o automatically mount a specific share from the NAS?
>   o add something to the config to automatically scan the
>     media share?
>o The poky-image-rygel description needs to be updated as we finalize
>   the package.
>
>
>
>--
>Darren Hart
>Embedded Linux Kernel

Re: "Demo Use Cases" documentation for the web page

[Dirk Hohndel]

On Fri, 22 Oct 2010 10:35:49 -0700, "Stewart, David C" <david.c.stewart@intel.com> wrote:
> >From: Darren Hart [mailto:dvhart@linux.intel.com]
> >Sent: Thursday, October 21, 2010 4:01 PM
> >
> >
> >Media Network Demo
> >==================
> >We're looking to have a section on the web site for the demo that
> >explains what each use-case is and possibly how it can be replicated.
> >I'm taking the approach of describing each image. Consider the
> >following:
> 
> At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend.  I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.
> 
> I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.

I think this is much more appropriate for the wiki, anyway.


-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: "Demo Use Cases" documentation for the web page

[Mark Hatle]

On 10/22/10 12:35 PM, Stewart, David C wrote:
>> From: Darren Hart [mailto:dvhart@linux.intel.com]
>> Sent: Thursday, October 21, 2010 4:01 PM
>>
>>
>> Media Network Demo
>> ==================
>> We're looking to have a section on the web site for the demo that
>> explains what each use-case is and possibly how it can be replicated.
>> I'm taking the approach of describing each image. Consider the
>> following:
>
> At this point, the site map is set, and we're working with the web guys to set this up for review today and over the weekend.  I'm loath to mess with the structure at this point, and adding something like this would require more than a page, it requires references, etc.
>
> I'm inclined to add a page to the new wiki once it is set up. (Scott is working on that now). Then we could add a link to the signage and on the Resources page.
>
>> The Yocto Project launch event at ECLF 2010 featured a
>> multi-architecture Media Network Demo. All the source for this demo is
>> available in the meta-demo git repository as a layer for the poky build
>> system.
>>
>> The following images made up the demo:
>> o poky-image-nas
>> o poky-image-mediatomb
>> o poky-image-rygel
>
> "Note that the goal of these recipes was to demonstrate example functionality and the flexibility and power of Yocto. The goal was not to produce a production-ready image."
>
> What might be better here would be a little additional info with each of these. Some examples below.
>
>> poky-image-nas
>> --------------
>> The poky-image-nas image boots your device as a network attached storage
>> device. It provides a DHCP service and an NFS server. We used this image
>> to store all our media.
>
> "The filesystem called /<blah>  is exported via nfsexport<or whatever>. To make use of this for our demo setup, put your *.mp3 or *.ogg files into the /<blah>  directory. You need to make sure your system is on a network, and the TCP/IP stack is configured correctly to be visible by the other client systems."
>

/media/storage is the export location...

> (I am sure you can fix this up to make it better).
>
>> poky-image-mediatomb
>> --------------------
>> The poky-image-mediatomb image adds a UPnP content provider via the
>> mediatomb package. This image mounts the media share from the NAS and
>> makes it available to UPnP renderers.
>
> "You need to edit<this file>  to nfsmount the filesystem from the NFS server in the previous example or use a local disk or another file server."
>
>> poky-image-rygel
>> ----------------
>> The poky-image-rygel image provides gupnp tools and the rygel media
>> renderer along with the sato desktop. The renderer can be controlled
>> locally or via any control point on the network. Several devices can run
>> this image and stream media from the mediatomb device.
>
> "To activate the media renderer, type<something>  at the command line as root." You get my drift.
>
> Let's go through one more round on email with these enhancements and by then the wiki should be set up.
>
>>
>> Open Questions
>> --------------
>> o Is this more or less what we are looking for?
>> o Should we modify the mediatomb image to:
>>    o automatically mount a specific share from the NAS?
>>    o add something to the config to automatically scan the
>>      media share?
>> o The poky-image-rygel description needs to be updated as we finalize
>>    the package.
>>
>>
>>
>> --
>> Darren Hart
>> Embedded Linux Kernel

Re: RFC: "Demo Use Cases" documentation for the web page

[Darren Hart]

On 10/21/2010 05:26 PM, Tian, Kevin wrote:
>> From: Darren Hart
>> Sent: Friday, October 22, 2010 7:01 AM
>>
>>
>> Media Network Demo
>> ==================
>> We're looking to have a section on the web site for the demo that
>> explains what each use-case is and possibly how it can be replicated.
>> I'm taking the approach of describing each image. Consider the
>> following:
>>
>> The Yocto Project launch event at ECLF 2010 featured a
>> multi-architecture Media Network Demo. All the source for this demo is
>> available in the meta-demo git repository as a layer for the poky build
>> system.
>>
>> The following images made up the demo:
>> o poky-image-nas
>> o poky-image-mediatomb
>> o poky-image-rygel
>>
>> poky-image-nas
>> --------------
>> The poky-image-nas image boots your device as a network attached storage
>> device. It provides a DHCP service and an NFS server. We used this image
>> to store all our media.
>>
>> poky-image-mediatomb
>> --------------------
>> The poky-image-mediatomb image adds a UPnP content provider via the
>> mediatomb package. This image mounts the media share from the NAS and
>> makes it available to UPnP renderers.
>>
>> poky-image-rygel
>> ----------------
>> The poky-image-rygel image provides gupnp tools and the rygel media
>> renderer along with the sato desktop. The renderer can be controlled
>> locally or via any control point on the network. Several devices can run
>> this image and stream media from the mediatomb device.
>>
>>
>> Open Questions
>> --------------
>> o Is this more or less what we are looking for?
>
> boards list used in this demo.

Hrm... do we want to explicitly call them out? The point is that it was 
multi-architecture, but for some to recreate it, the point is that it 
doesn't really matter what hardware they have - poky can build for any 
of them.

What do others think, should we mention the specific boards in use at 
the demo?

>
> Also a simple figure is always more intuitive to catch the intention here. :-)
>
>> o Should we modify the mediatomb image to:
>>    o automatically mount a specific share from the NAS?
>>    o add something to the config to automatically scan the
>>      media share?
>> o The poky-image-rygel description needs to be updated as we finalize
>>    the package.
>>
>
> One thought is, could we convert this demo page into something more useful
> as the collection for various use cases on Yocto which can be contributed by
> any user, and then here UPnP is the 1st example?

I'm not opposed to the idea, but for now, let's just make it a page 
where people can go and get more detail about what we did for the demo 
and get them started on replicating it if they should so choose.

>
> Thanks
> Kevin


-- 
Darren Hart
Embedded Linux Kernel

Re: RFC: "Demo Use Cases" documentation for the web page

[Alex deVries]

On 2010-10-22, at 4:22 PM, Darren Hart wrote:

>> boards list used in this demo.
> 
> Hrm... do we want to explicitly call them out? The point is that it was 
> multi-architecture, but for some to recreate it, the point is that it 
> doesn't really matter what hardware they have - poky can build for any 
> of them.
> 
> What do others think, should we mention the specific boards in use at 
> the demo?


Yeah, I think we should.  It proves that it really does run on other hardware, and the demo hw is the example.  Showing product names helps shake the image that this is IA-only.

- A


-- 
Alex deVries
Chief Linux Technologist
Wind River Systems

RFC V2: "Demo Use Cases" documentation for the web page

[Darren Hart]

Apologies for the resend, sent from the wrong address and the list 
bounced it.

Version 2 with some updates from Kevin, Dave, Tom, and Mark:

Media Network Demo
==================
The Yocto Project launch event at ECLF 2010 featured a
multi-architecture Media Network Demo. All the source for this demo is
available in the meta-demo git repository as a layer for the poky build
system.

The following images made up the demo:
o poky-image-nas
o poky-image-mediatomb
o poky-image-rygel

Note that the goal of these recipes was to demonstrate example
functionality and the flexibility and power of Yocto. The goal was not
to produce a production-ready image.


poky-image-nas
--------------
The poky-image-nas image boots your device as a network attached storage
device. It provides a DHCP service and an NFS server, which exports
/media/storage out of the box. Adding your MP3 or OGG format music files
under this directory will make them available to other devices on your
LAN. As presently configured, it assumes an address of 192.168.1.1 and
offers DHCP addresses in the 192.168.1.128 - 192.168.1.254 lease block.

poky-image-mediatomb
--------------------
The poky-image-mediatomb image adds a UPnP content provider via the
mediatomb package. Note that you will have to update your networking
scripts to suit your system and network. For the demo, we simply added
"auto eth0" to /etc/network/interfaces and got a DHCP address from the
NAS. After modifying the networking, be sure to restart the mediatomb
service (or just reboot). You can configure it to mount the
/media/storage share from a poky-image-nas system (as we did), or store
your media locally. Use the mediatomb web interface to add music to the
database and make it available to UPnP renderers. See
/var/log/mediatomb.log for the address and port:

2010-09-08 10:50:03    INFO: MediaTomb Web UI can be reached by 
following this link:
2010-09-08 10:50:03    INFO: http://192.168.1.3:49152/

poky-image-rygel
----------------
The poky-image-rygel image provides gupnp tools and the rygel media
renderer along with the sato desktop. The renderer is started on boot
via an init script and can be controlled locally or via any control
point on the network. Several devices can run this image and stream
media from the mediatomb device. To use a local control point, locate
the "UPnP AV control" under the "Utilities" category of the sato
desktop. Expand "Mediatomb" in the treeview and you should see a
familiar music navigation hierarchy.  Select a song and hit the "Play"
button. If you have multiple renderers on the network, you can select
which one to control with the renderer drop-down.


-- 
Darren Hart
Embedded Linux Kernel

Re: RFC: "Demo Use Cases" documentation for the web page

[Darren Hart]

On 10/22/2010 02:04 PM, Alex deVries wrote:
>
> On 2010-10-22, at 4:22 PM, Darren Hart wrote:
>
>>> boards list used in this demo.
>>
>> Hrm... do we want to explicitly call them out? The point is that it was
>> multi-architecture, but for some to recreate it, the point is that it
>> doesn't really matter what hardware they have - poky can build for any
>> of them.
>>
>> What do others think, should we mention the specific boards in use at
>> the demo?
>
>
> Yeah, I think we should.  It proves that it really does run on other hardware, and the demo hw is the example.  Showing product names helps shake the image that this is IA-only.

OK, so can someone provide me with an appropriate list of the non-IA 
platforms? I know them as "The MIPS board" "The PPC board" etc.

-- 
Darren Hart
Embedded Linux Kernel

Re: RFC: "Demo Use Cases" documentation for the web page

[Mark Hatle]

On 10/22/10 5:04 PM, Darren Hart wrote:
> On 10/22/2010 02:04 PM, Alex deVries wrote:
>>
>> On 2010-10-22, at 4:22 PM, Darren Hart wrote:
>>
>>>> boards list used in this demo.
>>>
>>> Hrm... do we want to explicitly call them out? The point is that it was
>>> multi-architecture, but for some to recreate it, the point is that it
>>> doesn't really matter what hardware they have - poky can build for any
>>> of them.
>>>
>>> What do others think, should we mention the specific boards in use at
>>> the demo?
>>
>>
>> Yeah, I think we should.  It proves that it really does run on other hardware, and the demo hw is the example.  Showing product names helps shake the image that this is IA-only.
>
> OK, so can someone provide me with an appropriate list of the non-IA
> platforms? I know them as "The MIPS board" "The PPC board" etc.
>

arm - beagleboard (I don't know the revision)
ppc - fsl-mpc8315e-rdb
mips - Ubiquity Networks Router Station Pro a.k.a. MIPS Linux Starter Kit

Re: RFC: "Demo Use Cases" documentation for the web page

[Mark Hatle]

On 10/22/10 5:17 PM, Mark Hatle wrote:
> On 10/22/10 5:04 PM, Darren Hart wrote:
>> On 10/22/2010 02:04 PM, Alex deVries wrote:
>>>
>>> On 2010-10-22, at 4:22 PM, Darren Hart wrote:
>>>
>>>>> boards list used in this demo.
>>>>
>>>> Hrm... do we want to explicitly call them out? The point is that it was
>>>> multi-architecture, but for some to recreate it, the point is that it
>>>> doesn't really matter what hardware they have - poky can build for any
>>>> of them.
>>>>
>>>> What do others think, should we mention the specific boards in use at
>>>> the demo?
>>>
>>>
>>> Yeah, I think we should.  It proves that it really does run on other hardware, and the demo hw is the example.  Showing product names helps shake the image that this is IA-only.
>>
>> OK, so can someone provide me with an appropriate list of the non-IA
>> platforms? I know them as "The MIPS board" "The PPC board" etc.
>>
>
> arm - beagleboard (I don't know the revision)
> ppc - fsl-mpc8315e-rdb

Figured I should expand this..

Freescale MPC8315E-RDB  (I think w/ have the 'A' revision, but thats not likely 
important)

> mips - Ubiquity Networks Router Station Pro a.k.a. MIPS Linux Starter Kit
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.pokylinux.org/listinfo/yocto