Amahi Forums

Since migrating to Ubuntu, I've found that some basic DLNA|UPNP compliment renderers will display a '(null)' error when displaying a folder in the media storage hierarchy that recently was itself or had something below it altered. For example:

• Folder A
  Folder B
  Folder C
  Folder D

After an change in [Folder B], the new [Folder B]* is displayed as:

• Folder A
  (null)
  Folder C
  Folder D

This seems to be because miniDLNA is unable to write-out to it's database file, [files.db], due to a permission problem. Frankly, I don't know where the hell the DLNA stuff is stored by default as last I checked it wasn't in the Fedora14 location or documented.

I found it's easiest to open the minidlna.conf file located at

• Code: Select all

  /etc/minidlna.conf

Enable by uncommenting-out and set a database location for the following:

• Code: Select all

  # set this if you would like to specify the directory where you want MiniDLNA to store its database and album art cache db_dir=/[my arbitrary location]/[folder

This directory needs write privileges set, so from terminal:

• Code: Select all

  sudo chmod 777 [my arbitrary location]/[folder]

And then it should work. I'd appreciate any advice, perhaps a more elegant way than 777.

We will have to take a look at this potential issue. Check the permissions on the folder to ensure it is owned by the admin user:users.

If you feel this is a bug, please submit a ticket in the bug tracker.

I still have problems. Still when files are copied to my HDA via windows snyc toy, all files under /var/hda/files/drives/driveX/..... are root:root

DIRECTORIES are given the correct ownership, but files are not. I need to do a chown after every sync in order to make sure new files are properly indexed by miniDLNA etc etc.

This is puzzling. So I presume that /var/hda/files/drives is owned by firstadminuser:users as well. If it is not, it should be.

This sounds like one of those hard to track down issues. Have you considered uninstalling DLNA app, cleaning up any left behind files, and reinstalling? Maybe there was something changed in the app since you installed it that will correct this problem.

Sorry I am not much help, but not sure what else to do at this point.

This is puzzling. So I presume that /var/hda/files/drives is owned by firstadminuser:users as well. If it is not, it should be.

This sounds like one of those hard to track down issues. Have you considered uninstalling DLNA app, cleaning up any left behind files, and reinstalling? Maybe there was something changed in the app since you installed it that will correct this problem.

Sorry I am not much help, but not sure what else to do at this point.

I don't think it's a DLNA issue...the issue is with the system itself because when those files are copied to the HDA remotely shouldn't they be assigned the correct ownership by the system? It's just a symptom that HDA isn't able ot access the files because they do not have the right ownership.

You are correct in that the parent directories all have the right ownership
/var/hda/files/
/var/hda/files/drives
/var/hda/files/drives/drive1
/var/hda/files/drives/drive2
/var/hda/files/drives/drive3

Directories created under those also have the right ownership when new files are copied and created
For example 2012-11-25 - Thanksgiving
var/hda/files/drives/drive1/photos/2012-11-25 - Thanksgiving will even have the correct ownership. It's only the files copied there that will not have the right ownership.

Does this happen when copying files using the Windows file manager or is this just a synctoy problem? Need to try different methods of copying to see if its the tool doing the copying that is the problem.

Sounds odd, but at least we can rule that out.

It doesn't matter how I copy...whether manually using windows explorer or using synctoy.

Sorry I am not much help. I don't know what to check now. Seems odd that it has this issue. Have you searched the forums or internet for any solutions?