I have noticed that when the DSM-320 is started, the discovery of Mediatomb does not work as flawless as it does with the D-link Mediaserver.
I have looked at the traffic with Ethereal and the reason of the problem seems to that the only way Mediatomb reveals itself, is by broadcasting keep-alive messages (at the interval stored in <SERVER>/<ALIVE>). When
DSM-320 is started it initially says "No Servers found" and you have to wait for a while before Mediatombs "alive" messages are detected and the server becomes selectable. Setting Mediatomb as default server in DSM-320's setup does not help.
When running DSM-320 against D-links Mediaserver the contents become browseable immediately. The reason for this seems to be that the D-link Mediaserver uses another way of getting in contact with DSM-320. It does not send any keep-alives at all, instead it answers the DSM-320:s discovery requests. In Ethereal you can see that a couple of UDP-packets are sent as reply by D-links Mediaserver and the packets seem to contain standard UPNP-information. However, these kind packets are not sent at all by Mediatomb.
Does anyone know why the reply packets aren't sent by Mediatomb? Isn't this kind of replies a standard feature of UPNP, or is there something non-standard about this communication that requires patching of libupnp?
If we get the reply-functionality working in Mediatomb, it would also be nice to be able to prevent the keep-alive broadcast loop in Mediatomb. For example: if -1 is entered in <SERVER>/<ALIVE> the UpnpSendAdvertisement()-function shouldn't be called at all.
Assuming that your network interface is eth0 enter the following commands on the machine that is running MediaTomb:
route add -net 22.214.171.124 netmask 255.0.0.0 eth0
ifconfig eth0 allmulti
After that MediaTomb will answer to incoming M-SEARCH requests.
Now, regarding the "advertisement broadcast loop" - this is required by the UPnP specification, all UPnP devices have to broadcast periodic alive messages.
Did the multicast configuration help?
On my computer Mediatomb is started using the included init.d-script. Inside the script I have set $INTERFACE to eth1, which is my internal interface, so the route should already be set up properly. I don't think there's any problem here since Mediatomb is listening on the correct, internal IP-adress (everything but the discovery works).
Could there be some problem with my firewall configuration? I'm using Firestarter and have configured the firewall to allow traffic to any address/port from 192.168.0.xxx (My internal network uses those adresses, the DSM-320 has 192.168.0.252). The firewall is also configured for masquerading in order be give the computers on the internal network Internet access. I haven't seen any messages about blocked packets in the firewall. Could it be possible that the firewall tries to forward the multicast-packets to the external interface or something?
Do you know if it is necessary to add any additional rules/configuration to the firewall? Or if there is something else that must be done when having two interfaces on the same server?
About the alive-broadcasting:
I understand that it may be "violating" the specification, however I have a good reason for wanting to be able to override it: The computer I'm using as server is a bit old. Normally playing movies and music with Mediatomb works just fine, but the alive-broadcasting sometimes causes a problem. When the server starts broadcasting there's a lot of harddrive activity for a about two seconds. I don't know why sending data on the network causes disk access, I couldn't see any signs of this in the libupnp sourcecode, but it's a fact. This sometimes causes glitches in the movie/music that is being played, which is of course very annoying. Since the D-link media server doesn't seem to send the alive messages and the DSM-320 seems to do fine without them, I would like to disable the alive-messages. It shouldn't do any harm to give the advanced users the possibility to turn the alive broadcasting off. What do you think?
unfortunately I have no idea about "firestarter", I use a custom iptables script; make sure that UDP port 1900 is open, that's where SSDP is operating
if you use the provided init.d script the multicast foute should indeed be set; you can of course try to set it manually just to be sure..
if you run ethereal on your server, do you see the incoming M-SEARCH requests from the DSM-320?
I also have a setup with two network interfaces and masquerading/firewall, but I have not experienced any difficulties yet, apart from setting the multicast route and specifying the correct interface to use I did not have to do anything to make it work. But again, I do not
know anything about this "firestarter" firewall,
so can't tell if it is messing things up or not.
about alive broadcasting: it is indeed strange that an alive broadcast is causing harddisk activity, I do not know how exactly it is implemented in the SDK, maybe you have not enough RAM and your PC starts swapping? I really don't know. There is however a problem with disabling the alive notifications - it is done in the SDK and would require a patch and thus a custom libupnp version.
I think that we can do this when we move the libupnp sources into our source tree, so we will not depend on an external libupnp package but will be able to modify the SDK as we see fit.
We already have a number of requests which we can not solve at the moment due to the SDK, so this step will take place.
For now you could try to use a very high alive value in the config.xml, so the notifications happen as seldom as possible.
P.S. sorry, still did not come to looking at the .srt issue :)
I think Firestarter actually uses IPTables in the background. After some digging I found some log entries that indicated that the multicast packets were dropped somewhere, and after some more digging in the configuration/rule files of Firestarter i found a line that looked suspicous. Since there is no way to control these details in the Firestarter GUI, I added an extra rula manually.
I haven't had the time to test things thoroughly, but when I did a quick test, the DSM-320 actually seemed to find Mediatomb much faster than before. I'll do some more testing, but I think it helped. Maybe it could be added in the readme-file's section about multicast routes, that the firewall must allow input for destination 239.x.x.x on the internal interface.
Like you mentioned, I can enter a large value in config.xml as a workaround to avoid the alive-broadcasts. However I took a quick look at Mediatombs source code, and I don't thing it would be that difficult to control the alive broadcasting. The line
ret = UpnpSendAdvertisement(device_handle, alive_advertisement);
seems to be the source that triggers the whole loop, and UpnpSendAdvertisement doesn't seem do anything more than sending the alive messages. So I think it would work to simply skip that call when desired. The easiest way would probably be by wrapping those lines up like this:
if (alive_advertisement != -1)
ret = UpnpSendAdvertisement(device_handle, alive_advertisement);
if (ret != UPNP_E_SUCCESS)
throw UpnpException(ret, "upnp_init: UpnpSendAdvertisement failed");
P.S. I hope we can get the subtitles working soon. And I also hope that D-link will improve the avi/xvid handling in the DSM-320 firmware soon. Avi/xvids often looks "jerky", while for example vob-files look a lot better.
>Maybe it could be added in the readme-file's >section about multicast routes, that the firewall >must allow input for destination 239.x.x.x on the >internal interface.
good idea, I will do that! actually I plan to finally write a howto and also put some more info on our project page.
>However I took a quick look at Mediatombs source >code, and I don't thing it would be that
>difficult to control the alive broadcasting.
oh, indeed! actually my memory was telling me that the whole SSDP system was fired up by this, but I think you are right. I must have remembered this incorrectly. I have to make a quick test, if it works out I will add that feature to the next release.
Regarding avi playback: you do use the DSM-320 patched version of libupnp, right?
I'll take a look at the D-Link server (regarding .srt) this Sunday, however I do not have a DSM-320 here, still I might find something on UPnP level.
I gave this another thought, and I think that removing advertisements completely will not work as we thought.
Let's summarize your scenario: the DSM-320 issues an M-SEARCH request to look for mediaservers, MediaTomb responds. In the response there has to be a timeout value (UPnP spec). This timeout value has an important meaning: if the servers fails to send an alive advertisement before the timeout has expired, all other UPnP devices (in that case the DSM-320) have to remove it from their list.
That means, when you disable the alive notification the server will simlpy disappear from the DSM-320 list after a certain timeout.
Now, that of course is theory - and will happen if the DSM-320 follows the UPnP spec.
I will have to try it at work and see what happens, if the server will indeed disappear or not. If the DSM-320 follows the spec correctly, then disabling the alive advertisements will not be something that we want to do. It may solve the problem you are having, but it will create another one..
When I looked at the traffic between DSM-320 and D-link Mediaserver with Ethereal I didn't see any alive broadcasts from that Mediaserver. I didn't think about looking inside the headers sent out by D-links Mediaserver, but it would be interesting to see what timeout value it uses.
My suggestion isn't to have a version of Mediatomb with the alive broadcasting disabled, just to add the possibility to manually disable it through the <alive>-parameter, then everyone can do as they like (good for testing purposes too). But I think you're right about the fact that the timeout in the replies should match the alive-broadcasting timeout, and what timeout value should be used if you don't want to broadcast alives at all? Perhaps there's some "infinity" value that could be used. But for now it seems to work ok for me with a high value (31536000 seconds).
About the "jerky" avi playback:
Yes, I'm using the patched version of libupnp. The problem has occured with every xvid-encoded file I've tried. DVD-mpegs (.vob-files) often works better, but some of them can also stutter (maybe related to the compression level?). The problem is worst when the camera zooms or pans fast. However I don't think it's a transfer speed problem, since vob-files that have higher bitrates than divx-files still looks better (and I use a 100 mbps hardwired connection). So either the DSM-320 has problems with the decoding, or possible it uses some unsuitable retrieval method. I think I read in a board somewhere that avi/xvids are fetched using (too) small chunks(?).
Have you tried playing avi/xvid files, or do you have any other interesting information on this? Could it be possible to "tune" Mediatomb in some way that could improve things (even though most of this performance seems to depend on the firmware)?
This actually leads me to another question: process priority. I have noticed that it's quite easy to cause glitches in the playback, for example just by moving a window or starting a program in Gnome. It doesn't feel right that things like that gets higher priority than Mediatombs network communication. I've done some experementing with "renice" on the mediatomb process, but I really don't know much about process controlling. It seems you can control priority either by calling functions directly in the sourcecode, or from the shell e.g. when a program is launched.
Maybe something could be added to the Mediatombs init.d-script that boosts the priority of the process and its subprocesses? Do you how these things can/should be controlled?
I got your idea about the parameter, and we can add that for testing, I just think that it may solve one problem by creating another.
As far as I know there is no "infinity" value in the UPnP spec, so that won't be possible.
Regarding jerky .AVI playback: if an .avi file plays back fine from the D-Link MediaServer but is jerky when streaming from MediaTomb - that's what the libupnp patch is for. D-Link use some custom HTTP headers (not related to UPnP) to enable certain features on the client side and request data in a different manner.
But of course you may encounter files which are jerky on any server - simply because the decoder on the DSM-320 is not fast enough to handle various bitrates. I have the same problem on the Streamium, where some video files are simply too much for the device. It's not about network load, it's really about decoding.
Regarding the "tuning" of MediaTomb on HTTP level - this all happens in the Intel SDK, so that is the place to start if any improvements are to be made to the integrated webserver. Btw, I also made an attepmt to choose better settings for the webserver, that's what the libupnp config.patch is doing.
Now, regarding priority: you could try to renice the whole mediatomb process group and see if it helps. To be honest I did not play around with it yet. You seem to be really on the edge with your hardware, if I recall correctly you are using a very slow PC? I once installed MediaTomb on a Pentium 100MMX notebook with 64MB RAM, I have to admit that I did not do too extensive tests but it worked out nicely. But then of course, I did not have Gnome running on that machine :)
You could however do an interesting test.
Install apache and try streaming a video from the Apache server instead of MediaTomb, see if the glitches still occur. Would be interesting to know.
My computer speed isn't that bad (P3 500 256MB if I remember correctly). But I guess having Gnome installed occupies some extra resources. Even if there's no one in front of the computer there are always some Gnome stuff running in the background. But that would be ok if only the system gave Mediatomb (and other servers) better priority.
Did your "tuning" of libupnp give any improvements? I'm not very familiar with building stuff from sourcecode, with patches and makefiles and stuff. I'm not even sure I have all the compilers, headers and devel-packages that would be necessary. So I can't do that kind of testing right now... I'm also a bit unsure about renice/nice, the documentation is a bit unclear. Is it positive or negative values that boosts the priority? Can you give me a good example on how to use renice or nice?
Regarding test of video streaming through Apache:
I actually tried to stream an avi-file through apache by adding an "external link"-item in Mediatomb. However for some reason it didn't work, the DSM-320 just hung when I tried to start the movie. I have successfully been able to open shoutcast streams on the Internet via "external link"-items. Do you have any idea why the avi movie wouldn't work?
I know that you usually can't stream avi movies when you open them in a regular browser like Internet Explorer, you have to wait until the movie is finished. Only mpeg-files can be streamed directly. Can there be a similar issue with my DSM-320 test with Apache? But in that case, what is it that Mediatomb does that makes avi streaming work? I also think it would be interesting to see how Apache would handle the streaming. I use to connect to my home server from work were I listen to mp3:s that are streamed directly from Apache to Winamp by regular http, and it works very good. Do you have any ideas what needs to be done to be able to test avi-streaming through Apache via Mediatomb?
Well, a P3 500 should indeed be enough, it is strange that even when noone is in front of the PC it is still lagging. I know Gnome can eat up resources, but it is strange that it affects movie download/streaming... it's just a basic read operation. Now regarding priority and renice:
negative values mean higher priority, you need to be root to send negative priority values, also make sure not to choose the "fastest one (-20)", strange things may happen if system processes are not allowed to run in time.
So, assuming that the PID of your running mediatomb server is 12345 you could try:
renice -5 -g 12345
Not sure if it will help though...
About the "tuning" of libupnp:
I made two changes. One change improve the reaction of the webserver when trying to download two files simultaniously. Without the config.patch it took quite a while for a second request to start, so this is now improved.
Then we have a second patch, it is related to the DSM-320 - it adds a specific header to the HTTP requests, based on that header the DSM-320 acts differently when requesting .avi files.
Now, regarding Apache:
the DSM-320 hung because you probably forgot to specify the correct upnp class of the item, it is a known bug in the DSM-320 firmware.
Take a look at this post for some details on external link items:
You may also want to take a look at this thread, regarding this "special" DSM-320 header:
If you want to try apache with .avi files, you will probably have to add this header as well. You can use the Apache module "mod_headers" to do this. In your httpd.conf, inside the <Directory> section (of the directory where you are serving the data from) add the following:
Header add X-User-Agent "redsonic"
Btw, regarding your question about .avi streaming: the mediarenderers use the range request to seek to the end of the file and get the avi index.
Let me know how it goes :)
It's been a while since my last post. I did test streaming via Apache but forgot to write about it. I found out why the DSM-320 hung while trying to open the movie. When I wrote the URL to my web server in the external link in Mediatomb, I didn't include any port number since I assumed that the DSM-320 would default to port 80 when using http. However it didn't. When I checked with Ethereal, I discovered that it used port 0. So i added a :80 to the URL and things started working.
Then I added the redsonic header (successfully i hope) to the Apache configuration. However the results where very similar to the performance when using Mediatomb. The jerkiness in avi playback seems to depend mostly on the DSM-320 itself.
BTW, any progress with srt-files and DSM-320 yet?
Well, you can see in ethereal if you added the header correctly - you should see the redsonic string in the HTTP response.
Regarding the subtitles:
sorry I did not yet have the time to look at it, currently we are very busy preparing the next release and we have more work than we can handle, so it will take some time :)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.