moOde 5.0 RC1 In-Place Update

[Onionhead]

@Onionhead

My bad. Turns out I was asking Google too detailed a question. When I searched on just "@eaDir" I got several hits (besides your posts, that is).

Turns out that the culprit is the Synology DSM software after all. It's generating these weird folders in some sort of indexing scheme. Here's two representative posts:

https://mikebeach.org/2012/12/12/disable...ology-nas/
 
http://www.ourmaninindia.com/delete-eadir-folders/

Sorry I took so long to find this. Given the popularity of Synology NAS products I'm surprised the issue hasn't popped up in MPD circles. I'm not sure why it doesn't bite in moOde r4.4 but does in r5.0 but it suggests some recent change to MPD makes its directory-traversal code misfire on the weird name. Now that I know @eaDir directories are actually being written, I can try a test by creating one on my (OpenMediaVault) NAS.

Regards,
Kent

UPDATE: Even on the Synology forum where a number of legacy posts complain about @eaDir directories, I can't find a suitable explanation of what's in them. Here's an example comment, though:

So in some case you can get a lot of hidden folders (@eaDir) with preview data that you dont need anymore.

It can be significant Gb in case of Video (becuase @eaDir contains flv / mp4 preview).

A quick test with my NAS shows the mere presence of this directory doesn't throw off moOde r5.0 so it must be the "preview data" which is screwing up the works and I have no way to generate it.

Kent,

Much thanks. I will open a ticket with Synology. I am not holding my breadth. Decision time buy another NAS or give up on moOde. Wish all my decisions were that clear cit.

Good day to you.