Originally Posted by philgoble
I tried OShare. I just opened up the DLNA published site and navigated through the menus where the file was and selected the file to play it. OShare /Denon could play the file as a DSD this way without a problem. Since I had always been pushing the files from JRiver through my computer, JRemote or the Denon app I decided to try to navigate to the file via the DLNA (Audiophile 24-bit DAC) I had set up in the same manner. When I did that I was able to play the file as a DSD file.
So the question now is why can't I used JRemote or the Denon app for this purpose. It seems like there must be some kind of setting issue, or a problem with JRiver or the Denon. Do you have any other suggestions?
I have posted my problem in other places and corresponded with a person on JRiver who had me run a utility to make sure the Denon supported DSD, which it obviously does. I will post over there again with these results also to see what anyone can suggest.
Thanks very much for this suggestion which has shed some more light on this. If I ever resolve this totally I will be sure to post here for others benefit.
Ok - so this is subtle - and the problem could be in any one of several places. So let's knock another one out now (or not ;-) )
I actually doubt that the problem is with JRemote. Here is an experiment to check that out. Fire up the JRiver UI on the PC on which it is installed. Then use the UI on that PC to "play" the same DSD file to the Denon. (Yes - you can do this straight from the JRMC UI). My guess is that you will see the same behavior that you see using JRemote.
When you browse and play media from the Denon front end, you are using the Denon as a DLNA "Player". When you use JRemote to browse media and "push" it to the Denon, the Denon is acting instead as a DLNA "Renderer".
One disturbingly-common problem is that many Renderer implementations are "afterthoughts". The folks who program them have already programmed the player implementation and realize that they are 90% of the way to a renderer. They then go implement almost
all of the needed renderer-specific functionality because it is nearly free. The catch - they miss details - like responding PERFECTLY ACCURATELY to DLNA queries about what is supported and such, or using an appropriate de-jitter buffer on the network side of the renderer. I have seen this on numerous occasions - including with Oppo renderer implementations at one time or another. "Ooh - we added support for another media type. YAY US!!!.... OOPS, we forget to change the answer to the 'What media types does your renderer support?' DLNA message...BAD Us. Bad dog!" This mistake and its cousins are incredibly easy to make - and I (a 52-year-old software developer who started writing code in high school) could easily see myself making those same kinds of mistakes. it only takes a very small detail missed in this scenario.
So the problem is probably a subtle incompatibility between the DLNA RENDERER implementation in the Denon and the DLNA SERVER implementation in JRMC. This could be due to any number of issues - but the JRiver folks should be able to get you a long way - even if, in the end, they tell you that Denon needs to fix their renderer.