Workaround for large music collection!

[Ramses800]

Hello everyone, I just finished a little utility for making a workaround for getting Sonos to be able to index large music collections.
This workaround will only be usable with the Folders view in the controllers though.

The key point is letting Sonos index a folder structure with m3u files instead of the actual music files.
This together with a program that can automatically create a copy of the music collection folder structure and fill it with m3u files(with complete(and possible shifted) file paths.), mimicking the actual collection.

Sonos will still only be able to index 65000 m3u-files but since each m3u-file will contain the contents of each folder listed(which usually means 1 folder per album) the limit will approximately be pushed up with a factor 10-15(number of songs on a standard album)


More info and the beta(only tested on XP) of M3U4U is found on www.anderware.org

cheers,
Anders Forslund

[President]

Hi Anders,

VERY NICE application!

I do however have a problem.

M3U file structure created as described - i.e. a line in a the m3u file reads

D:\shares\Music\Sonos - Rockabilly flac\1910 Fruitgum Company\Best Of\01 - Simon Says.flac

Sonos indexed the M3U file structure. I can browse the structure - but I cannot play any music. Sonos reports:

Unable to play the file 01 - Simon Says.flac - the file //HPSERVER/M3U/01 - Simon Says.flac cannot be found

(HPSERVER is D


Seems in Sonos all file structure reference after main folder M3U is lost - even if I can browse the full structure.

Any thoughts on this?

Pres.

[President]

Used the Location Shift function to state \\HPSERVER\shares\Music.........

Again M3U tree structure is built to perfection.

Sonos indexes.

Now when trying to play music I get an "Access denied to \\HPSERVER\shares" message.

Anyone?

Pres.

[ratty]

Some time back another user had a similar problem with access rights when using M3U playlists pointed at non-indexed shares.

AFAICR it was resolved by allowing 'guest' read access to all shares, and not specifying username/password for the shares in Sonos library setup.

BTW, M3U lists for Sonos can never use drive letters like D:\ -- a mapped drive is meaningless outside Windows (DOS!). The other point is that M3U paths can be absolute (\\<computer>\<share>\<folder>\<subfolder>\etc) or relative (<subfolder>\etc), but upward relative paths (..\<sibling_folder>\etc) are not valid.

[Ramses800]

Ratty is absolutely correct, the m3u-share must have proper access rights set to it in order for Sonos to be able to read them(this is of course no different than the normal share used).

Originally Posted by Ratty

AFAICR it was resolved by allowing 'guest' read access to all shares, and not specifying username/password for the shares in Sonos library setup.

Right, the Sonos player reads the file path from the m3u but does not know what username or password to access that location with. It could use the same as the indexing share but it does not try that either.

If I remember correctly, Sonos requires a "true" share as well, meaning that Sonos has some problems with indexing subfolders below the starting share level, ie if the actual share is \\192.168.0.1\music_share, trying index \\192.168.0.1\music_share\m3u will not always work. A new share would be need to be made like \\192.168.0.1\music_m3u_share which publishes the m3u folder as the base share. This works differently on different NAS:es.

And also, as he states, the mapped drive in Windows is not a valid path for Sonos - that is what the "Location Shift" is used for.
It can be a bit tricky to determine the correct location shift that is valid for the individual system to be used. Sometimes it is easier to use the IP-adress of the server with the share instead of its name, ie \\192.168.0.1\music_share etc

[Ramses800]

Now, if we only could persuade Sonos to implement the option to select what file types the indexing service indexes, it would be easy to just index m3u-files and let the program create m3u-files on in the actual, local music share and by this way the access rights would work directly!

This workaround has its issues, mainly security related things like, "Do I want to give the guest account read access to all my music without any password protection?"
If only m3u-files was indexed this would not be a problem, all files would be password secured and accessible by Sonos!

Taking it a step further, maybe the Sonos indexing service could create the m3u-files itself!

I suggested this in Sound Ideas(http://forums.sonos.com/showthread.p...9126#post99126)

[Avee]

All sounds very similar to ID3Browse. This is a tool to create m3u files in folder structures to allow for multiple browse hierarchies in file-based music players. It is extremely flexible in its structure, but only allows for a mp3 library. It is available in source code, so maybe a lot of inspiration can be gotten from what this tool already does.

[ratty]

Originally Posted by Avee

All sounds very similar to ID3Browse.

ID3Browse has to dig in the tags whereas Anders' utility has the benefit of simply working with directory/file names and is format-agnostic. In this case I think I'd go with Occam's razor.

[Ramses800]

And since Sonos only support basic m3u(which only can contain path/filename) and not extended m3u(which can contain tag information as well), there is no point in getting tag data from the media files. The generating process can take a lot of time anyways(we are talking about a lot of files to index) and would increase a lot if the process has to open each file for getting tag data as well.

[President]

Thanks a bunch.

Also asked Sonos support.

The solution was to allow the guest account access through the Windows Home Server control window!

I now have access to my "normally" indexed collection - and even all the rest by the help of this workaround.

Pres.