[gmediaserver-devel] I'm using gmediaserver with a Philips SLM5500

[Jan Ceuleers]

Oskar,

I thought I'd let you know that I'm using gmediaserver 0.10.0 with a
Philips (Streamium) SLM5500 box. This device is truly an AV renderer, in
that it supports not only audio but also stills and video.

Some feedback which I hope will be of some use to you:

- This is stating the obvious, but gmediaserver supports only audio file
formats. I don't quite understand why that is the case, but I'm
*guessing* that adding additional file types should be easy. I tried
patching gmediaserver myself, by adding jpg as a supported file type,
only to find that this caused my photos to show up on the Philips box
under the Audio tab (so clearly there is some work to be done on the
meta data side of things as well, even though I thought I'd also put in
the correct mime id).

- A second point is that gmediaserver seems to be quite fragile when it
comes to parsing tags within mp3 files. In order to avoid having a
sizeable number of my mp3 collection ignored by gmediaserver I've had to
patch it to accept serving any file that has an .mp3 file extension
(rather than drop them on the floor). This works fine. (By the way: this
means that I have to use ushare (on a different port) for my photo
library, further adding to the problems raised in my next rant. I'm not
using ushare for my music library because it seems to have its own
problems, including being somewhat picky about file and directory names).

- Due to a limitation in the UPnP architecture I find myself having to
run gmediaserver on an underpowered platform (a Soekris net4801 box).
The limitation I'm talking about is that (as I'm sure you know) the UPnP
discovery functionality only works within a broadcast domain. My main
server (which I would prefer to use as the content server) is connected
to my wired ethernet, whereas the Philips box is (or would ideally be)
connected wirelessly. For security reasons I don't want my wired and
wireless networks to be bridged together, so that I have resorted to
using a Soekris box as the wireless client, NFS mount the content
directory and run gmediaserver on it, and then connect that by wired
ethernet to the Philips box. The reason why I'm mentioning this to you
is that this setup makes it puts gmediaserver's memory requirements in
the spotlight, to the extent that I've had to enable NFS swapping over
the wireless link in order to keep the Soekris box from running out of
memory (clearly not good for either speed or stability). This is the
case even if I tell gmediaserver not to bother scanning the tags.
(In case you're not familiar with Soekris boxes, mine has a 266MHz
Pentium-class CPU with 128MB RAM and a CompactFlash card instead of a
hard disk).

- I'm sending gmediaserver a SIGUSR1 signal whenever something has
changed in the content directories, which causes gmediaserver to rescan
as expected. However, this rescan takes several minutes on my setup
(about 3700 mp3 files), during which time the renderer is left in limbo.
This problem is not apparent if I connect the renderer directly to my
main server (a much faster machine) and run gmediaserver there, since
the rescan only takes a few seconds. I'm mentioning this since you may
not have come across this issue in testing. I'm naively wondering
whether it would be possible for gmediaserver to continue serving
requests during the rescan, and for the rescan to take the shape of a
"patch" to the existing metadata, rather than the zero-based approach
that I believe is currently employed.

- Another feature request: it would be great if gmediaserver were
capable of building additional indices facilitating browsing and playing
content by artist, album, genre, etc.


Please be assured that I am extremely grateful for your efforts and for
the results so far. I am hoping that the constructive intent of my
feedback will properly come across to you.

Thanks and best regards,


Jan Ceuleers
Brussels, Belgium