Helpme1986
Posts: 121
Joined: Tue Jan 03, 2012 3:48 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 12:54 pm

intraclast wrote:Good news! Got it sorted. :D A change of power supply has sorted it, its still 5v 1000ma, but this one works. Unfortunately its not mine so I'll have to get another one that works.

Thanks again!
Glad you found the issue :D dam dodgy power supplies!

arun
Posts: 8
Joined: Tue May 15, 2012 8:59 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 4:54 pm

First of all it's great that the swapfile header error message on startup is gone since r11039.

I have compared Openelec and Raspbmc now. There is one very big difference in the loading time (ex Youtube Plugin). Raspbmc is much faster here. Can anybody confirm this? Maybe it's because of the different types of SD I use, but I really don't think so.

User avatar
frying_fish
Posts: 80
Joined: Mon Jan 23, 2012 3:26 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 6:06 pm

So, I'm still running 10954, haven't updated in a few days.

I have finally managed to get my NAS setup with all the 3TB worth of videos on there. Currently the NFS sharing with that is not working quite how I would want it to, so I'm using SMB (I know higher overheads).

Apart from taking an age for the scrapers to update everything (expected really), and trakttv taking a while to sync all the watched flags, all seems to be running smooth now.

Using the XBMC remote app, perfect for getting at everything, and seems a lot less laggy than my IR remote (and more functional).

I will endeavour to see how some old xvid encoded files play (I've only tried my x264 encoded files so far), but I've not noticed any playback problems. The menus have been a bit laggy, but that could just be while it is updating all the libraries and such. I'll see how the menus perform later on after the final batch have been updated.

1 tip I've found so far is that need to keep the fanart off, putting the fanart on and it ground to a halt a lot, so after turning that off I've not had any problems.

Has anyone tried any different skins? Do they perform better? I'll get on with compiling a more recent version (after checking out the commits)

intraclast
Posts: 12
Joined: Sat May 19, 2012 6:40 am

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 7:09 pm

Hi, me again.

I've searched and searched but cannot find answer to this, but I think I must be doing something wrong, else there would be more posts about this wouldn't there?

I've been watching a h264 encoded HD video (looks awesome, v impressed!) the audio track is AAC encoded 5.1 and xbmc has detected that and shows it as such in the video info. However, I'm only getting 2.0 across my HDMI feed to my receiver. I've got the follow settings under Audio Output:

Audio Output - HDMI
Speaker config - 5.1
Boost volume level on downmix - on
Dolby digital compatible receiver - on
DTS capable receiver - on
Audio output device - hdmi (OMX)
Passthrough output device - hdmi (OMX)

I've tried turning the receiver settings off, but it didn't change anything, and I've tried restarting after changing settings, just in case.

I've tried another video thats in 5.1 and it does the same, and also I tried a 2.0 video to make sure that xbmc reported it correctly as such (which it did).

I've also tried more than one input on the receiver.

Have I missed something obvious?

Thanks in advance!

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 9:34 pm

Anybody having issues with images/accessing the db - upgrading to the latest xbmc-rpi may help. Instructions are here:
http://forum.xbmc.org/showthread.php?ti ... pid1106893
But you also might have to modify

Code: Select all

GIT_REPO="-b master [email protected]:xbmc/xbmc-rbp.git"
to

Code: Select all

GIT_REPO="git://github.com/xbmc/xbmc-rbp.git"
at the top of

Code: Select all

OPENELEC-SOURCE/tools/mkpkg/mkpkg_xbmc-rpi
Also, per the above link, if you want to get the bleeding edge XBMC-
"XBMC for RPi is a different git repo to the main XBMC [ed - right, I know] and is not as up to date so you may need to look at the XBMC master commits and apply relevant commits to XBMC for RPi...

In OpenELEC, to use the latest XBMC code from master, you need to build OpenELEC with XBMC=frodo. "
That last bit is likely to be a process so I'm not going there right now...

mactalla
Posts: 17
Joined: Fri Dec 09, 2011 6:25 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sat May 19, 2012 11:29 pm

intraclast wrote:... the audio track is AAC encoded 5.1 and xbmc has detected that and shows it as such in the video info. However, I'm only getting 2.0 across my HDMI feed to my receiver. I've got the follow settings under Audio Output:
[...]
Dolby digital compatible receiver - on
DTS capable receiver - on
Those options in XBMC for passthrough are only for AC3 (Dolby Digital) and DTS. There is no option to pass AAC through undecoded. I'm not even sure if many/any receivers can natively handle AAC. After confirming that mine can only do AC3 and DTS but no AAC I've opted to track down whatever files have an AAC track and convert it to AC3.

I would think that XBMC should decode AAC and preserve the surround sound -- perhaps re-encode it on the fly as AC3 5.1. But it doesn't seem to do that and I'm not certain whether the RPi CPU could do that in real time as it cannot offload the work to the GPU.

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 1:46 am

mactalla wrote:
intraclast wrote:... the audio track is AAC encoded 5.1 and xbmc has detected that and shows it as such in the video info. However, I'm only getting 2.0 across my HDMI feed to my receiver. I've got the follow settings under Audio Output:
[...]
Dolby digital compatible receiver - on
DTS capable receiver - on
Those options in XBMC for passthrough are only for AC3 (Dolby Digital) and DTS. There is no option to pass AAC through undecoded. I'm not even sure if many/any receivers can natively handle AAC. After confirming that mine can only do AC3 and DTS but no AAC I've opted to track down whatever files have an AAC track and convert it to AC3.

I would think that XBMC should decode AAC and preserve the surround sound -- perhaps re-encode it on the fly as AC3 5.1. But it doesn't seem to do that and I'm not certain whether the RPi CPU could do that in real time as it cannot offload the work to the GPU.
Right, so I don't think it's passing the AAC off to the receiver or that it should be - like you said, it's probably decoding on the box but being mistakenly (or by design?) downmixed. Maybe something to bring up at the XBMC forums, although apparently much of the changes to the next version of xbmc are audio-related

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 5:49 am

LastSilmaril wrote:Anybody having issues with images/accessing the db - upgrading to the latest xbmc-rpi may help. Instructions are here:
http://forum.xbmc.org/showthread.php?ti ... pid1106893
...
So I just tried compiling without AirTunes and AirPlay support (edit projects/RPi/options) and it failed when it came to linking together xbmc.bin. I'm not sure if this is something limited to building with a later xbmc or something that happens with vanilla builds of OpenELEC.
This isn't the first time I've run into something like this - compiling without vorbis encoder support also fails as vorbis.c and vorbis.h are still needed for something else (the decoder I guess?).

Maybe these things need to be disabled in xbmc too somehow?

intraclast
Posts: 12
Joined: Sat May 19, 2012 6:40 am

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 7:14 am

mactalla wrote:Those options in XBMC for passthrough are only for AC3 (Dolby Digital) and DTS. There is no option to pass AAC through undecoded. I'm not even sure if many/any receivers can natively handle AAC. After confirming that mine can only do AC3 and DTS but no AAC I've opted to track down whatever files have an AAC track and convert it to AC3.

I would think that XBMC should decode AAC and preserve the surround sound -- perhaps re-encode it on the fly as AC3 5.1. But it doesn't seem to do that and I'm not certain whether the RPi CPU could do that in real time as it cannot offload the work to the GPU.
Thanks mactalla & LastSimaril - that makes sense. You're right my receiver can't decode aac, and nor would I expect it to (although it would be nice!). I've got myself muddled between the two :) I'll pop over to XBMC and see if there is anything about the downmixing to 2.0, although as you say it may be too much to expect this little board to do!

Thanks again.

pezholio
Posts: 13
Joined: Sun Mar 04, 2012 7:31 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 7:18 am

Hi all,

I'm beginning to look into building and installing OpenELEC on my Pi, but am on a Mac. I've got Ubuntu installed via Parallels, but there doesn't seem to be proper SD card support in Parallels (you can use your SD card as a shared folder, but it doesn't mount as a disk drive). My question is therefore, can I prepare the SD card on my Mac easily (I tried using Disk utility a while back when I first got my Pi, but it didn't work), or is there another way I can get my Parallels VM to recognise my SD card?

Cheers

mactalla
Posts: 17
Joined: Fri Dec 09, 2011 6:25 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 5:35 pm

pezholio wrote:can I prepare the SD card on my Mac easily?
Probably the easiest would be to grab a .img file that people have uploaded earlier in this thread and use dd to image your SD card from your Mac. That will create the partitions for you. After that to upgrade to the version that you built, just overwrite the files in the System partition of the SD card. (Note that KERNEL from the build process needs to be renamed to kernel.img)

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 7:01 pm

pezholio wrote:Hi all,

I'm beginning to look into building and installing OpenELEC on my Pi, but am on a Mac. I've got Ubuntu installed via Parallels, but there doesn't seem to be proper SD card support in Parallels (you can use your SD card as a shared folder, but it doesn't mount as a disk drive). My question is therefore, can I prepare the SD card on my Mac easily (I tried using Disk utility a while back when I first got my Pi, but it didn't work), or is there another way I can get my Parallels VM to recognise my SD card?

Cheers
You might want to invest in a USB 2.0 SD Reader like this one for dd'ing reliably and the ability to pass control of the SD over to the VM (besides the general convenience). when you make your build, make sure you specify the 'release' parameter like so:

Code: Select all

PROJECT=RPi ARCH=arm make release
Then you'll want to untar the resulting tar.bz2 file, get in there and run

Code: Select all

sudo./create_sdcard [linuxdevicename]
which will create the SD for you with a card of any size (but practically speaking a card smaller than 1GB won't work). [linuxdevicename] will probably be /dev/sdb unless you have a USB key or something else connected to and controlled by your VM.

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Sun May 20, 2012 8:13 pm

LastSilmaril wrote: Then you'll want to untar the resulting tar.bz2 file, get in there and run

Code: Select all

sudo./create_sdcard [linuxdevicename]
Small typo, there should be a space between 'sudo and the next command:

Code: Select all

sudo ./create_sdcard [linuxdevicename]

milhouse
Posts: 634
Joined: Mon Jan 16, 2012 12:59 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 6:02 am

For anyone using MySQL storage, I've been doing some reading and it seems the recommended approach is to use the MySQL database to store the shared metadata, but then use a local database/cache on each client for thumbnail storage (cover art, fan art etc.) .

As far as I can tell, this means that path substitution is generally frowned upon, so don't store thumb images on the network. XBMC will automatically grab thumbs from the internet as it needs them (ie. when viewed, or in the background) since the source URL (eg. "http://cf2.imgobject.com/t/p/w500/6sASq ... RecPD2.jpg", or a network image location within your media library) will be held in the central MySQL database. The XBMC client will then store the resized images it grabs locally in its cache (the Thumbnails folder), and update the local Textures12 database with the image details thus mapping movies/tv shows/music/etc. to the cached images.

So when configuring a new XBMC client, all you need to do is:

1) Add the video (and optionally music) database settings to advancedsettings.xml
2) Optionally (to save a tiny amount of space) delete the local Database/MyVideos* (and optionally Database/MyMusic*) database(s) that are no longer required
4) Reboot

I had thought that "sharing" a common network-based thumbnail folder would mean it was no longer necessary for each client to re-download each thumbnail image, but without the Textures database being present in MySQL (not supported - not sure if there any plans to support in future) this means each XBMC client has no knowledge of the network based thumbs.

One solution might be to sync each XBMC client with a "master" copy of Textures12.db but this isn't recommended and very hack-ish (though it might be a solution to get a new client "off the ground" with all images present, but probably not a long term solution).

One other reason not to use network-based thumbnails is that the design of XBMC in some places tends to assume local storage is being used, and can thus make a lot of "stat" calls (file information, directory walking etc.) which can, when occurring across a network SMB/NFS connection thanks to path substitution, incur an unintentionally significant overhead compared with local storage. Optimisations are being made to improve the disparity between local and network storage, but for now local would be the preferred choice if you want maximum performance.

So I've reverted back to local SD card-based thumbnail storage with my central MySQL video/music database, which is all fine as long as your SD card is big enough: my main Revo 3700 XBMC player with 514 movies, 34 tv shows/1538 episodes is running at just under 3.5GB thumbnail storage (all movies and tv shows have full cover art/fan art etc.).

pezholio
Posts: 13
Joined: Sun Mar 04, 2012 7:31 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 10:08 am

mactalla wrote: Probably the easiest would be to grab a .img file that people have uploaded earlier in this thread and use dd to image your SD card from your Mac. That will create the partitions for you. After that to upgrade to the version that you built, just overwrite the files in the System partition of the SD card. (Note that KERNEL from the build process needs to be renamed to kernel.img)
Brilliant, thanks. I'll give that a crack :)

pezholio
Posts: 13
Joined: Sun Mar 04, 2012 7:31 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 10:09 am

LastSilmaril wrote:
You might want to invest in a USB 2.0 SD Reader like this one for dd'ing reliably and the ability to pass control of the SD over to the VM (besides the general convenience). when you make your build, make sure you specify the 'release' parameter like so:

Code: Select all

PROJECT=RPi ARCH=arm make release
Then you'll want to untar the resulting tar.bz2 file, get in there and run

Code: Select all

sudo./create_sdcard [linuxdevicename]
which will create the SD for you with a card of any size (but practically speaking a card smaller than 1GB won't work). [linuxdevicename] will probably be /dev/sdb unless you have a USB key or something else connected to and controlled by your VM.
Ah, cool. That might be doable too. Cheers :)

arqcan
Posts: 8
Joined: Tue May 15, 2012 8:23 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 4:56 pm

milhouse wrote:For anyone using MySQL storage, I've been doing some reading and it seems the recommended approach is to use the MySQL database to store the shared metadata, but then use a local database/cache on each client for thumbnail storage (cover art, fan art etc.) .

As far as I can tell, this means that path substitution is generally frowned upon, so don't store thumb images on the network. XBMC will automatically grab thumbs from the internet as it needs them (ie. when viewed, or in the background) since the source URL (eg. "http://cf2.imgobject.com/t/p/w500/6sASq ... RecPD2.jpg", or a network image location within your media library) will be held in the central MySQL database. The XBMC client will then store the resized images it grabs locally in its cache (the Thumbnails folder), and update the local Textures12 database with the image details thus mapping movies/tv shows/music/etc. to the cached images.

So when configuring a new XBMC client, all you need to do is:

1) Add the video (and optionally music) database settings to advancedsettings.xml
2) Optionally (to save a tiny amount of space) delete the local Database/MyVideos* (and optionally Database/MyMusic*) database(s) that are no longer required
4) Reboot

I had thought that "sharing" a common network-based thumbnail folder would mean it was no longer necessary for each client to re-download each thumbnail image, but without the Textures database being present in MySQL (not supported - not sure if there any plans to support in future) this means each XBMC client has no knowledge of the network based thumbs.

One solution might be to sync each XBMC client with a "master" copy of Textures12.db but this isn't recommended and very hack-ish (though it might be a solution to get a new client "off the ground" with all images present, but probably not a long term solution).

One other reason not to use network-based thumbnails is that the design of XBMC in some places tends to assume local storage is being used, and can thus make a lot of "stat" calls (file information, directory walking etc.) which can, when occurring across a network SMB/NFS connection thanks to path substitution, incur an unintentionally significant overhead compared with local storage. Optimisations are being made to improve the disparity between local and network storage, but for now local would be the preferred choice if you want maximum performance.

So I've reverted back to local SD card-based thumbnail storage with my central MySQL video/music database, which is all fine as long as your SD card is big enough: my main Revo 3700 XBMC player with 514 movies, 34 tv shows/1538 episodes is running at just under 3.5GB thumbnail storage (all movies and tv shows have full cover art/fan art etc.).
i've only just set up a mysql database, but every new build of xbmc creates a new database file and from what i can see i can't sync with different versions, any ideas?

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 5:07 pm

milhouse wrote:For anyone using MySQL storage, I've been doing some reading and it seems the recommended approach is to use the MySQL database to store the shared metadata, but then use a local database/cache on each client for thumbnail storage (cover art, fan art etc.) .

As far as I can tell, this means that path substitution is generally frowned upon, so don't store thumb images on the network. XBMC will automatically grab thumbs from the internet as it needs them (ie. when viewed, or in the background) since the source URL (eg. "http://cf2.imgobject.com/t/p/w500/6sASq ... RecPD2.jpg", or a network image location within your media library) will be held in the central MySQL database. The XBMC client will then store the resized images it grabs locally in its cache (the Thumbnails folder), and update the local Textures12 database with the image details thus mapping movies/tv shows/music/etc. to the cached images.

So when configuring a new XBMC client, all you need to do is:

1) Add the video (and optionally music) database settings to advancedsettings.xml
2) Optionally (to save a tiny amount of space) delete the local Database/MyVideos* (and optionally Database/MyMusic*) database(s) that are no longer required
4) Reboot

I had thought that "sharing" a common network-based thumbnail folder would mean it was no longer necessary for each client to re-download each thumbnail image, but without the Textures database being present in MySQL (not supported - not sure if there any plans to support in future) this means each XBMC client has no knowledge of the network based thumbs.

One solution might be to sync each XBMC client with a "master" copy of Textures12.db but this isn't recommended and very hack-ish (though it might be a solution to get a new client "off the ground" with all images present, but probably not a long term solution).

One other reason not to use network-based thumbnails is that the design of XBMC in some places tends to assume local storage is being used, and can thus make a lot of "stat" calls (file information, directory walking etc.) which can, when occurring across a network SMB/NFS connection thanks to path substitution, incur an unintentionally significant overhead compared with local storage. Optimisations are being made to improve the disparity between local and network storage, but for now local would be the preferred choice if you want maximum performance.

So I've reverted back to local SD card-based thumbnail storage with my central MySQL video/music database, which is all fine as long as your SD card is big enough: my main Revo 3700 XBMC player with 514 movies, 34 tv shows/1538 episodes is running at just under 3.5GB thumbnail storage (all movies and tv shows have full cover art/fan art etc.).
Thanks for the info. I guess I'll be using the 8GB card for this going forward. In the meantime, I've still got a backup image of an older build that uses myvideos61 and doesn't have any image issues if I get too desperate. More likely I'll just use it as a dumb file-browser client without all the trimmings :)

milhouse
Posts: 634
Joined: Mon Jan 16, 2012 12:59 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Mon May 21, 2012 8:09 pm

arqcan wrote:i've only just set up a mysql database, but every new build of xbmc creates a new database file and from what i can see i can't sync with different versions, any ideas?
All clients should be using the same version of XBMC (eg. Dharma, Eden, Frodo etc.), in which case they'll all share the same database (and be "in sync").

Since OpenELEC is under heavy development it's likely that it will continue to change database schema and thus automatically upgrade your database from time to time, meaning clients on older versions will be "left behind" - this is unavoidable until things settle down in the not too distant future (ie. later in the beta cycle or once you are on a "stable" release).

funnel
Posts: 48
Joined: Sat May 05, 2012 8:00 am

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Tue May 22, 2012 12:38 pm

Anybody knows how the get airplay working to send a video stream from ubuntu to openelec+xbmc? Any tips or tutorial?

Blokie
Posts: 5
Joined: Sun Apr 29, 2012 9:23 am

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Tue May 22, 2012 4:51 pm

milhouse wrote:
arqcan wrote:i've only just set up a mysql database, but every new build of xbmc creates a new database file and from what i can see i can't sync with different versions, any ideas?
All clients should be using the same version of XBMC (eg. Dharma, Eden, Frodo etc.), in which case they'll all share the same database (and be "in sync").

Since OpenELEC is under heavy development it's likely that it will continue to change database schema and thus automatically upgrade your database from time to time, meaning clients on older versions will be "left behind" - this is unavoidable until things settle down in the not too distant future (ie. later in the beta cycle or once you are on a "stable" release).
All you need to do is to add the tag

Code: Select all

<name>MyVideos60</name>
to your <videodatabase> section of advancedsettings.xml and it will then use that database. Depending on which version of XBMC is your "base" version, you might need to rename the above to whatever your MySQL database is called. Add the above to all instances of XBMC and away you go. As suggested above, I would recommend using only one flavour of XBMC or you may end up corrupting things....

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Tue May 22, 2012 10:40 pm

In case anybody is following the most recent commits, it seems like this optimization has been enabled for a few libraries:
http://en.wikipedia.org/wiki/Prelinking
Cool beans

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Tue May 22, 2012 10:47 pm

Ooh, and apparently rebooting works now. That's nice...wonder how long that's been the case though, haven't tried in a while.

User avatar
fodi
Posts: 112
Joined: Wed Mar 14, 2012 9:03 pm
Location: Hungary

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Tue May 22, 2012 11:03 pm

how can i add extra video scripts/plugins for xbmc?
i have found one on github, that is not in the official repos, and i just can't figure out how to add it to my openelec/xbmc

milhouse
Posts: 634
Joined: Mon Jan 16, 2012 12:59 pm

Re: OpenELEC meets Raspberry Pi - part 1 (XBMC)

Wed May 23, 2012 1:08 am

Blokie wrote: All you need to do is to add the tag

Code: Select all

<name>MyVideos60</name>
to your <videodatabase> section of advancedsettings.xml and it will then use that database. Depending on which version of XBMC is your "base" version, you might need to rename the above to whatever your MySQL database is called. Add the above to all instances of XBMC and away you go. As suggested above, I would recommend using only one flavour of XBMC or you may end up corrupting things....
This information is not correct - the <name> tag is there to allow you to change the default name used by a client from "myvideos" to something else, but XBMC will always add a numeric version suffix so if you did name your database "myvideos60" in advancedsettings.xml, XBMC would simply create a database called "myvideos6063", and when the next schema database update comes along it will then upgrade that database to "myvideos6064".

Basically, the <name> tag is completely redundant for most users and shouldn't be specified in advancedsettings.xml at all unless the user has some specialist requirement for an XBMC client (eg. to use a particular database name with a specific user profile, eg. <name>kidsvideos</name> in the profile used by your kids - this will create/use/upgrade a database called kidsvideos60 etc.).

Return to “Media centres”