I can't see anyone else here that has brought this up yet - Is there a reason why I will get a pause every 15 seconds or less with MediaTomb when playing back .MPG and .AVI files? It is like the DSM is re-syncing with MediaTomb. I tried uShare and Fuppes, and this pause doesn't happen.
I'd like to use MediaTomb however since it seems to serve the correct file lengths to the DSM. uShare and Fuppes will only show a video length as being only 1 hour for a 2 hour show (almost 4 GB file) and I am guessing that they are having issues with the files being over 2 GB in size. MediaTomb however shows the 2 hour length correctly.
One more thought, it happens on both AVI and MPG files. I tried a smaller 700 MB AVI and it still pauses every 15 seconds or so. Playback of music is fine however, as is viewing of photos.
Hardware is - Dlink DSM-520 with the brand new 1.04 firmware. MediaTomb is being served from a Gentoo installation that is running on a KuroBox-HG NAS (266 MHz PPC, 128 MB RAM).
Anyone have any ideas on this one? Any help in this regard will be appreciated!
PS. Was using TwonkyMedia demo prior to MediaTomb, and Twonky also works fine.
well, this issue has been discussed a lot of times.
Scroll down to the D-Link section and add the redsonic headers as described. I hope that at some point we can implement automatic detection of renderers, so special settings would be automatically applied; for now you have to add the settings to your config.xml manually.
Did that solve the problem?
Thanks for the reply. Sadley, the answer is no. It just ends up scrolling on the server side that the DSM is now looking for .srt files, but the pausing still happens. Any other clues?
Hmm, usually the redsonic headers do the trick for AVI playback..
To be honest, I have no idea why this happens. If you make me a log (ethereal or tcpdump) I could look at the traffic and see if I can find anything unusual.
Thanks. Let me do some more testing. I might compile with the debug options turned on and see if that gives any clues. If not, I'll get ethereal running and take a snapshot.
One more thought - this couldn't be caused by lack of memory now could it? Out of curiosity, I ran ps -AF to get a snapshot of memory usuage and I see that this thing is using almost all available memory. How much memory does it really need?
Well, I have MediaTomb running on an ARM9 based NAS devive with 64MB RAM - that's the Bubba Mini Server; it works perfectly (allthough I do not have a DSM-520, I use it with a Streamium MX6000i). I also know of people who are using MediaTomb on platforms with 32MB RAM - your box has 128, so that should not be a problem, well, unless there is a bug in our code and we are leeking; but I believe then we would have a lot more complains. We also did some valgrinding before the release. I think the Kurobox is powerful enough, so I really wonder what is causing the problem. My biggest suspision was with the DSM-520 and the redsonic headers, without those headers there were always playback problems, also on more powerful x86 systems; but you did add those headers, so I guess it must be something else...
Yeah, interesting. 32 MB? Wow! I wonder what is going on then because I had 'top' running and watching Mediatomb, it was eating well over 100 MB itself. I think 104 MB last I checked, which was about evey last bit of useable ram left on the system prior to hitting swap. Possible memory leak?
Is there a way to limit its ram consumption? It seems to play better when I shut down several services, but then it started acting up again. It just took longer. Of course, this could be coincidence.
On another test, because I read in the documentation that the taglib can cause a memory leak, I tried compiling for id3lib instead, but this had no effect either.
I went back and ran Twonky, and checked it's RAM usage, and it has a much smaller footprint. It has an option to limit RAM in the config files as well. Played with both the same AVI's and same MPG's and it works fine, so it can't be the files. I really shouldn't use Twonky anymore however since my 30 day trial was over months ago (insert guilty feeling here).
I'll do an Ethereal capture on it now, but this won't happen till Monday since I will be leaving town this evening for a couple days.
No, limiting RAM is not possible. We did check for leaks on x86 and did not see any major problems, seems also to work fine on ARM based platforms. But well, one can never rule out some undiscovered bug or odd behaviour, especially on a platform where we have not done any testing. Maybe you could check with other Kurobox users, would be interesting to see if they report similar problems?
I'll be gone for 10 day holidays starting mid-next week, would be good if we could look at the log on monday.
I just emailed you the tcpdump taken directly on the Kuro Box. Let me know if you find anything. I didn't see anything right off, but it's 2.3 MB worth of data so it may take a minute to go through.
Hmm, the log is somehow garbled, Wireshark complains about a few things and I do not see everything there; some packets appear incomplete, I see HTTP traffic continuation but no GET requests...
maybe you could try to make the capture with tethereal (it's a textmode tool in the wireshark package)
My thoughts too. I was looking for header requests and such, and found none. I'll try the wireshark package. It looks like they have a Gentoo binary available.
Give me a bit. The source is over 10 MB in size for wireshark. It takes a while to compile that on a 266 PPC! :)
Still compiling. Now you know why I went with Tcpdump. It's a lot smaller!
Still compiling. :(
Well, you could try cross compiling... can be tricky to set up but is of course much faster :>
Maybe next time. I didn't think it would take 2 hours! :) Anyway, I'll have a trace for you tonight.
I tried the 1.04 firmware and had nothing but trouble from it. I recommend downgrading to the 1.02 firmware. To do this, you will have redirect traffic for ftp.dlink.com and possibly www.dlink.com to an ftp server where you create a "fake" version of their site. You'll basically need an anonymous FTP with a directory tree containing "medialounge" in the root and a "DSM520" directory in there. Inside the DSM520 directory, create a file called "DSM520-VerInfo.txt", and put this in it:
Only two lines, no blank lines before or after. The LOCATION= line tells your media player to download that file and reflash itself with it. You can find the file here:
(note, obviously this will only work if you aren't redirecting the traffic yet)
The 1.04 firmware made the interface nicer, but it totally mucked up playback of files that worked perfectly with 1.02. I have *no* idea why. I tried other servers as well, it didn't make a difference.
Thanks for your feedback! That's some very interesting information!
Log in to post a comment.