INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: depechefan on September 20, 2019, 12:31:01 pm
-
Hi,
I've been searching this forum and it seems that some people have been able to send DSF files to a Sony STR-DN1080 receiver using DLNA. I haven't been able to so I hope someone can help. I've installed newest version of JRiver. I can send MP3 files to my receiver but when I try with DSF files I get the error "There was a problem controlling the selected DLNA device. Please double-check your device, servers and network settings". Not sure how to proceed. I can play DSF files via USB directly plugged into the receiver.
Thanks in advance for any help.
/M
-
Did you enable DSD-over-DLNA (DoPE)?
https://wiki.jriver.com/index.php/DSD#DSD_Over_DLNA
-
Hi,
Thanks for the reply. I must be doing something wrong because I can't find that setting. I have the options you can see in the attached file. I must admit that I find the interface difficult to navigate so I'm most likely missing something.
Thanks again
/M
-
Hi again,
So I managed to find that setting you mentioned. Now I'm actually able to start playback without an error. However it looks like it's sending PCM to the receiver rather than the original DSF file. And I hear only a faint hissing sound. See attached picture. Also the metadata seems to be mostly missing - not a huge deal. I've tried to choose to send PCM as well but the result seems to be the same.
So all in all still a bit confused... ?
P.S. I have just tried to install Serviio because I read that someone had better luck with that server. That worked with the default settings. All files I've tried so far are playing at the native quality...
/M
-
DSD over DoPE (DSD over PCM Ethernet) is an alternative way to send DSD data. It is meant for systems that do not handle DSD's high sample rates, including Apple systems. Some receivers understand it and some do not. Sounds like your Sony may not.
DoP packs the 0s and 1s of a DSD file into a PCM form and then the receiver unpacks the bits into the DSD form. It uses 16 bits of each sample for the 0s and 1s and 8 bits to identify the stream as DSD. The 8 bit identifier is set so that if the receiver does not recognize the DoPE format and plays it as PCM rather than unpacking it then you hear a low hiss. It sounds like that is what is happening when you use DoPE. Your receiver does not seem to recognize the format.
Your picture shows 176K PCM, which corresponds to 2.8 MHz DSD (2,822,400/16 - since there are 16 bits of DSD data in each PCM sample).
Sorry, I cannot help with the rest of the problem.
-
A total shot in the dark, but one thing you could try (if you're not already doing it) is set MC's internal volume (and maybe even system volume) to 100%, as that's required in some cases to get DSD playback working when bitstreaming, otherwise you could just hear faint sound like you are.
-
Hi,
Thanks a lot for the replies. Very helpful. Feels like sticking with Serviio is probably the easiest. Only thing I'm missing in that application is a way to shuffle songs in my playlists and that's definitely less important to me than the sound quality :-)
Thanks again!
/M
-
Please download the DMRA from my sig; run the test; and post the renderer report here..
-
Hi,
Report attached.
/M
-
Ok. The report confirms your receiver can play DSD media. However it does not give any information about the “flavours” of DSD that it supports (i.e. DSF, DFF or DOPE). So it does not really help us solve your problem (sorry for that).
You tried pushing DOPE :) and apparently that did not work. And apparently neither did 2x DSF work. So I would suggest trying a) 1x DSF (rather than 2x or 4x DSF), or b) DFF formats to see which of those, if any, do actually work.
Otherwise you may have to set MC DLNA server to convert your tracks to PCM (with header) aka WAV on the fly.
-
Hi,
Thanks for checking. Serviio works out of the box so will probably stick with that. Just would be great to have a nicer controller for sending music to the receiver. The built-in browser/player in the receiver isn't very sexy :-)
/M
-
If you could figure out what Servio is actually pushing, then we might figure out how to get MC to do the same..
..but you would need to do a trace on your network. Do you know Wireshark? If so then a Wireshark trace of the traffic between Servio and the renderer at the time you start to push play a track would help.
-
Hi,
Sure, I will give it a go. Haven't used WS in ages so might take me a little while :-)
/M
-
Hi,
I've made an attempt. Not sure if it means anything to you - I couldn't see much (other than a few lines mentioning audio/dsd). But this is the receiver grabbing the file because I can't figure out how to get Serviio to playback on the receiver...
And it seems that I can't post it. The attachment is too big. See attached screenshot with the most relevant info.
/M
-
Thanks for trying the tests. Several things..
1) You said that Servio cannot push to the Sony: So are you saying really that Servio is NOT performing any better than MC? If that is the case, then there is not much benefit in getting MC to behave like Servio. Or??
2) But you said that the Sony CAN pull from Servio: So did you try having the Sony pull from MC? (there is no point comparing apples with bananas..)
Notwithstanding the above, we may be able to make some progress with the Wireshark traces. BUT your trace is unfortunately not enough; it shows a GET for an xml file followed by an HTTP response for the DSD media track. So we will need to see the GET for the media track, and also the respective HTTP response. You will need to locate the GET visually by hand, and then you can right click on it and select to follow the TCP or HTTP session. This will open a window which shows the full content of the GET including the HTTP headers, plus also the full content of the HTTP response with its headers too.
-
Hi,
What is working is scenario 2. My receiver can pull. Just tried using BubbleUpnp as a remote to push content to the receiver via Serviio and it works like a charm. Receiver shows "Native DSD".
I'll have a look at the trace again and see if I can figure it out.
For my use case Serviio definitely works much better (actually perfect) than JRiver.
/M
-
Just an FYI - "Native DSD" has two separate meanings. One, it means the the content is in fact DSD, not DSD converted to PCM. Second, it means that the transport is native DSD speed - that is sample rates like 2.8/5.6 MHz, rather than the corresponding DoP sample rates of 176/352 KHz. Hard to know which it is using on your receiver, without comparing it to other displays. If the comparable display says things like PCM or MP3, it is probably case 1. If the comparable display is the same rate, it could be the second, although you would think it would then say the sample rate in MHz.
Anyway, just a caution. But, in any case, it seems you are clearly getting DSD from Bubble and Serviio.
-
What is working is scenario 2. My receiver can pull.
So did you try pulling from MC?
-
Poor old Sony. No wonder they struggle to compete. They just can't keep up. (BTW I have a 1999 Sony Receiver and a 2015 Sony 65" TV).
From their very poor manual:
================================================
Formats compatible with home networks
Supported music formats (*1)
MP3 (MPEG 1 Audio Layer-3):
.mp3
AAC/HE-AAC (*2):
.m4a, .aac
WMA9 Standard (*2):
.wma
LPCM:
.wav
FLAC:
.flac, .fla
DSF (*2):
.dsf
DSDIFF (*2)(*3):
.dff
AIFF (*2):
.aiff, .aif
ALAC:
.m4a
Vorbis
.ogg
Monkey’s Audio
.ape
*1Compatibility with all encoding/writing software, recording devices and recording media cannot be guaranteed.
*2The receiver may not play this file format on the home network server.
*3The receiver does not play DST encoded files.
Note
Some files may not play depending on the file format, the file encoding, the recording condition, or home network server condition.
Some files that have been edited on a computer may not play.
Fast forward or fast reverse functions may not be available for some files.
The receiver does not play coded files such as DRM and Lossless.
The receiver can recognize the following files or folders stored in the home network server:
up to folders in the 19th layer
up to 999 files/folders in a single layer
================================================
I would be very surprised if Serviio can push DSF files to the receiver, which can then play them, and MC can't. Either Serviio is sending LPCM, which has been reported previously, or there is some incorrect setting in MC.
Please test each option using exactly the same files, given what the receiver manual has to say about DSF files.
-
Hi,
So in my case using Serviio definitely works like a charm so the above doesn't really apply but I can see why it's difficult to guarantee that DLNA & DSD will work... I'm certain that Serviio sends the raw DSD file to the receiver. Funny thing is that the receiver sees the DSD file from JRiver as WAV even though settings are configured to send the original.
I've compiled some information in the attached files. Good luck :-)
/M
-
Hi,
Funny thing is that the receiver sees the DSD file from JRiver as WAV even though settings are configured to send the original.
)
JRiver is sending DoP which the receiver seems as PCM but it is actually the DSD bitstream packaged in a PCM format, as I explained above. It appears your receiver is not decoding the DoPE format. If you want to send the native DSD file at native DSD sample rates, you uncheck the DoPE box.
Details on DoP here
https://dsd-guide.com/dop-open-standard
-
Hi,
I think I've tried all possible settings to get the DSD file to the receiver. Whether I use DoPE or not makes no difference. (Look at reply #3 in this thread).
/M
-
You showed a screenshot of your MC server settings concerning DOPE, but can you please also post the screenshot showing the MC server settings for AUDIO Conversion?
Also I don’t recall exactly, but I think somewhere in the MC server settings there is a setting called MimeType (or something like that), can you please send a screenshot of that part too?
Finally thanks for the Wireshark captures concerning the Pull from Servio. But can you please show me the upper part of that capture that includes the GET request? (Your picture shows only the HTTP 206 response but not the GET request).
And can you then please try a Pull from MC and also show the respective GET and HTTP 20x responses as well?
EDIT: the fact that you have the MC server profile “Audiophile 24bit DAC” selected, makes me think that you might have the MC server set to Always Convert Audio to L24 (PCM no header), and if that is the case, then a) the Sony would almost certainly display “LPCM” on your playing now screen, and b) it would almost certainly fail to actually play anything (regardless of what DOPE settings you may have)..
-
Hi Andrew,
I'll try to get you that info. Probably not tonight though... The WS captures are for a pull request.
/M
-
I added some additional text in RED in my prior post above.
And yes I know that the captures are for a Pull..
-
If MC were converting DSD to PCM it would convert 1x DSD (2.8Mhz) to 352 KHz PCM. The screen shot shows 176 KHz, which is consistent with DoP. A DSD to PCM conversion of 1x DSD would only get to 176 KHz PCM if there is a conversion set in DSP - Outut format to convert 352 KHz to 176 KHz.
-
Hi,
The extra settings you asked to see. I can't fine mime types anywhere.
I tried to locate other http requests but all I see is 206. I might have filtered something out in my capture because I specified that I only wanted traffic going to a specific port. So might have to try again I guess...
/M
-
If MC were converting DSD to PCM it would convert 1x DSD (2.8Mhz) to 352 KHz PCM. The screen shot shows 176 KHz, which is consistent with DoP. A DSD to PCM conversion of 1x DSD would only get to 176 KHz PCM if there is a conversion set in DSP - Outut format to convert 352 KHz to 176 KHz.
The screen shot says “LPCM / 24 bit” which IMHO is NOT consistent with DOPE over L16 or WAV L16..
-
The extra settings you asked to see.
Could you also expand the “Advanced” tab please?
-
The screen shot says “LPCM / 24 bit” which IMHO is NOT consistent with DOPE over L16 or WAV L16..
DoPE is, by definition, 24 bit. It cannot be 16 bit.
The DoPE setting may override the Format setting, but that is speculation. I have not tried it. But with DoPE set, it should not send 16 bit data.
-
Could you also expand the “Advanced” tab please?
With Original set, there should be no options available under Advanced.
-
With Original set, there should be no options available under Advanced.
Think Andrew is referring to the Advanced tab at the bottom of the frame, not the one under Audio. The one at the bottom has the DSD bitstream checkbox and other DLNA options.
-
This is very strange. BubbleUPnP can push Native DSD from the Serviio server to the STR-DN1080, which proves the STR-DN1080 capability.
MC should have "Bitstream DSD (requires DoPE compliant renderer)" turned off, which was Depechefan's original setting, and it should have just worked, as long as Audio was set to "Original".
If you turn on "Bitstream DSD (requires DoPE compliant renderer)" then you are sending the DSD file in DoPE format, and you must have the MC volume set to 100%, or else you will just get a hiss or white noise. But I'm not sure that the STR-DN1080 supports DSD over DoPE anyway, so that may not work. Note that normal audio devices have a setting of "Maximize device volume during playback", but DLNA servers do not, so you must manually maximise the volume in MC. Maybe that could be improved in future?
Andrew the Mime Type Override at the bottom of the "Advanced" settings group only applies to video by the look of it. Hopefully, there is no spillover into audio.
I have experienced some issues with DLNA settings changes not seeming to take effect, particularly if I haven't set them and then OK'd my way completely out of the dialogue. The obvious example in the "Display name" of the DLNA server, which doesn't change in the top list until the DLNA configuration dialogue has been closed and reopened. Maybe try turning off "Bitstream DSD (requires DoPE compliant renderer)", setting Audio to any "Specified Output Format", saving that by OKing out of the dialogue, then reopen the dialogue and set it to "Original", OK out again and test DSD Push playback to the STR-DN1080.
Also Depechefan, do you have a OneDrive, Google Drive, DropBox or other account that you could put a Wireshark log on, so that Andrew could see the whole thing? (Sorry to dob you in Andrew :D) It seems a waste of time to keep requesting screenshots.
I would appreciate knowing if the Sony STR-DN1080 is capable of Native DSD playback from MC, as that may well be one of my options in the future. I tend to buy Sony gear, though I can't think why really, and their manuals are just awful so it is hard to know what they are really capable of.
JRiver: It would be great if the DLNA Server dialogue was resizable, at least vertically, so that a user could expand all sections and the dialogue, and hence post a screenshot of all settings in one go. It would help with this sort of user support a lot. It has been a problem in lots of past threads. There seems to be no reason not to allow dialogues to be resizable. Thanks.
-
Okay, the STR-DN1080 seems to be a bit quirky. This problem was actually solved a couple of years ago. See https://yabb.jriver.com/interact/index.php?topic=111822.0
The "C:\Program Files\J River\Media Center 25\Data\Default Resources\FileAssociations.xml" file now contains these three lines:
<Item Name="dff">audio/x-dff;audio/dff</Item>
<Item Name="dsf">audio/x-dsf;audio/dsf</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
I think that should have fixed the issue in that thread above. But maybe not. So try this if nothing above works.
1. Make a copy of the "FileAssociations.xml" file so that you can revert to the original if required.
2. Shut down MC and the MC Media Server if it is running. Also, make sure Serviio and any of its services aren't running. As a separate issue, you shouldn't have an DLNA server running on a NAS, if you use one. We haven't even confirmed you are running MC on Windows, where your files are, how you imported them and so on. Maybe if this doesn't work we should do all that. But later.
3. Edit the "FileAssociations.xml" and change the above three lines to:
<Item Name="dff">audio/x-dff</Item>
<Item Name="dsf">audio/x-dsf</Item>
<Item Name="dsd">audio/x-dsd</Item>
4. Restart MC and test again sending Native DSD (not DSD over DoPE) and see if that works.
5. If 4. didn't work, close MC and Media Server, edit the "FileAssociations.xml" and change the above three lines to:
<Item Name="dff">audio/dff</Item>
<Item Name="dsf">audio/dsf</Item>
<Item Name="dsd">audio/dsd</Item>
6. Restart MC and test again sending Native DSD (not DSD over DoPE) and see if that works.
Report back what happened.
-
JRiver: It would be great if the DLNA Server dialogue was resizable, at least vertically, so that a user could expand all sections and the dialogue, and hence post a screenshot of all settings in one go. It would help with this sort of user support a lot. It has been a problem in lots of past threads. There seems to be no reason not to allow dialogues to be resizable. Thanks.
Good idea.
Coming next build:
Changed: Made the DLNA servers dialog larger and made it sizable.
-
Thanks Matt!
-
Hi,
I've tried to change the mime types to match the above-mentioned suggestions. restarted the JRiver service and disabled DoPE. in the Advanced section of the Media Network settings. The basic setting is "Mode: Original". When I browse to the folder containing the DSF files I get a message saying that there are no playable files in that location. I'm happy to do some more troubleshooting but it seems to be very complicated to make this work. I'm using Windows 10 as my OS. The files are stored locally on the PC.
I'll try to make a new capture and upload to Onedrive. Thanks for that suggestion.
P.S. This is mostly because it's an interesting mystery. Tbh. I'm happy with Serviio so...
/M
-
Hi,
Here is a complete capture of a pull request for a DSF file from the Sony receiver to Serviio:
https://1drv.ms/u/s!Aly2HCHRkhMrjIJ0Xaj4sNaaIU2koQ?e=LtHvlb
/M
-
DoPE is, by definition, 24 bit. It cannot be 16 bit.
The DoPE setting may override the Format setting, but that is speculation. I have not tried it. But with DoPE set, it should not send 16 bit data.
Look. One thing is clear from the DMRA renderer report: the Sony will NOT play L24 audio. So if the OP is trying to push anything in an L24 wrapper (be it PCM or DOPE) it will simply NOT play. It’s got nothing to do with the DOPE setting in MC; it is about the lack of L24 capability of the renderer...
-
That's okay Andrew, because the STR-DN1080 doesn't support DSD using DoPE, only Native DSD. So, no 24 bit processing required.
The STR-DN1050/70/80 range seems to need a specific mime type to work. The internet is full of discussions about the STR-DN1050/70/80 and how to make them play DSD. The Minimserver DLNA solved the issue back in 2010 from memory, and Serviio solved it sometime after that, after a bit of a rocky period. Hence my suggestion above.
JRiver seem to have added the right mime types to the FileAssociations.xml file, but both audio/x-dsf and audio/dsf are included, which the STR-DN1080 may not handle correctly. Hence my suggestion above.
Depechefan, you say you tried changing the mime type. Did you try both versions I documented? Completely restart MC between changes?
-
Morning,
Yes, I tried both options for the mine types. It's weird that it didn't fix it. I restarted the service and I even tried restarting the PC.
A question about 24 bit because I can play 24 bit flac files but maybe that's different?
/M
-
Not from the manual but from the website https://www.sony.com.au/electronics/av-receivers/str-dn1080/specifications:
Decoding Format for USB/Network Client
HI-RES FORMAT
DSDIFF (DSD): Up to 5.6MHz 5.1ch , DSF: Up to 5.6MHz 5.1ch , WAV(LCPM): Up to 192kHz/24 bit 7.1ch,AIFF(LCPM): Up to 192kHz/24 bit 5.1ch, FLAC: Up to 192kHz / 24 bit 5.1ch , ALAC: Up to 192kHz / 24 bit 5.1ch
-
A question about 24 bit because I can play 24 bit flac files but maybe that's different?
Yep, that's different, because you are sending the FLAC files themselves to the STR-DN1080 and it is doing the decoding, hence it handles the 24 bit issue. That is because you have the DLNA Audio Mode set to "Original", which means MC doesn't do anything to the media it is sending, and just sends the FLAC file. DLNA is a file-based protocol. There is no 24 bit PCM involved in the transfer from MC to the STR-DN1080.
You can simply test or confirm this by changing the DLNA audio settings to "Specified Output Format" and trying to play a 24 bit FLAC file using the formats "PCM L24 No Header" and "PCM 24-bit". MC will then decode the FLAC file to 24 bit PCM and send that to the STR-DN1080. Neither should play correctly.
WAV(LCPM): Up to 192kHz/24 bit 7.1ch
That bit is interesting. Although again for DLNA, a WAV file would be sent to the STR-DN1080, which would then do the decoding. This is different to MC sending 24 bit LPCM, which is what DSD using DoPE requires. According to the DMRA report the STR-DN1080 only supports L16, which is 16 bit LPCM without a header, I believe. WAV files are LPCM with a header anyway I believe, so a slightly different format.
If you run the DRMA against MC, you will see it support various versions of "L24", or 24 bit LPCM. For example, it declares support for the following formats and more;
http-get:*:audio/L24;rate=192000;channels=8:DLNA.ORG_PN=LPCM
http-get:*:audio/L24:*
file:*:audio/L24:*
MC is evaluated to support those formats as well.
Andrew, feel free to correct any of the above, because I'm no expert on this stuff.
I think the only way forward is to work out what mime type Serviio is sending to the STR-DN1080, and make MC do the same. I haven't looked at the Wireshark log, and may not be able to make sense of it anyway.
-
I think the only way forward is to work out what mime type Serviio is sending to the STR-DN1080, and make MC do the same. I haven't looked at the Wireshark log, and may not be able to make sense of it anyway.
Indeed. I am planning to look at the Wireshark capture later today.
-
Here is a complete capture of a pull request for a DSF file from the Sony receiver to Serviio:
https://1drv.ms/u/s!Aly2HCHRkhMrjIJ0Xaj4sNaaIU2koQ?e=LtHvlb
Sorry but this is not a complete capture. It only shows half of the dialog — namely it only shows messages sent from the pc (192.168.1.30) to the renderer (192.168.1.233). But it does not show any messages sent from the renderer to the pc.
In order to diagnose your problem, I need to see both sides of the dialog — specifically to see what file the renderer is requesting (the GET) and the respective matching response from the Servio server.
I guess that you made your capture with a capture filter like src=192.168.1.xxx or dst=192.168.1.xxx and both those filters will only capture one side of the dialog (either from the source or to the destination). Instead you need to set a capture filter like host=192.168.1.xxx which will capture the traffic in both directions to/from the given device. (So I suggest host=192.168.1.233 should get everything to and from the Sony).
-
Hi,
OK, that could well be. I'll make a new one when I get home :-)
/M
-
Hi Andrew
This one looks better, I think:
https://1drv.ms/u/s!Aly2HCHRkhMrjIJ1lv75FG2r2xnROg?e=Qftb9E
/M
-
I had a look at the Wireshark log just to see if I could work out what was going on. Just curious. Learning.
It looks like the STR-DN1080 requests a DSF file, but Serviio sends back a mime type of DSD. See attached image with highlights.
So maybe the FileAssociations.xml file needs to read;
<Item Name="dsf">audio/dsd</Item>
Or perhaps even more fully;
<Item Name="dff">audio/x-dsd;audio/dsd</Item>
<Item Name="dsf">audio/x-dsd;audio/dsd</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
In other words, the mime type for Native DSD needs to be set to audio/dsd, regardless of the file container it is in.
Maybe the references to x-dsd could be dropped as well. Guessing a lot here. But Serviio is just using a mime type of audio/dsd.
What do you think Andrew?
-
Hi Roderick
Yeah, I had the same thought when I looked at the capture. Just tried to change the mime types to audio/dsd for dsf files. And it actually works :-)
So if anyone is interested or has the problem I have attached my fileassociations.xml file. (If you want to use this then change file type from .txt to .xml)
Thanks for the great assistance!
/M
-
Thanks for posting the capture. I can confirm your findings. The essential part is below. The renderer does a GET for the file, and it says it will accept any mime-type “Accept: */*”. And the Servio server responds with “Content-Type: audio/dsd”. And this seems to work.
I suppose MC is returning another Content-Type; that the renderer does not accept; even though the Sony says it would accept */* (!!). This means that the Sony is at fault, because if it cannot Accept: */* then it should say so — for example by saying Accept: audio/dsd. If the renderer was explicit then server could respond explicitly too. Otherwise the server has to make a best guess at what it should send. In this case Servio made a lucky guess, and MC did not.
You should inform Sony about this..
GET /resource/3225/MEDIA_ITEM/DSF-0/ORIGINAL HTTP/1.1
Host: 192.168.1.30:8895
Accept: */*
Range: bytes=0-15
X-AV-Physical-Unit-Info: pa="STR-DN1080"
X-AV-Client-Info: av=5.0; cn="Sony Corporation"; mn="STR-DN1080"; mv="2.0"
getcontentFeatures.dlna.org: 1
transferMode.dlna.org: Streaming
HTTP/1.1 206 Partial Content
Content-Length: 16
Content-Type: audio/dsd
Cache-control: no-cache
Connection: close
Content-Range: bytes 0-15/253534447
contentFeatures.dlna.org: DLNA.ORG_PN=DSF;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Date: Thu, 26 Sep 2019 17:25:26 GMT
realTimeInfo.dlna.org: DLNA.ORG_TLAG=*
Server: Windows_10 UPnP/1.0 DLNADOC/1.50 Serviio/2.0
transferMode.dlna.org: Streaming
DSD ............
-
Hi Andrew,
That makes perfect sense. I'll see if I can find a suitable place to give Sony this information... ;)
Thanks again!
/M
-
Great that you got it working. I'm wondering if there is a more universal solution.
Specifically, I don't know how the original mime type specification format in the FileAssociations.xml works.
i.e.
<Item Name="dff">audio/x-dff;audio/dff</Item>
<Item Name="dsf">audio/x-dsf;audio/dsf</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Does that mean that MC will, using dsf files as an example, try to send files marked as "audio/x-dsf" mime type first, and if that doesn't work, send as "audio/dsf" mime type? Or does it respond with all mime types listed, so that the Renderer can pick the mime type it wants, or something?
I'm wondering if changing the FileAssociations.xml file to read;
<Item Name="dff">audio/x-dff;audio/dff;audio/dsd</Item>
<Item Name="dsf">audio/x-dsf;audio/dsf;audio/dsd</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Or maybe;
<Item Name="dff">audio/dsd;audio/x-dff;audio/dff</Item>
<Item Name="dsf">audio/dsd;audio/x-dsf;audio/dsf</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Would work, and retain compatibility with other Renderers, meaning that the default FileAssociations.xml could be updated and supplied with a MC update by JRiver.
==========================================
Regardless, you may want to complete one more step Depechefan.
You have currently edited the FileAssociations.xml file in the "C:\Program Files\J River\Media Center 25\Data\Default Resources\" directory. In order to prevent that file from being overwritten during an update, I suggest that you make the following changes.
Create a directory "C:\Program Files\J River\Media Center 25\Data\Custom Resources\" if you don't have one already.
Move your modified FileAssociations.xml file to that directory.
Rename your saved FileAssociations.xml file in "C:\Program Files\J River\Media Center 25\Data\Default Resources\" back to its original name. i.e. "FileAssociations.xml".
MC will then look in the "Custom Resources" directory before the "Default Resources" directory, find your modified "FileAssociations.xml" file and use that instead of the default version. Nothing in the "custom Resources" directory is overwritten by a MC update, or major version Upgrade. In the case of a major version Upgrade, for example MC25 to MC26, I think you will need to copy your "Custom Resources" directory to the new version, but I'm not sure. MC may copy it across if it finds the previous version of MC.
If the default version of the "FileAssociations.xml" file can be updated so that it works with your STR-DN1080 and all other Renderers, then you wouldn't need to worry about the "Custom Resources" directory issue. Hence my wondering about the functionality of those specific lines in the "FileAssociations.xml" file above.
What say you JRiver?
-
Hi Roderick,
That is an interesting idea. I'm not home today but will try your suggestions tomorrow and also place the modified file in the custom directory.
Will keep you updated.
/M
-
Great that you got it working. I'm wondering if there is a more universal solution.
Possibly yes.
The UPNP specification is as follows..
1) In the Content Directory Browse process, when a Digital Media Server publishes information about a track in its library, it must advise meta data for ALL the different mime types that it is capable of delivering (e.g. audio/wav, audio/mp3, audio/flac, or whatever) together with a corresponding url for getting each mime type of that track.
2) Then the Digital Media Render will fetch its desired mime type of that track by doing a GET for the respective url in the meta data provided by the DMS, and also specifying an Accept: audio/xyz header in the GET request.
The above describes a Pull process. But when doing a Push, things are a bit different, since step 1) is omitted, and instead the DMS sends a SetAVTransportURI command telling the DMR what it should play. However I think the SetAVT command essentially contains the same meta data as a Browse response, so step 2) can be followed also in this case.
In order to streamline the above process, the UPNP specification also has a mechanism GetProtocolInfo whereby a DMS can publish a list of all mime-types that it can deliver (source protocol info) and a DMR can publish all those that it can play (sink protocol info). If the DMS has done a proper matching of sink and source protocol info, then in Browse or SetAVT it can restrict the list of offered mime types to those that a) it can deliver, and b) that it knows the DMR can play.
So I think there are several improvements that MC can make.
a) Implement GetProtocolInfo properly, and use its findings in Browse and SetAVT
b) Offer all mime type flavours audio/dsd, audio/dsf, audio/dff and their x-variants in Browse and SetAVT
c) If there is an explicit Accept mime type in the GET, then use the same mime type in the responding Content-Type
-
Hi again,
Now back and able to test. I moved the fileassociations.xml file to the custom directory. JRiver picks it up - just installed an update so can confirm it's not overwritten :-)
Great that you got it working. I'm wondering if there is a more universal solution.
Specifically, I don't know how the original mime type specification format in the FileAssociations.xml works.
i.e.
<Item Name="dff">audio/x-dff;audio/dff</Item>
<Item Name="dsf">audio/x-dsf;audio/dsf</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Does that mean that MC will, using dsf files as an example, try to send files marked as "audio/x-dsf" mime type first, and if that doesn't work, send as "audio/dsf" mime type? Or does it respond with all mime types listed, so that the Renderer can pick the mime type it wants, or something?
I'm wondering if changing the FileAssociations.xml file to read;
<Item Name="dff">audio/x-dff;audio/dff;audio/dsd</Item>
<Item Name="dsf">audio/x-dsf;audio/dsf;audio/dsd</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Or maybe;
<Item Name="dff">audio/dsd;audio/x-dff;audio/dff</Item>
<Item Name="dsf">audio/dsd;audio/x-dsf;audio/dsf</Item>
<Item Name="dsd">audio/x-dsd;audio/dsd</Item>
Would work, and retain compatibility with other Renderers, meaning that the default FileAssociations.xml could be updated and supplied with a MC update by JRiver.
I tried this. First option didn't work. I was back to the error message saying that there are no playable files in the location chosen. Second option works as expected though. So for my scenario that is probably a good choice.
Posted a link to this thread in a Sony UK forum. Haven't received a reply though. I can see that they are discussing wake on lan issues in that forum so that is probably my next challenge... ;-)
/M
-
Thanks for letting us know which one worked.
WOL, for a Receiver... :o fun ;D
-
Hi again,
So I got a reply from Sony after I created a support case. You can see it below. So the long and short of it is that they don't care... I'll probably pick a different brand next time I'm in the market for a receiver :-)
Thank you for contacting Sony support.
We are sorry to learn that you are facing difficulties with your Sony STR-DN1080 device using DSF files with the DLNA feature.
Unfortunately we would like to highlight that we do not guarantee the functionality of DSF files using DLNA, for more information, please check the help guide below including the restrictions:
https://helpguide.sony.net/ha/strdn108/v1/en/contents/TP0001221399.html
You may also find this information using the manual link below on page 64 restriction number “2”:
https://www.sony.co.uk/electronics/support/res/manuals/4686/1a5e9c2b4143ad36dd5cb360f2a11851/46865241M.pdf
Should you have any further questions, please feel free to reply to this email.
Thank you for your enquiry.
Yours sincerely,
Seif
SONY SUPPORT TEAM
SUPPORT: http://www.sony.co.uk/support/en
/M
-
Hmm. Don’t be in a hurry to change suppliers. At least you got it working with the Sony..
-
It is complicated for a company to make a change to the firmware of a AV receiver. The software fix is easy enough to do, but rolling out an actual firmware update is a significant task and it is only done for significant improvements. A mistake can brick receivers. There was last one for your receiver a year ago. There may be another one, but firmware updates for $450 receivers are not very common. Their answer basically said that they are not going to roll our a firmware update just for this issue, especially since they clearly said the DSD may or may not work. That is disappointing given Sony's history in SACD/DSD, but that was a long time ago.
-
Oh well, as per their manual and help, they did say it may not work.
Changing brands can also be a bit of a crapshoot. Denon and Marantz have DLNA issues, according to reports here. People have had problems with other brands. It just shows you have to do your research before buying.
-
Sometimes pulling from the server will work when pushing to the renderer won't. Try controlling it from the Sony receiver side.
-
It has been fixed by editing the "FileAssociations.xml" file Jim. All good now.
-
Morning,
I guess I didn't make myself clear. I find it disappointing that Sony apparently don't take an interest in solving this. This makes me less likely to choose one of their products in the future. At this point everything is fine. I have it working to send dsf files directly to the receiver for it to decode them.
I'll not purchase a new receiver until they start supporting 8k passthrough. And I'm going to buy a more expensive device with more focus on audio next time anyway.
/M
-
I'm going to buy a more expensive device with more focus on audio next time anyway.
Enjoy your shopping spree!
-
And I'm going to buy a more expensive device with more focus on audio next time anyway.
/M
The ES line is a significant step up. However, the firmware for things like DLNA and DSD are often common across the entire line. ES adds lots of features, but it does not necessarily modify features like that. I am a fan of Yamaha, but I have no experience with their DLNA. I use a USB DAC for DSD playback. Something to consider.
-
Hi,
Thanks for the suggestions. I haven't quite understood how the USB DAC thing works so I need to look into that, I think. When I bought the Sony one of my main reasons to pick that one is that it supports DSD over HDMI. I thought I could use Apple TV or Nvidia Shield to send the files. Now I know that basically no streaming devices (or PCs) support DSD over HDMI so I have no source I can use. My research indicates that I'd need to buy an Oppo player or a Dune HD extreme or similar. So that will be pretty expensive. The other option I thought I had was to connect to my NAS using CIFS, NFS or something but the Sony doesn't support that. So this is why I've ended up with DLNA as my best option (unless I copy my music to a USB drive - how do you make a playlist then?)
So I know much more now to do some better research before my next purchase. You live and learn...
/M
-
For a usb DAC, you connect the DAC via usb to the PC and then connect analog (RCA) cables from the DAC to the analog inputs on your receiver. The IFI Nano is an inexpensive DAC with usb input and RCA outputs. It does both PCM and DSD. There are also off brand DACs for not much money. Of course, the price goes up quickly. Receivers benefit from a mass market, where DACs, especially DSD DACs, are a much more specialized market.
-
Ah, I see. Makes sense. It would mean also investing in a suitable PC then. NUC or something. The media center PC I currently use is in a closet far from the receiver.
-
That's when DLNA makes sense. If you use a second PC, you can use MC in client/server mode, but the whole setup becomes more complicated.
At least you have your DSD working now.
Enjoy the music.
-
Exactly - and I do very much :)
-
Happy to find this work around!
But on a Mac,
where would I find the original FileAssociations.xml file and where should I put a custom one? ?
-
I can answer one of my questions at least.
The original FileAssociations.xml file is in the Application Contents of Media Center,
in the subfolder Contents/Resources/Data/Default Resources
I tried to put my own FileAssociations.xml file in ~/Library/Application Support/J River/Media Center 25/Data/Custom Resources/
But it's ignored.
But I can report that the dff/dsf file types fix works if I modify the default original xml file (until I update...)
It even sends the 6 channels files without problems now.
I am happy!