TomatoUSB

Configuration:
- Asus RT-N16 running
- Database location: RAM
- Two 2TB ext3 hard disk drives attached
- Primary media server client is PS3 Slim (latest firmware)

Essentially, the media server dies after a few hours. PS3 works fine for awhile, will play videos, see files no problem.

When the error happens, then everything on the shares becomes inaccessible and PS3 claims they are illegible or not there.

What leads me to believe miniDLNA is crashing is that when I go to the admin console, the option to restart now isn't there. The Tomato FW is acting like it's not running.

What logs should I gather in order to assist? I realize this is a beta feature, and want to help with sorting this out.

The only log available is the regular Tomato system log. Is there anything in the log after media server becomes unavailable?

What's the memory and CPU usage on the router (as shown on the Overview page) after a few hours of using miniDLNA but before it's crashing?
What's the output of "ps" command, and CPU and memory usage after the crash?
Is the USB disk still accessible otherwise - via FTP or Samba - after the crash?

Will work on getting those logs and confirming the result of ps ccommand

- Changing settings for example - to strictly adhere to DLNA or not, and saving - gets the service to restart and back online for a bit.
- I can confirm the files remain available via FTP, can still add files / remove files.

Teddy_B - I swear you must have "the knack."

the knack

I can't break it for the life of me since your post. I've fast-forwarded, went in and out of movies - I just can't break it. Even NAS'ing files over while watching a movie.

The same things that for the past 3 days were guaranteed to do this after 8 hour of run time - nothing will trigger.

I will have to subject to a rainy-day weekend of torture as a media server and see what I can get.

Finally got it to happen again.

Sep 4 05:24:37 unknown daemon.warn minidlna[27657]: File too small. Probably corrupted. [/tmp/mnt/NAS_DRIVE1/REDACTED_FILENAME&FILETYPE!
Sep 4 05:24:37 unknown daemon.warn minidlna[27657]: Cannot extract tags from /tmp/mnt/NAS_DRIVE1/REDACTED_FILENAME&FILETYPE!
Sep 4 05:24:37 unknown daemon.warn minidlna[27657]: Unsuccessful getting details for /tmp/mnt/NAS_DRIVE1/REDACTED__FILENAME&FILETYPE!
Sep 4 05:39:48 unknown daemon.warn minidlna[27651]: HTTP Connection closed unexpectedly

The two things that stand out to me are:
- Many of these are very-deep directory wise with special characters. Are there DLNA specifications regarding how many directories deep and what characters are allowed?
- How are older-style MP3 playlists handled?

I was able to force the issue after a reboot:
Sep 4 07:13:23 unknown daemon.warn minidlna[5651]: HTTP Connection closed unexpectedly

Name tomato
Model Asus RT-N16

Time Sat, 04 Sep 2010 07:14:32 -0700
Uptime 1 day, 10:46:12
CPU Load (1 / 5 / 15 mins) 2.12 / 2.03 / 1.98
Total / Free Memory 124.29

PS Output logs: (Telnet Session)

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2010.09.04 09:18:54 =~=~=~=~=~=~=~=~=~=~=~=
unknown login: root
Password:

Tomato v1.28.9048 MIPSR2-beta18 K26 USB Ext

BusyBox v1.16.2 (2010-07-25 09:15:28 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

psroot@unknown:/tmp/home/root# ps
PID USER VSZ STAT COMMAND
1 root 1260 S /sbin/init noinitrd
2 root 0 SW< [kthreadd]
3 root 0 RWN [ksoftirqd/0]
4 root 0 SW< [events/0]
5 root 0 SW< [khelper]
17 root 0 SW< [kblockd/0]
43 root 0 SW [pdflush]
44 root 0 SW [pdflush]
45 root 0 DW< [kswapd0]
46 root 0 SW< [aio/0]
90 root 0 SW< [mtdblockd]
286 root 752 S hotplug2 —persistent —no-coldplug
327 root 1248 S buttons
646 root 0 SW< [khubd]
690 root 736 S p9100d -b -f /dev/usb/lp0 0
692 root 0 SW< [scsi_eh_0]
693 root 0 SW< [usb-storage]
734 root 0 SW< [kjournald]
837 root 736 S p9100d -b -f /dev/usb/lp0 0
885 root 1004 S eapd
897 root 1020 S rstats
905 root 1184 S nas
1087 root 1688 S udhcpc -i vlan2 -s dhcpc-event -H unknown -m
1190 root 2468 S nmbd -D
1191 root 2412 S nmbd -D
1192 root 3248 S N smbd -D
1263 root 1680 S telnetd -p 23
1265 root 1332 S httpd
3159 nobody 940 S dnsmasq
3762 root 0 SW< [scsi_eh_2]
3763 root 0 SW< [usb-storage]
3788 root 0 SW< [kjournald]
5204 root 3640 S N smbd -D
5651 root 9976 S minidlna -f /etc/minidlna.conf -R
5652 root 9976 S minidlna -f /etc/minidlna.conf -R
5656 root 46824 R N minidlna -f /etc/minidlna.conf -R
5657 root 9976 S minidlna -f /etc/minidlna.conf -R
5929 root 1692 S -sh
5938 root 1680 R ps
24127 root 1696 S crond -l 9
24129 root 1676 S syslogd -L -s 50
24131 root 1676 S klogd
root@unknown:/tmp/home/root# exit

I am having stability issues with minidlna. When it crashes it takes the whole router out with it (still routes to the internet but can't access it directly and needs a reboot for stuff like NAS services and DNS to work again etc).

Is it just that this program is unstable in general or is there anything I can do to resolve this?

This is familiar. It's characteristic of the router exhausting some resource, like memory. It's not the program and it's not the program crashing. It's the router itself going belly-up. This can be expected when you take a platform that is designed and optimized for one simple thing (routing IP packets) and loading it down with additional resourse-intensive programs.

If you could monitor syslog, you'd probably see kernel messages just before it dies.

Probably the only thing you can to is kill and restart the program every few hours.

I would understand if it exhausted the memory and minidlna died, but the whole environment dying seems a bit silly. Linux is supposed to be excellent at managing memory and so something low priority like minidlna shouldn't be able to take the whole router out with it.

I have disabled PHP on my built in web server as I'm not using it. Hopefully the additional memory will reduce the frequency of errors.