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

[Jan Ceuleers]

Oskar,

(Note that I'm copying the list).

Oskar Liljeblad wrote:
> On Thursday, April 06, 2006 at 19:46, Jan Ceuleers wrote:
>
> Hi Jan!
>
> > 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).
>
> Yeah, it's sending out the wrong value for upnp:class... contentdir.c
> would need to be patched appropriately too. I'll add this to the TODO!

I'll have a look at this over the weekend (but it's been years since I 
did any serious development work).

> > - 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).
>
> Are you using id3lib or TagLib? The latter is a little better at reading
> tags, IMHO.

Both are compiled in; don't know which-one gets used.

I note that changes have already been made in the 0.11 candidate in this 
area; I'll wait for those to become available.

> > - 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).
>
> Interesting. I would like to reduce the footprint of GMediaServer if
> possible, but I think (hope) it's pretty low at the moment... I'm
> sure it can be improved though.

I'll do some more digging in order to confirm the actual memory needs of 
the application. Perhaps what I'm seeing is a side effect (perhaps 
linked to the fact that I'm NFS mounting the content directory, etc.)

I have noticed (through studying strace output) that the scanning 
involves a stat(), open(), mmap(), llseek(), read(), ..., close(), 
unmmap(), brk() sequence. That looks quite tidy. I'll look at the source 
to see how the memory actually gets allocated (and how the amount of 
memory that is allocated gets decided on).

> > - 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.
>
> Yes, I'd like to see some kind of caching implemented in GMediaServer.
> I'm not sure how it would be designed and implemented though...
>
> > - 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.
>
> Also planned :)... Hopefully for the near future...
>
> > 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.
>
> I'm glad you find GMediaServer useful. :) Thanks for your input.
> (And remember, patches are always welcome!)
>
> Regards,
>
> Oskar

Regards, Jan