Adding symlink information to the database?

Discuss client development (or even MPD development if you feel so inclined), ask questions about the client libs, MPD feature requests from client developers, etc...
Post Reply
nbpf
Posts: 56
Joined: June 17th, 2014, 6:45 am

Adding symlink information to the database?

Post by nbpf » January 4th, 2016, 2:22 pm

It is well known that using "internal" symbolic links leads to fake copies of album tracks. For instance

https://github.com/nicolabotta/screensh ... 4%20PM.jpg

comes into place because there are two symbolic links pointing to the tracks of the selected albums. The outputs of mpc -f "%file%" for two such tracks
composers/Vaughan Williams, Ralph (1872-1958)/Violin Concerto in D minor/Tasmin Waley-Cohen, Orchestra of the Swan, David Curtis (2014)/1 Vaughan Williams Concerto for violin and string orchestra - 1 Allegro pesante.flac
and
data/Tasmin Waley-Cohen, Orchestra of the Swan, David Curtis/Vaughan, Elgar | The Lark Ascending, Violin Concerto in D minor, Introduction and Allegro, Serenade for Strings (2014)/1 Vaughan Williams Concerto for violin and string orchestra - 1 Allegro pesante.flac
reveal that, at the file system level, the first file is a symbolic link to the second one. In building the MPD database, this information is lost leading to fake copies of album tracks in MPD clients.

If MPD would preserve the information that the first file is a symlink to the second, MPD clients could use it to prune albums from fake track duplicates.

This, in turn, would allow one to make proficent use of symbolic links for accessing music collections. For classical music, for instance, it is mandatory to be able to browse a collection according to a COMPOSER > WORK > INTERPRETATION scheme, for instance as in

https://github.com/nicolabotta/screensh ... posers.PNG

https://github.com/nicolabotta/screensh ... orks-1.PNG

https://github.com/nicolabotta/screensh ... ions-1.PNG

The set of tags currently supported by MPD is not suitable for organizing classical music collections. But, as you can see from the screenshots, browsing a collection according to COMPOSER > WORK > INTERPRETATION can be easily realized via symbolic links and plain folder browsing.

If it was not for the silly track duplicates, of course!

Thus, the question is whether it would be possible to add a "target" information to MPD entries. This could be void (or would contain the own path) for actual data and would contain the path (relative to MPD's music_directory) of the file pointed to for symbolic links.

This additional string would be enough for MPD clients to treat symbolic links consistently and avoid fake track duplicates.

Post Reply