“the j stands for Johnny”
about me | research blog | wordpress plugins | jQuery plugins

25 July, 2011

How I revived my disappearing Seagate GoFlex Home DLNA/UPnP server

My family bought a Seagate GoFlex Home 2TB network-attached drive for streaming videos directly to our Samsung TV via DLNA/UPnP. Everything worked fine for a while, until suddenly one day it just refused to show up on the TV anymore. After eliminating all the home networking factors (cables, IPs, DHCP etc.), I noticed that when restarting the device it actually showed up briefly on the TV, but with no files on it – only to disappear after a few seconds.
Note that the device still behaved normally as a network device, i.e. when browsing using Windows Networking/SAMBA we could still access all our files normally. It was only the DLNA service that did not seem to be functioning.

Combing through the Seagate forums (and the web in general) I found that others have had similar issues but no real solutions seem to have emerged. So a little more investigation had to be done. The GoFlex Home web interface did not report anything untoward, and fiddling with all the settings in the preferences did not seem to have any effect.

So, like all good hackers I got my hands dirty and gained SSH access to the device.

Getting SSH access to the device

As described here and here, to gain access to your GoFlex Home via SSH you will need:

  1. An SSH client (obviously)
  2. The IP address of your GoFlex Home
  3. The administrator username & password
  4. Your device’s product key, which you can find by clicking About GoFlex Home in the bottom left of the web interface
  5. Confidence using the Linux command line

So, you open an SSH connection to your device with this specially-formed username USERNAME_hipserv2_seagateplug_XXXX-XXXX-XXXX-XXXX, where USERNAME is your username and XXXX-XXXX-XXXX-XXXX is your product key. On a Linux/Mac terminal this could look something like this (note the username, product key and IP will be different):

ssh john_hipserv2_seagateplug_FKSU-FJDU-DOWU-OSHD@

Once you’re in, go straight into root — as you will need to do so anyway before long — with:

sudo -s

Of course poking around as root is dangerous and could irreversibly mess up your device, but if you’re still reading then you probably already knew that.

Restarting the DLNA service

At this point I tried poking around, trying to find some logs or anything which could give me an idea what the problem was. The name of the service which actually provides the DLNA server is minidlna, for which a totally invaluable reference can be found here. I tried to access the MiniDLNA log with

tail /tmp/minidlna/minidlna.log

but was told that the log was unavailable. Curiously, running ls -l in the directory reported that the file had no size, permissions, or modification date; so that wasn’t much help. I then tried to find the status of the MiniDLNA service with

/etc/init.d/minidlna.init status

which told me that the PID in /mnt/tmpfs/var/run/minidlna.pid did not match that of any running process, implying that the daemon had crashed. Made sense so far, but when I tried to restart the service with

/etc/init.d/minidlna.init restart

the service would attempt to restart, but instantly crash again as described above. Same thing with manually stopping and starting the service. Some trial and error later, I discovered that what needs to be done is is that MiniDLNA’s temporary folder needs to be forcibly unmounted, like so:

umount /tmp/minidlna

Restarting the service again after doing this finally did the trick; Checking the service’s status again as above now reports that MiniDLNA is running, and everything shows up normally on my TV etc.

Rebuilding the database

If the steps above still don’t fix your problem, you likely need to get MiniDLNA to rebuild its media database, with the command

/usr/sbin/minidlna -f /etc/miniupnpd/minidlna.conf -R -d

This time, I was given an error message about being unable to open sqlite database file, /tmp/minidlna/files.db. Attempts to force-delete the file manually also failed, and I finally had to resort to manually unmounting the minidlna directory with

umount /tmp/minidlna

This happily worked, and I was then finally allowed to rebuild the database with the command given above. This will scan your media folders and rebuild the database for you in MiniDLNA’s debug mode, which means it will spit out lots and lots
of output message to the console. After maybe 5 minutes or so, it finally told me the media library scanning was complete, and lo and behold I could once again access my GoFlex Home via my DLNA-enabled TV.

Now, I am still unclear as to what happens when I restart my device. The first time I tried this (after rebuilding the media database) my device went into the exact same problem as before! This time I logged in via SSH again, and run the MiniDLNA daemon in debug mode but without rebuilding the library:

/usr/sbin/minidlna -f /etc/miniupnpd/minidlna.conf -d

This successfully started the service again, allowed me to cleanly exit my SSH connection and access the DLNA server via my TV again. However it did take many minutes until my files all showed up, so I am assuming that MiniDLNA was in fact rebuilding the media database itself.


Despite finally managing to get things working as described above, it turns out that every time my GoFlex Home is restarted the MiniDLNA daemon crashes in the same way, and I am forced to fire up an SSH connection to sort things out. I have as yet found no way of permanently fixing the issue, but since our device is basically online 24/7 it’s not too much of an issue.

Of course I realise the steps here are not for the computer faint hearted, but after exhausting all the “user-friendly” ways of restoring the device, this is only sure-fire way I have found.