TomatoUSB

Using latest VPN build on Asus RT N-16 and been playing with the media server. So far works fine with the PS3 (using DLNA) and both my XP box and my Macs can see the HD over Samba (using FAT32 right now; NTFS was too slow. Getting ext3 is likely to be tricky.)

I have the Tivo option checked, and somewhere along the way it actually showed up. But then suddenly, it stopped showing up on the Tivo. Not sure what happened (been tweaking lots of unrelated settings). Doesn't seem to be much discussion on this on the forums.

Running a Tivo HD (1TB upgrade).

TiVo discovers 'desktops' that it can pull files from using one of two methods, either the TiVo beacon system (port 2190) or, more recently, Bonjour (port 5353). Looking at the minidlna source code, it uses the beacon protocol on 2190.

I have a TiVo HD wired to an RT N-16 running K26 beta 54 VPN, but I haven't tried the media server yet. I've historically used pyTivoX or plain pytivo on my MacBook because I like being able to 'push' h264 files in their native format to the tivo (the same system that the movie services use to send videos to your tivo). I may add a spare drive to the router and see how I get on.

Paul

For the record, Tivo now sees the Media Server. I had rebooted everything apparently except the router with the HD attached. Had 3 copies of everything, but that is now corrected too as well.

Spoke too soon, and now I understand why it seemed to work the first time I used it and then didn't:

The Tivo will detect the NAS on the Asus RT N16 soon after the router is rebooted, but unlike its use with my PS3 (DLNA) and my PC/Macs (Samba), it is not very stable. I got halfway through transferring a video file from the Tomato HD to my Tivo and it just stalled. Then I noticed the Tivo simply won't display the NAS any longer. (All other Tivo HME devices are working fine). And though the Tivo stopped recognizing the NAS, everything else could still use it just fine (PS3/Mac/PC).

So it works, just not for very long, and is much less stable than use with other systems (DLNA & Samba).

Hopefully the Tivo code is up for revision in a future Tomato firmware update. I'd be happy to beta test it!

I am also seeing weird behavior from minidlna after enabling Tivo support. minidlna opens a socket on the tivo port (udp/2190), but netstat shows the receive queue on this socket never clears. The queue gets bigger and bigger as the process runs on. Why doesn't minidlna read that socket?

Looking at the code for minidlna shows that this socket is apparently only used for outgoing broadcasts, and is never checked for input. Ah, that explains it.

But why? There is a comment above the socket create routine which refers to an http socket. But that never seems to be created. I'm not familiar with the tivo protocol, but something seems missing here. More investigation required.

Meanwhile, the dlna part of the server works fine: I am able to access via dlna from another client. Everything else is working fine on my router as well, including ipv6 support via tunnelbroker.net.

Does this issue ring any bells for anyone? Any suggestions?

Here are details of my environment:

WNR3500L router, running Tomato Firmware v1.28.7440 MIPSR2-Toastman K26 USB VPN.

Log entries after enabling Media server in gui:

... daemon.warn minidlna[21395]: Starting MiniDLNA version 1.0.18.2 [SQLite 3.7.2].
... daemon.warn minidlna[21395]: HTTP listening on port 11690
... daemon.warn minidlna[21395]: TiVo support is enabled.

21395 root      5116 S    minidlna -f /etc/minidlna.conf
21396 root      5116 S    minidlna -f /etc/minidlna.conf
21397 root      5116 S N  minidlna -f /etc/minidlna.conf

Here's /etc/minidlna.conf:

network_interface=br0
port=0
friendly_name=tomato
db_dir=/var/run/minidlna/.db
enable_tivo=yes
strict_dlna=no
presentation_url=http://172.22.0.3:80/nas-media.asp
inotify=yes
notify_interval=600
album_art_names=Cover.jpg/cover.jpg/Thumb.jpg/thumb.jpg

media_dir=/mnt

Netstat shows expected open ports for minidlna, including udp/2190. Here is netstat -uan output after several minutes of operation:

Proto Recv-Q Send-Q Local Address           Foreign Address 
udp    23976      0 0.0.0.0:2190            0.0.0.0:*
udp        0      0 127.0.0.1:38032         0.0.0.0:*
udp        0      0 0.0.0.0:53              0.0.0.0:*
udp        0      0 0.0.0.0:67              0.0.0.0:*
udp        0      0 172.22.0.3:3912         0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:38000           0.0.0.0:*
udp        0      0 :::53                   :::*

And a few more samples for 2190 over the course of the next few minutes:

udp    26016      0 0.0.0.0:2190            0.0.0.0:*
udp    28312      0 0.0.0.0:2190            0.0.0.0:*

Any ideas or suggestions for further debugging? Thanks!

I suggest you bring this issue up with MiniDLNA author - either start a forum discussion, or submit a bug report on the project site.

Is their a conflict with miniupnpd? The author of miniupnpd has recently submitted a patch in this area

http://miniupnp.tuxfamily.org/forum/viewtopic.php?t=746

I don't see a conflict. Both applications bind SSDP listeners to UDP port 1900 using SO_REUSEADDR socket option, so they can coexist:

udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*

Followup to my post from a few days ago, after a bit of debugging…

Turns out there are two issues. One of them concerns the default routing table as initialized by tomato: minidlna sets up the TivoBeacon udp broadcast to go to address 255.255.255.255. The routing table has no provision for this, and so the packets are directed via the default entry out the vlan2 port to the WAN, and are never seen on the LAN. So the TiVos don't see the beacon, and naturally never respond.

Adding a new route entry solves this problem and the TiVos now communicate fine with minidlna:

route add 255.255.255.255/32 dev br0

The other issue I raised (udp/2190 socket not being read) does seem to be an issue with minidlna, and I'll bring it up in that forum. Thanks for the pointer. For now, I addressed it in my router by adding an iptables rule to DROP those inbound packets from the LAN.

minidlna sets up the TivoBeacon udp broadcast to go to address 255.255.255.255

Hmm… It should not normally do that. It only uses INADDR_BROADCAST as a fallback, if it could not determine the broadcast address of the listening interface (br0), which should be X.X.X.255 in your LAN subnet (usually 192.168.1.255), and doesn't require any additional routes.

Are you doing anything unusual with your ifaces configuration? Do you see the correct bcast address for br0 in the ifconfig output?

If ifconfig shows the correct address, try the following. Stop minidlna via command line:

service media stop

minidlna -f /etc/minidlna.conf -d

minidlna[13963]: minidlna.c:890: TiVo support is enabled.
minidlna[13963]: tivo_beacon.c:128: Interface: br0 broadcast addr 192.168.1.255

The other issue … does seem to be an issue with minidlna, and I'll bring it up in that forum.

Saw your post, and MiniDLNA author's reply… Great - fixed already :).