First, many thanks for the work you've done on this. Hope I can help in the future. Here's my first experiences with 0.7:
Some install problems:
- installed upnp, but was not clear (either from upnp or mediatomb readme) that you need to separately build & install all three parts of that lib (ixml, threadutil, upnp). The error messages in mediatomb's configure could be more helpful here.
- mediatomb readme says "filemagic" is required, but was not clear (to me) from mediatomb readme that this is actually unix file(1) (available from ftp.gw.com/mirrors/pub/unix/file, and elsewhere)
- I didn't have Python -- had to install that too -- a bit frustrating since it seems it's only used for the install script?
But after those relatively minor problems, the server:
- installed & configured itself;
- ran on my setup;
- allowed me to browse the filesystem and database, and add and delete media to and from the database;
- connected to my client device (D-Link DSM-320 on wireless, via a D-Link router)
- allowed me to browse the server database through the DSM-320.
BUT (a more serious problem):
- trying to play any media on the DSM-320 caused a hard lockup on the device. (Could only resolve by cutting power).
Any suggestions? The device works with D-Link's server.
Thanks again for your work, and I look forward to further developments!
first of all - thanks for trying out the server and thanks for your feedback!
>- installed upnp, but was not clear (either from upnp or
> mediatomb readme) that you need to separately build &
> install all three parts of that lib (ixml, threadutil, upnp). The
> error messages in mediatomb's configure could be more
> helpful here.
well, actually when you do make, make install for the SDK it should build and install all three libraries.
As mentioned in the readme it forgets to install ixml.h... but I guess you are right, a better desciprtion for installing the UPnP SDK will for sure not hurt, especially since you really need it to run the server. I also think about putting rpm's of it online to make life easier... btw what distributoin are you using?
>- mediatomb readme says "filemagic" is required, but was
> not clear (to me) from mediatomb readme that this is
> actually unix file(1) (available from ftp.gw.com/mirrors/pub/unix/file, and elsewhere)
ok, will add that to the readme
>- I didn't have Python -- had to install that too -- a bit frustrating since it seems it's only used for the install
well yes.. I'm just not such a great shell scriptor :) we also assumed that most people would have python installed anyway since lots of distros use python scripts for their purposes.
>BUT (a more serious problem):
>- trying to play any media on the DSM-320 caused a hard
>lockup on the device. (Could only resolve by cutting power).
indeed not nice... could you please make an ethereal capture of the network traffic while you reproduce the problem?
it may reveal some information...
I will take a look for this D-Link server to see what exactly it delivers and what the differences to us are, is it available for free download?
We tested the server with a Philips Streamium and I did not observe any real issues there. I am not familiar with a DSM-320 but I will ask around if anyone in my surroundings has one so we can try to reproduce and solve the problem.
Thanks again for your feedback!
Ok, I got a DMS-320 in front of me, it was quite a pain to get it running (it had some old firmware) but after uprading it to 1.05 i could finally do some testing.
Well... I can confirm your findings - it indeed crashes, but - and here is the funny part - before even sending out the http get request! This is quite odd, because browsing seems to work nicely, but as soon as you press enter it just dies and the network is silent.
I will install their server tomorrow and have a look at their DIDL-Lite XML to see if there is something unusual there that they excpect, but to be honest it looks more like a bug on the D-Link side - tests with other devices worked out nicely, I also could not find anything suspicious by looking at the server with the IntelTools.
Anyway... let's see, maybe there is still something I could do. Have you tested the DSM against other servers? There is quite a bunch out there, would be interesting how many of them work and how many fail, maybe the problem is more general.
...to be continued :)
OK, I know what the problem with the DMS-320 is.
They can't handle an object.item upnp class.
I looked at their server and tried entering object.item.audioItem.musicTrack for the upnp class on mediatomb (that is the value used on the d-link server for audio) - then everything worked fine.
We will think of a flexible and configurable way to allow upnp:class settings... so expect an updated version that takes care of this problem. However, D-Link should be notified of the probolem, from UPnP point of view there is nothing wrong with object.item, the mime-type is important. I will mail them about that issue, thanks again for your feedback!
That's good news Jin -- thanks very much for tracking it down so quickly. Look forward to the updated version with workaround. Hopefully this is a special case and you won't have to write custom code to deal with bugs in every player out there!!
(Incidentally, I also tried the TwonkyVision server -- the free version -- and it does work, but as you probably know it's audio-only and a lot of other functionality is excluded (and it's closed-source), but just thought I'd let you know as another data-point.)
OK, it's done, please take a look. Luckily this special case did not require any ugly hacks and we were able to fix it in quite a clean manner. For the DSM-320 it is important to have the upnp classes of the items as specified in the config file. Since it goes along with the UPnP spec it should not introduce any problems with other players, so we included those settings as default.
About Twonky.. yes, I do know it, but as you mentioned - it's not opensource. Besides, we don't feel like waiting for someone to put in a feature we would like to have - that was also one of the reasons why we decided to write our own server :)
Thanks again for pointing out the DSM-320 problem, please report any other issues you may encounter.
Release 0.7.1 now rocks with my DSM-320 :)
One question though ..
When i try to start mediatomb in background with "mediatomb &" or using ctrl-z and "bg" the UI does not respond anymore ..
Is this a bug or intended to be this way ?
Nice that it works with the DSM now :) Allthough there is one thing: we allow adding any content to the server (so also normal data files, not just av-media), the mimetype is properly set by our server so we give the players the information on what it is, still the DSM can not handle that - it freezes when you try to play anything that has a different upnp class then what it expects. I reported the issue to D-Link, so let's see if it gets fixed.
About the background issue... indeed, it's not running in the background. We never tested that.. so I can't say that it was done on purpose :) For now just run the server inside a screen session, that for sure works.
I can also confirm 0.7.1 works with my D-Link DSM-320 (using 1.05ww firmware). Thanks for the quick fix!
Now I'll give some thought to what should go on the wishlist...
Hit another problem (but also have a solution).
Most of my music is ogg vorbis (which the DSM-320 can play). However, it seems that when you add .ogg files to the MediaTomb database, they take mime type "application/ogg" and therefore UPnP Class "object.item." Unfortunately, as noted above, this kills the DSM-320 when played.
So (easy solution): within the Mediatomb interface hand-edit the UPnP Class for each ogg vorbis file to replace "object.item" with "object.item.audioItem"
Or (better solution): edit the Mediatomb config.xml file to include the following line within the mappings section:
<map from="application/ogg" to="object.item.audioItem"/>
(There might be a still better solution whcih is that ogg vorbis .ogg files could be recognised as mime type "audio/vorbis" rather than "application/ogg"? I realise this can get complex since .ogg is a container for multiple types. Anyhow, solution 2 above works well for me at present).
well, that is exactly the reason why we decided to make it configurable: other players may have different issues, other firmware may expect other values - now the user can always adapt the configuration to his needs.
I will add the ogg mimetype to the distribution config file, so it will be mapped to the appropriate upnp class by default.
About mimetype recognition: we use the unix file utility (filemagic) to set the mimetype, so there is nothing we can do here, the recognition is done in libmagic. Also, I am not sure what the mimetype for ogg is supposed to be - if you look at /etc/mime.types you will see that it's indeed application/ogg. You also have to be carefull with the mimetypes, because players use them to recognize the media and start the appropriate codec.
However we plan to add another feature, which will also speed up the process of addding data to the server: file extension to mimetype mappings.
It will work in the same manner as the mimetype-upnpclass mapping - you will do something like <map from="*.mp3" to="audio/mpeg"/> but of course you then should be sure that the mimetype you set is correct - else the player may also run into problems.
Thanks again for reporting! You help us to improve the server :)