ReadyNAS Duo - Minidlna - Very, very slow discovering service

[steveTu]

Model: ReadyNAS Duo [X-RAID] Serial: 24M3117Y01978 Firmware: RAIDiator 4.1.16 [1.00a043]  Memory: 256 MB [2.5-3-3-7]

I have had the NAS for a while and it has been running minidlna fine - with various clients using mainly the photo and music sharing.

Over the weekend, even though the minidlna services are still running fine, the clients seem to take ages to initially detect them. I did rescan the media files.

Is there any way to see what is happening? I have one client (Onkyo AV) that is not finding the service at all.

All the clients find other instances of minidlna all but instantly (I run minidlna under Fedora Core 28) - so the clients seem ok.

The clients that have had timing issues were roberts 'stream' radio, panasonic music stream and the Onkyo. Panasonic TV seemed to pick up the NAS minidlna  service fine though.

[steveTu]

....also, the NAS is on timer so reboots each day - so the minidlna service is also obviously restarted daily....

[StephenB]

Try enabling ssh on the duo, and looking at notify_interval in minidlna.conf.

The default is 30 seconds (so if it is commented out, that is how often the server sends out a NOTIFY message).  That's a reasonable value.  But it might not be commented out (and might be set to something more like 15 minutes).  If that's the case, try using the default.

Also, see if something on the NAS is interfering with the service (either a nearly full OS partition, or a high CPU load).  By default, the NAS puts it's DLNA cache on the OS partition - which isn't great, because that partition is quite small (2 GB on a NAS running 4.1.x firmware).  You might want to move that cache to a folder on the C volume.

The NOTIFY is an unsolicited advertisement.  The other mechanism is that the DLNA client broadcasts a query ( M-SEARCH ), and the DLNA server responds to that query.  It sounds like the M-SEARCH might be being blocked by your network infrastructure - which is puzzling, since that doesn't seem to be happening with the fedora-hosted server.  You might try toggling the UPNP service in your router and see if that helps (turning UPNP off if it is on, or vice versa). 

Another option might be to mount the duo shares on your Fedora, and just use it's server.  Though you'd need to script that since you are using the power timer on the NAS.

There are some upnp developer tools out there, including https://www.meshcommander.com/upnptools.  I haven't used them, so I don't know how helpful they would be.

[steveTu]

Thanks for the reply.

The issue seems to be some form of timing as the panasonic smart music apps eventually pick up the NAS and once 'acquired' seem fine. So I have the panasonic TV and speaker ok and the roberts radios ok. Just the Onkyo is being stubborn and just won't see anything apart from my laptop minidlna server and that's working fine as starting and stopping the service on my laptop reflects ok on all the clients.

Starting and stopping the NAS minidlna works ok'ish now apart from the Onkyo - which would tend to point at the Onkyo more ...

The notify interval was set to 900 (but so is the minidlna conf on my laptop) - so I've set that to 30 without much luck. 'Top' is showing nothing manic on the NAS - it's doing bugger all - and I've still got 1,4 GB of the 1.9 in the root fs. So all seems ok on the NAS.

I've toggled the UPNP settings on the BT HHUB - and made sure they were saved - no joy.

I have turned the Onkyo off and on from source rather than just to/from standby - and that's done nothing.

Frustrating as hell as all this has been working fine for years! I'll check the Onkyo to see if I've had any auto firmware updates on that (not sure if I can see that though - I think it just shows the firmware version and not the date updated).

[steveTu]

I really don't follow what is happening. AFAIK the only change was a rescan on the NAS.

The Onkyo (I acn't see when the firmware was updated - just the version and that it is the latest) that is still experiencing the worst connection problems supports both wired and wireless connections. It has been wireless since we had it (and there's never been a problem at all with it picking up the NAS). So I thought I'd simply try wired. It picked up the NAS after a few seconds. So I toggled the wired/wireless setting - and this time nothing in both wired/wireless. I then tried a last time and again, after a few seconds in wired mode, it picked up the NAS. So at the moment I've left it in wired mode. The device uses the same network (IP) settings in both wired/wireless modes.

Still it seems that it's timing out somewhere - as in all the clients that support DLNA my laptop appears immediately and the NAS then pops up sometime later (apart from the Onkyo in wireless mode).

I'll see if there's any specific report of issues with the Onkyo and DLNA.

[StephenB]

Is it possible that your router isn't forwarding broadcast packets between the wireless and wired networks?

What router do you use (manufacturer+model).

[steveTu]

The router hasn't changed for over a year. It's a BT Home Hub6. Split frequency since day one. Most of the major connections are static IP's - the NAS is, as is the Onkyo, Roberts radios and Panasonic TV. The phones, tablets (using Panasonic Music Stream app) are DHCP.

I've tried changing upnp settings on the router and that makes no odds. The only way I can get the Onkyo now to see the NAS is hardwiring it. So at least that proves that minidlna is working fine. I also know that wireless is working fine (or at least the Roberts' implementation of upnp over wireless) as the Roberts Radios pick up the NAS (after a few seconds). The Panasonic Music stream apps used on a couple of phones are hit and miss. Although I changed my phone to the 5GHz frequency and the Panasonic app picked up the NAS ok.

Still for the life of me can't think what's changed over the weekend apart from the known rescan - although when I couldn't connect to the NAS, I did reboot the router. But obviously that was after the event.

[StephenB]

It is a puzzle.  Is it practical to just run the Onyko wired for the long term?

[steveTu]

Maybe - as I probably need a new NAS anyway!

But I've had a bit of a result. I went into the frequency select on the hub and switched off each frequency individually and restarted them. Then restarted the Onkyo in wired mode and switched that back to wireless and hey presto, Bob's your auntie. Still don't see how or why that should work given that the Roberts Radios were working. I'll check all the devices over the next day or so and post it back here if it's now 'fixed'.

Thanks for the help.

[steveTu]

OK - the NAS has shut down and rebooted on the timer and all the devices can still it. Grand. So the issue 'appears' to have been in the wireless network - and shutting down each frequency and restarting them has 'somehow' cleared a log jam (again still not sure why restarting the router didn't have the same effect - but what the heck).

A couple of related questions though - what I realised yesterday, is that playlists (that I've been creating more of over the past few weeks) are in some way interpreted by minidlna and seem to scan oustide of the main scan. So when I rescanned the minidlna database, it said it had finished after a couple of hours - but now I think that it hadn't finished and was still processing the playlists. Is that the case? Is the Radiator message that says the scan is complete issued before the playlists are processed?

Ssecondly, I now have differences between my laptop minidlna and that on the NAS (they contain the same data - and the NAS is a copy of the laptop) in some of the playlists. The problem appears to be where a track name is the same. For instance, I have 'Heaven' as a track by Chris Rea and The Staple Singers. I created a new playlist (m3u) yesterday for the Staple Singers. The .m3u has all the tracks in the cd - fine. BUT when I play the NAS version of the playlist, instead of playing the Staple Singers' Heaven, it plays the Chris Rea version. So the scan of the playlists within minidlna is presumably creating a database ( I see there's an SQLITE database there) with an interpreted version of what the playlist is trying to play rather than physically using the entries in the playlist itself on playback. If that is the case, then the SQL that scans the playlists and creates the DB entry would appear to have a bug (that doesn't appear to exist in the minidlna version on my laptop - as that plays the right track).