Category: Hacking

Buckle up, this is a ride.

First off, I have to say that I do love the Cambridge Audio kit, I’ve not got anything fancy, just a CXA-60, a CXN(v2), a CXN and a pair of SX-60s. I’ve been after some Cambridge Audio separates for ages since I originally saw them in Richer Sounds many years ago. When my small Panasonic network player died it was more costly to get it fixed than to buy a new one and, since it was cheaper to buy a new one, I just went for the CXA-60 and the CXN(v2) and kept the speakers I had. The Cambridge Audio stuff does sound truly fabulous and properly love it.

There’s just one (smallish) problem.

I use iTunes to rip all my media and Meta to keep the data tidy. The back end storage is a WD My Cloud Mirror Gen 2 running Twonky 8.1. Twonky isn’t perfect and sometimes it needs a helping hand to properly recognise all album tracks but I really like the sort order it uses and it’s pretty useful for media management.

Most discs tend to have data something like:

The Title, Track Number and Disc Number are the important fields.

With most albums the tracks play in the order they’re expected to, track 1, track2 track 3 etc.

However, there is a bit of a problem with multi-disc albums. For some reason the play order is not set. Sometimes track 1, disc 1 plays first and sometimes track 1 disc 2 plays first. The play order is always alphabetic. So, really, the sort order for multi-disc albums is track number followed by alphabetic sorting of the resultant list. For albums that have two discs this is irritating because the play order is completely out of sequence, for compilations that have around five discs this is a nightmare.

Because I’d given feedback on the Cambridge Audio app I was given the opportunity to do some beta testing with the new app. Naturally, I gave that a go.

One of the things I noticed was that the app displayed a different sort order to the CXN for multi-disc albums (the proper order) but when the album was played via the app the actual play order was different from the displayed play order. That was kind of annoying really.

Investigating things further I used my LG TV do navigate the album structure to see if the same problem occurred there too. The LG TV doesn’t play AIFF files though so, as far as the TV was concerned, there was no content in any of the directories I was looking at. I had to convert all the AIFF files to MP4 files and then the TV could see the files. Not only could the TV see the files but they were displayed and played in the correct order too. To my mind, this meant that the CXN was not asking for the disc number when generating a list of assets to play.

After much back-and-forth with Cambridge Audio support I managed to get the developers to take a look at the problem. The upshot there is that as the albums play correctly when played through a USB stick and other NAS (Synology in this case) there must be a problem with the WD NAS and the way it presents its data. I’m completely not convinced that is the case because the LG TV plays everything correctly and if there was a problem with the NAS that could not happen.

At this point I was thinking I should just buy a new NAS, especially as a disk has died in the WD one, but I’m just too stubborn to give up like that and, although I can’t seem to generate DLNA traffic, I wondered whether it would be possible to snoop the traffic between the CXN and the NAS. Turns out it totally is. I mirrored the NAS port and used my Mac to read all the traffic. Using a packet capture of:

tcpdump -i en5 port 9000 host wdmycloudmirror.local -XAvvv -w cxn.cap --print

Using Wireshark I managed to filter out the HTTP traffic and I could see that when the request came for the album details it looked like this:

<?xml version="1.0" ?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
	<s:Body>
		<u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
			<ObjectID>0$1$12$18640</ObjectID>
			<BrowseFlag>BrowseDirectChildren</BrowseFlag>
			<Filter>dc:title,upnp:class,upnp:album,upnp:originalTrackNumber,id,res,res@protection,res@duration,upnp:searchClass,upnp:artist,upnp:genre,upnp:albumArtURI</Filter>
			<StartingIndex>0</StartingIndex>
			<RequestedCount>100</RequestedCount>
			<SortCriteria>+upnp:originalTrackNumber,+dc:title</SortCriteria>
		</u:Browse>
	</s:Body>
</s:Envelope>

Here it’s pretty easy to see that the sorting requested by the CXN is:

+upnp:originalTrackNumber,+dc:title

So it’s not asking for the disc number at all. The same request from the app looks like this:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
	<s:Body>
		<u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
			<ObjectID>0$1$12$18640</ObjectID>
			<BrowseFlag>BrowseDirectChildren</BrowseFlag>
			<Filter>*</Filter>
			<StartingIndex>0</StartingIndex>
			<RequestedCount>100</RequestedCount>
			<SortCriteria/>
		</u:Browse>
	</s:Body>
</s:Envelope>

Again, here it’s pretty easy to see that no sorting has been applied to the results. Also, no filtering has been applied to the original request either.

Now, not being a software developer I’m only making a suggestion here but I reckon that adding +pv:numberOfThisDisc to the filtering and sorting of the CXN requests would completely fix the problem with multi-disc albums. I’ve suggested that but it’s out of my hands and I just have to hope that my proposal is accepted…