Is there anyone else that have tried to get subtitles working with the DSM-320 using Mediatomb?
With firmware version 1.06 and above the DSM-320 supports subtitles using .srt-files. The D-link Mediaserver seems to treat these files in some special way since I have not gotten srt-files to work using Mediatomb. I put the srt-file in the same folder as the movie and gave it the same basename, but with an srt extension. But when the movie was played there were no subtitles.
I did some packet sniffing on the network, but didn't have time for any deep analysis. I noticed however that the mimetype used was "application/octet-stream", so I changed this in mediatomb. But the subtitles were still ignored...
I don't know if some special sort of "object.item"-type is expected. As far as I could tell from the sniffing, the DSM-320 didn't even try to request the srt-file. So it seems the DSM-320 determines if subtitles should be from the browse-data.
Does anyone else know something about this?
You could try the following thing:
download Intel UPnP tools (free download from the intel site) and browse the server using Device Spy, browse the video file which also has associated subtitles and look at the browse XML - is the server providing the .srt file as an additional resource?
I have a lot of work at the moment, so a bit too busy, but I can try to take a look at it over the weekend. I should probably also add subtitle support for Philips Streamium devices.
I tested "Device Spy", but I wasn't sure about how the browse methods should be invoked. Instead i used the "AV Media Controller" which could browse the contents of the D-Link Media Server.
The movies did have extra resource fields, however the field were not unique for movies that had an srt-file. The fields contained general information about resolution, duration, codec etc, but nothing that could be related to a hint about subtitles. The fields for movies that had subtitles looked the same as fields for moves without subtitles.
I did some more network sniffing. However it's quite difficult to follow the communication, since Ethereal can't identify the individual requests inside the keep-alive connection and instead displays everything as raw TCP-data. But if I'm not mistaken I think i saw a request for an srt-file, when I played a movie that did not have an srt-file at all. The DSM-320 seemed to make a "blind" request and got a "HTTP file not found" message back from the media server.
The problem is that when communicating with Mediatomb, the DSM-320 doesn't seem to make the same kind of blind request as it did when talking to the D-Link Media Server. I could not see any srt request at all when I sniffed the communication between DSM-320 and Mediatomb.
So, the most probable assumption would be that the DSM-320 makes the blind request based on something that is not directly related to the presence of srt-files, but rather on some other information that differs from what Mediatomb returns. It could be the presence of the resource files with resolution, duration etc., or it could be that the returned mime types for movies differs between D-links Media Server and Mediatomb. If changing these things doesn't help, maybe another possibility is to "disguise" Mediatomb, by making Mediatomb identify itself with the same information as D-links Media Server does.
Jose Bernardo B R Silva
Any advance on this? I've tried to see subtitles on my DSM320RD, and I only get those using dlink's media server. I've even tried "upgrading" my firmware from 1.01eu to 1.03 us, and still no good, subtitles only show using the original media server. All I got was that now the FF/Rev keys only work with dlink's media server or twonkymedia, and are broken both with Mediatomb and ushare. I'm trying installing tversity now in windows to see if it helps, but I'd rather not have a windows machine on my wifi network.
I will have to look at the ethereal data, I hope I will find some time during the weekend to setup the D-Link MediaServer. It is very well possible, that they implemented something "outside" of the UPnP standard; we already know that they use special HTTP headers (that is why we had to patch libupnp in order to fix the .AVI playback problem), so I assume something similar is in place when it comes to subtitles. I'm sure we can figure it out :>
ok, I looked at the D-Link Media Server; it does not advertise the .srt features via UPnP, but it provides the .srt file for download.
So, for example, if the link of the video file is:
you can request
and will get the .srt file (of course if it exists on the server).
that means, that the DSM-320 somehow figures out that it is dealing with the D-Link server and simply makes a request for an .srt file.
Now, I see two problems.
First, we have to figure out how to make it think that we are the D-Link server, so it makes the erquest for the .srt
Second thing is somewhat more complicated.
We do not have filenames in our links, only object id's and some resource information. So the question is: how will the DSM-320 interpret our URL and where will it try to append the .srt ending (if at all). It is difficult to tell right now, because I do not have a DSM-320 here, but we have a unit at work, so I will have a closer look with ethereal. We already know about the redsonic headers (for avi playback), so probably there is something similar for srt.
Your conclusions are about same as mine. The first question is what feature of the server that "triggers" the DSM-320's request for the srt file. Have you tried adding those extra resources, that you can see on the D-link Mediaserver (duration, size etc.), to the files? When testing with a single file you could hardcode those values for that particular file, just to see if the resources have anything to do with the srt-request.
When it comes to the issue with D-link's filenames versus Mediatombs object id's:
Maybe it would be worth testing how DSM-320 reacts if Mediatomb sends a link with a proper filename instead of a resource id, just to see how that affects DSM-320's willingness to request the srt-file. If this would be the case, then how difficult would it be to let Mediatomb use filename links for video files?
I haven't looked at mediatombs database structure or the browsing logic, but I suppose the filename is stored with the rest of the information for every file? Is the reason for using the object ID:s instead of filenames to achieve faster searches on the server or is there some other reason?
I've been thinking of another thing when it comes to navigation. When browsing for example music on Mediatomb there are two options: you can either open the "Audio" container and browse the files based on various properties (mostly based on their ID3-tags), or you can open the PC Directory-folder, where you have to find your music files among all other types of files.
D-links Mediaserver has a feature that works as a mix between those two kinds of navigation, and I think it's quite useful. The main categories Audio, Video etc. each have a sub folder that preserves the directory names on the disk, like "PC Directory" in Mediatomb. However, it only displays the files that belong to the main category you're under (Audio, Video etc.). It's very good when you want to be able to browse the directorys like they look on disk, but showing only the files of a certain category. And you would also avoid some problems with the DSM-320 if you could browse files that way.
Let's say that I use the current "PC-directory"-functionality on Mediatomb to navigate to a directory that contains the songs on an album. In this directory an album cover image is also stored. If I select the directory name with the remote and press play, the DSM-320 normally starts playing the contents of that directory. However if there are mixed file types in this directory the DSM-320 can get very cranky and hang. And even if it wouldn't hang, I still wouldn't want the DSM-320 to suddenly display the album cover instead of playing the next song.
Do you think it would be possible to implement folders-under-each-category functionality without too much trouble?
to be honest - I did not look at the subtitle problem further yet. The main problem is that I do not own a DSM320 and my possibilities using it at work (we have a unit there) are often limited because.. well - too much work :)
After the release of the next version we are planning to write to some manufacturers and ask for sample units, I think this is the only way to provide maximum compatibility - you need to have a device in front of you in order to figure everything out.
But back to the topic... for testing you could add an internal or an external link item and use the item name in the URL. Then check if it makes the request. By the way, you do use a libupnp version that sends out the "redsonic" header? I would switch to libupnp 1.4.1 from http://pupnp.sf.net/, it has some improvements.
Now, regarding filenames vs. object ID's - it is much faster to use integer object ID's than string filenames. What we could do is, to add an option to add the filename to the link and append the usual parameters to it - the question is, if the DSM320 will accept this or not. Another possibility would be to use the Content-Disposition HTTP header and see if the DSM320 can make any use of it.
Regarding the navigation structure:
please take a look at the scripting-intro.txt and scripting-dev.txt files in the mediatomb/doc directory. Also take a look at import.js that comes along with MediaTomb. You can write your
own import scripts and create a custom server
layout - this functionality is already provided
in the 0.8.1 version.
Could you please try the external link thing and tell me if the DSM320 requests an .srt file then?
If it works, could you then try adding dummy parameters to the link (something like we use ?object_id=123&res_id=0) to see if it in any way impacts the DSM-320 behaviour?
Just a note, I'm a different user - I'm not the one using apache, that's Anders, I just started trying to use the DSM320RD I got with mediatomb, found out it wouldn't display DVDs, and decided to check. Finding this thread, I thought I should add to it instead of starting a new one.
But I'll take a look at the scripts, the kind of structure Anders proposes makes sense to me.
I'm using libupnp 1.4.1 already, and I'll check tonight adding a external URL.
DVD - yo mean .vob files? Check what mimetype was set for those files; I think it should be set to video/mpeg, also do not forget to set the correct upnp class (look at your config.xml) because the DSM320 used to crash when uppn:class was set to something it could not recognize.
Sorry, I messed up that message. I meant DVD ripped to Divx, and not VOB, but instead .srt. I've tried merging them with the video using yamb in my windows machine, but then the DSM320RD hangs trying to download the .m4a resulting file - probably because it has the same bug as the 320 and can't recognize the class.
try to add the appropriate mapping in your config.xml, similar to the .avi mappings, just map from .m4a or whatever you got
are you sure the DSM320 can play those m4a files at all?
Well, since they are mpeg4 video and aac audio, it should play them. And once again I messed up, m4a are the pre-merge music files, I meant mp4.
well anyway, have you tried setting the appropriate upnp:class?
for video the DSM320 expects "object.item.videoItem"
...and don't forget the correct mimetype of course :)
I finally setup a DSM320 for testing here and spent some hours trying to figure out what it needs in order to make the request.
Unfortunately I still do not know what it is looking for - it is not making the request for .srt with MediaTomb.
has anyone else made some new findings on that topic? I think it would be easy to add .srt support once the http request is made, so I would very much like to add this to the upcoming 0.9.0 release.
Jose Bernardo B R Silva
What setup do you want me to do to detect what is happening? I can try to run twonkimedia and capture some packets to see what happens, as with twonkimedia ff and rewind work - but subtitles don't. The only way I could get subtitles to work was to use the dlink software, in windows...
Give me a rundown on the setup you prefer (what software to use for capture, etc.) and I'll try to do it next weekend.
Hmm.. well, since subtitles do not work with Twonky I do not think that twonky-captures will help us. Do you know any other server, besides D-Link, which enables the use of subtitles on the DSM-320? If yes we could compare this server and D-Link server and look for similarities, and also compare them to non-subtitle-enabled servers like Twonky or MediaTomb.
Ethereal/Wireshark works best for captures. But again... it only makes sense if you find another server that supports subtitles for the DSM-320. I do have a working DSM-320/D-Link server setup now, but could not yet figure out why the DSM-320 is not making the request for the subtitles.
Jose Bernardo B R Silva
I'll start my hunt for servers again. Also, it is time to pressure D-link again so that they release the correct source of the DSM* firmware under the GPL - what they have now on their site is the firmware for a router renamed to appear to be that of the DSMs.
I wrote to D-Link support asking about substitle request information, couple of weeks passed and no reply so far. Too bad I did not realize that wycc (the guy who told us about the redsonic header) was actually from the Redsonic company - they made the DSM-320 firmware. I was trying to reach him but unfortunately I was not successful. It also seems that Redsonic no longer exists, and apparently they are "Zensonic" now - the Zensonic Z400 which is sold in Australia also needs the redsonic headers. I will try to reach someone from Zensonic and see if we can get any information from them.
Regarding the firmware... I looked at it once, actually I was hoping to find something realted to UPnP so I could figure out the subtitle issue. Unfortunately there was nothing related to UPnP in the released package. I did not look so close, that I could say it's a router firmware... After all, if the UPnP part of the application was not using any GPL code - they do not have to release that.
Anyway, I think if more users are interested in getting this feature to work and start bugging D-Link about it - we might get an answer. Until then we'll have to continue to play around and see if we can find a solution ourselves.
I've written to email@example.com about the gpl violations in July, and they got a answer from d-link claiming that it would be fixed soon. I'm right now sending FSF a new email asking if they got news from D-Link.
Interesting... I would indeed like to see the code.
Today I got the answer from D-Link support... basically they said that it would be better if I call technical support and talk to a live technician.
I doubt that anyone from the support line had anything to do with DSM320 development, usually they deal with end-user questions; so I am not sure if such an overseas call would be a good idea.
Jose Bernardo B R Silva
I had exactly that same answer, I'd say it is a form email for all "pesky gpl guys"... And I'm in Europe as you are, so I didn't even bother. We'll see if the fsf has more clout. Anyway, I'm still afraid that in the end it will be a "tivo" situation, where we can get the code but not the keys needed to sign the firmware.
Jose Bernardo B R Silva
/me admits to being blind
The GPL parts of the firmware are there - but no redsonic bootloader, no mediaplayer application source, no xml menus, only the kernel, busybox and a few other apps. What threw me off was that there are two root dirs - one for the basic redsonic "securesoho2" setup, the other under set/DMA with the specifics for the DSM320RD.
This means that the "meat" of the DSM320 media player is not GPLed and we have another "tivo" here...
well, I did look at their firmware image and could not find anything interesting. the DSM-320 app itself is proprietary and did not reveal any information regarding the subtitles.
btw I got further answers from D-Link support, basically they told me that the information I was seeking was confidential and that it could not be disclosed to individuals. If I was representing a company I should write them a written request which would then be reviewed, and also that the received information (if they decided to reveal anything) could only be used within the company.
Bottom of the line is - we will have to figure this one out ourselves.