Topic: DLNA with Denon (Read 24874 times)

Rubberduck0 · « **on:** February 10, 2013, 06:00:22 am »

According to my tests it seems that at least certain Denon devices do not get well along with MC. In principle it works, but seek function (to jump to a certain time index of a track) and pause cause problems. I have found the following behaviour:

Setting: Denon AR4311, MC 18.0.128, iPad apps PlugPlayer (=PP) and 8player (=8P)
Legend: S=Seek, P=Pause, +=works, -=does not work

Code: [Select]

Source/DLNA Profile / 8player / PlugPlayer / MC itself
--------------------------------------------------------
Synology NAS DLNA     P-, S-    P-, S-       P+, S- *
MC/Generic DLNA       P+, S+    P+, S-
MC/Denon              P-, S-    P-, S-
MC                                           P+, S- **

*  = ignores the new time index and continues to play
** = when a new time index is set (e.g. 50% of track), then MC starts the track from the beginning

Since 8P works with the Generic DLNA profile I played around with the differences between the Denon and Generic profile in MC (under the advanced settings for the DLNA server). The feature which has to be set to make it work is "DLNA" (the first setting under advanced).

My conslusions:
1) Denon seems to be difficult to handle via DLNA as the source (NAS or MC) does not matter.
2) At least one combination (8P with Generic DLNA profile) does work, so there has to be a solution.
3) The "Denon" preset for the DLNA server is not working, so I suggest to update this in a future version of MC. At least the setting "DLNA" should be enabled (do not know what the others do, e.g. DLNA Extra).
4) When MC directly plays on the Denon (so not other controller involved) then pause works, but not seek. Unfortunately MC provides settings for DLNA servers, but not for MC itself. So I cannot set the advaned feature "DLNA" enabled for MC and hence seek does not work. So either the hard coded settings for MC should be updated to work with a Denon device or there should be options to configure how MC communicates with other devices.

Note: This is continued from the thread DLNA Search not working, due to a missunderstanding on my side.

bob · « **Reply #1 on:** February 10, 2013, 01:17:03 pm »

The Denon profile in MC is for older devices, you won't want to use that (it probably should be removed).
Start with the Generic DLNA device and have only that in your DLNA server configuration.
Try turning on "enable bitrate field" in the MC advanced settings.
See if you get any different results.

Rubberduck0 · « **Reply #2 on:** February 10, 2013, 04:41:05 pm »

"Enable bitrate field" changes nothing (so 8P: P+/S+; PP: P+/S- like before). Note: I have to set "Use flat URLs" otherwise I do get an error in PP, but I guess this has nothing to do with the problem.

However, finding the correct DLNA server settings is only the minor issue in my opinion. At least there is a working combination (using 8P instead of PP).

But my point 4) is more important, I think, and has nothing to do with the DLNA server settings. MC itself cannot handle the Denon correctly and there are no options (at least I know of) to correct this (as compared to the DLNA server settings, where there are options). 8P must do somethings right, which MC itself does not...

By the way, there is another issue, which I think could be solved very easily:
The Denon AVR4311 has an always on network card. When using 8P or PP I just have to start playback and the Denon switches on from stand-by and starts playing. Veeery convenient. The start-up of the Denon takes a while of course (around 10-15 seconds), but the apps can handle that and I guess retry the play command for long enough until the Denon responds.
Not so MC. When I do the same with MC as the controller, I get an error message (on my server PC, where I do not see it normally) that the device does not respond or so. I think this is just because MC does not retry long enough and gives up too early. Could this be changed? It's a small thing but makes live much easier (no need to get the remote to switch on the receiver, just take your phone and press play).
--- This issues was added upon a very urgent (and pressing) request from my family members ;-) ;-) ;-) ---

Just a personal note, why I think point 4) is more important:
I tried several DLNA apps for iOS and did not find any combination (server, controller, renderer) really working good. Most DLNA apps are way to complicated to use, none is working reliable (playback stops randomly after some time, sometimes I had to restart all devices to get it working again, etc. This got me constant complaints from my family. My personal feeling is, that the DLNA standard is the real problem and does not work reliable if the three roles are on different devices. So, I changed to JRemote, to eliminate one role (server and controller is combined in MC), which is like heaven on earth, as it has a very good UI, and works much more reliable (complaints almost stopped ;-)). The only issues are the start-up thing and the seek function, which I really regard as important, especially if you listen to 30 min tracks or audio books.

bob · « **Reply #3 on:** February 11, 2013, 06:52:55 pm »

You can right-click on the Denon zone in MC and choose the MC DLNA server to associate the renderer with.

Rubberduck0 · « **Reply #4 on:** February 12, 2013, 11:26:36 am »

Thanks again for trying. But didn't help either. As I have only one DLNA server, it tells me that it is already associated with this. Then I found these other DLNA controller options 'ignore transport events' and 'disable setnext'. Both were unset and I tried every combination enabling them, but nothing changed.

I think I understand now: JRiver uses the advanced settings of one of the DLNA servers, so that is why there are no separate options.
So, I tried to enable every advanced option there is (one by one) but again nothing changed. My default and current settings are (based on the Generic DLNA profile): 'DLNA', 'DLNA Extra', and 'flat URLs'. With these settings 8P works but JRiver not (I refer to seek only). As already pointed out the critical setting is 'DLNA', without that 8P doesn't work either.

Any chance for a solution? Cannot believe that I am the only one with this problem, as Denon is quite common. Also a solution for the start-up thing would be very welcome. I swear, if these two issues are solved, I will never ever look sideways to any other MC and continue to pay the annual (license) fee with pleasure...

bob · « **Reply #5 on:** February 12, 2013, 12:32:22 pm »

I'm going to guess that the 8p controller is doing something to get a time based seek. The only way to really find out is to do a trace using wireshark.
It would be difficult in your situation since you've got a wireless controller. You'd do the trace on your PC but the only way you'd see all of the interactions is if you had a HUB (not switch) connecting the PC and Denon. Hub's are pretty hard to find these days...

Rubberduck0 · « **Reply #6 on:** February 16, 2013, 06:06:19 pm »

Sorry, but it is not possible for me to give you those information.

Is there any other option to solve this?
(and again I have to ask if there is any chance that this "wait-longer-before-error" issue will get fixed)

Rubberduck0 · « **Reply #7 on:** February 17, 2013, 05:02:02 pm »

I wrote to the developer of 8player and he was kind enough to give me the following information of how the app does a seek. I want to thank Alex again for sharing this with me.
I hope this information is what is needed to solve the issue as I lack the knowledge to judge this.

------- This is the info I got ----------
8player calls "Seek" the function of "urn:schemas-upnp-org:service:AVTransport:1" service with the following parameters:
- Unit: REL_TIME
- Target: x:yy:zz (where x - hours, yy - minutes, zz - seconds)

csimon · « **Reply #8 on:** February 18, 2013, 05:31:50 am »

Quote from: Rubberduck0 on February 10, 2013, 04:41:05 pm

I tried several DLNA apps for iOS and did not find any combination (server, controller, renderer) really working good. Most DLNA apps are way to complicated to use, none is working reliable (playback stops randomly after some time, sometimes I had to restart all devices to get it working again, etc. This got me constant complaints from my family. My personal feeling is, that the DLNA standard is the real problem and does not work reliable if the three roles are on different devices. So, I changed to JRemote, to eliminate one role (server and controller is combined in MC), which is like heaven on earth, as it has a very good UI, and works much more reliable (complaints almost stopped ;-)). The only issues are the start-up thing and the seek function, which I really regard as important, especially if you listen to 30 min tracks or audio books.

I agree! DLNA works somewhat but is still very flawed. I don't know why this is so - surely it's a set protocol but in practice it's very very difficult to get devices to interoperate as the protocol was meant to get them to do.

bob · « **Reply #9 on:** February 18, 2013, 04:35:51 pm »

Quote from: Rubberduck0 on February 17, 2013, 05:02:02 pm

I wrote to the developer of 8player and he was kind enough to give me the following information of how the app does a seek. I want to thank Alex again for sharing this with me.
I hope this information is what is needed to solve the issue as I lack the knowledge to judge this.

------- This is the info I got ----------
8player calls "Seek" the function of "urn:schemas-upnp-org:service:AVTransport:1" service with the following parameters:
- Unit: REL_TIME
- Target: x:yy:zz (where x - hours, yy - minutes, zz - seconds)

PM'ing you with a test build.
This is only the try to debug the seek problem with MC as controller.

Rubberduck0 · « **Reply #10 on:** February 19, 2013, 07:07:50 am »

YIPPIE-YA-YEAH!!!! Yes, it works with the test build (also with JRemote of course)!

Could this be added as a setting for the DLNA Controller (Options/Media Network/Advanced/DLNA Controler)? That would really be great.

Cough... cough... and yet, I dare to ask again, regarding the time span until JRiver throws up an error, if the renderer does not answer. I only dare to do this, because I think that this would be a minor and easy change. Is there any chance that this could be changed too? ^_^

bob · « **Reply #11 on:** February 19, 2013, 09:54:57 am »

Quote from: Rubberduck0 on February 19, 2013, 07:07:50 am

YIPPIE-YA-YEAH!!!! Yes, it works with the test build (also with JRemote of course)!
Could this be added as a setting for the DLNA Controller (Options/Media Network/Advanced/DLNA Controler)? That would really be great.

It seems that the Denon doesn't support high precision time and doesn't return an error when we try to use it. We may just remove the high precision time for now.

Quote

Cough... cough... and yet, I dare to ask again, regarding the time span until JRiver throws up an error, if the renderer does not answer. I only dare to do this, because I think that this would be a minor and easy change. Is there any chance that this could be changed too? ^_^

This is actually more difficult than it sounds. We need to change the threading on the whole Media Network to implement a longer timeout properly. Another one for the todo list...

Rubberduck0 · « **Reply #12 on:** February 21, 2013, 05:46:11 am »

I am very sorry, but on the technical side I cannot comment. So I cannot tell, if it is better to add an option or to remove the high prescision time all together.
However, is it OK to use the special build you sent me until this is implemented?

Quote from: bob on February 19, 2013, 09:54:57 am

Quote from: Rubberduck0 on February 19, 2013, 07:07:50 am
Cough... cough... and yet, I dare to ask again, regarding the time span until JRiver throws up an error, if the renderer does not answer. I only dare to do this, because I think that this would be a minor and easy change. Is there any chance that this could be changed too? ^_^
This is actually more difficult than it sounds. We need to change the threading on the whole Media Network to implement a longer timeout properly. Another one for the todo list...

I understand... May I suggest something different then? Right now it seems that while the error message box is presented, JRiver does not accept any commands (at least from remote via JRemote) and thus I have to go to a PC, connect to the server and click away the dialog box. It would already help greatly, if that behavior could be changed, i.e. either there is an option to prevent the error message box to pop-up, there is no message box at all, or JRiver does not wait until the message box is closed (but I think this is not really possible). Then I could still start playback with JRemote (the only minor drawback is to hit play a second time after the Denon is up and running) and it'd prevent the hazzle if somebody starts playback with Denon off by accident.

I also would think that such message boxes should bother many other people too, if they use JRiver as a server on a remote PC. In fact, the more I think of it, the more I am convinced, that a program which acts in the background, like Media Server does, should throw up no message boxes at all, which need human interaction. Most programs use balloon pop-ups for messages (typically virus scanner), which disappear after some time.
Would that be a (first) solution which could be implemented easily?

bob · « **Reply #13 on:** February 21, 2013, 10:32:44 am »

Quote from: Rubberduck0 on February 21, 2013, 05:46:11 am

I am very sorry, but on the technical side I cannot comment. So I cannot tell, if it is better to add an option or to remove the high precision time all together.
However, is it OK to use the special build you sent me until this is implemented?

It's totally fine to use that test build

Quote

This is actually more difficult than it sounds. We need to change the threading on the whole Media Network to implement a longer timeout properly. Another one for the todo list...

I understand... May I suggest something different then? Right now it seems that while the error message box is presented, JRiver does not accept any commands (at least from remote via JRemote) and thus I have to go to a PC, connect to the server and click away the dialog box. It would already help greatly, if that behavior could be changed, i.e. either there is an option to prevent the error message box to pop-up, there is no message box at all, or JRiver does not wait until the message box is closed (but I think this is not really possible). Then I could still start playback with JRemote (the only minor drawback is to hit play a second time after the Denon is up and running) and it'd prevent the hassle if somebody starts playback with Denon off by accident.

I also would think that such message boxes should bother many other people too, if they use JRiver as a server on a remote PC. In fact, the more I think of it, the more I am convinced, that a program which acts in the background, like Media Server does, should throw up no message boxes at all, which need human interaction. Most programs use balloon pop-ups for messages (typically virus scanner), which disappear after some time.
Would that be a (first) solution which could be implemented easily?

Could you give me the exact text of the message box you see that keeps the remote from responding?

Rubberduck0 · « **Reply #14 on:** February 21, 2013, 03:47:54 pm »

Quote from: bob on February 21, 2013, 10:32:44 am

Could you give me the exact text of the message box you see that keeps the remote from responding?

Sure. The message box says:

Information
There was a problem controlling the selected DLNA device. Double-check your device, server, and network settings.
[OK]

bob · « **Reply #15 on:** February 26, 2013, 09:54:43 am »

Quote from: Rubberduck0 on February 21, 2013, 05:46:11 am

...
I understand... May I suggest something different then? Right now it seems that while the error message box is presented, JRiver does not accept any commands (at least from remote via JRemote) and thus I have to go to a PC, connect to the server and click away the dialog box. It would already help greatly, if that behavior could be changed, i.e. either there is an option to prevent the error message box to pop-up, there is no message box at all, or JRiver does not wait until the message box is closed (but I think this is not really possible). Then I could still start playback with JRemote (the only minor drawback is to hit play a second time after the Denon is up and running) and it'd prevent the hazzle if somebody starts playback with Denon off by accident.

I also would think that such message boxes should bother many other people too, if they use JRiver as a server on a remote PC. In fact, the more I think of it, the more I am convinced, that a program which acts in the background, like Media Server does, should throw up no message boxes at all, which need human interaction. Most programs use balloon pop-ups for messages (typically virus scanner), which disappear after some time.
Would that be a (first) solution which could be implemented easily?

I checked on this and you shouldn't get that message box when initiating the play command from JRemote (or Gizmo or Webplay for that matter).
Is it repeatable and if so, can you give me the exact steps to duplicate it? Thanks...

Rubberduck0 · « **Reply #16 on:** February 26, 2013, 04:50:47 pm »

Interesting... However, it is definitely repeatable (100%). The exact circumstances are:

* JRiver Media Server is running (no matter if I just started it and this is first thing I do, or if it runs for a longer time already)
* Denon is in standby (network card is active, so JRiver will list it as zone)
* I use JRemote to start playback of any song (the play button becomes a pause button).
* Denon is switching on (which takes approx. 10+ secs)
* Approx. 7 secs after I hit the playback button, the error/information box from JRiver comes up
* JRemote "stops" playback (the pause button changes back to a play button).
* Until now no playback has ever been initiated. To solve this problem the only thing I can do is to go the the PC with JRiver on it and click away that dialog box. Anything else will not help (e.g. hitting playback again on JRemote).
* As soon as I close the message box, JRemote continues playback with the next song, which actually starts to play.

By the way, the same happens if I don't use JRemote, but use JRiver itself for playback. The only difference is, that after the first messag box, a second one comes up, saying "Playback Problem: Something went wrong with playback. [OK] [Help]". After clicking OK, playback does not start with next song.

I hope this is what you wanted to know and helps to identify the problem.

To be honest, I am starting to feel silly... Does nobody have the same problem, as I am the only one in this thread? Does nobody use Denon devices with DLNA capability? Or does nobody care about it, except me nitpicker...

sskings · « **Reply #17 on:** February 26, 2013, 05:56:49 pm »

I also see that playback will not start when the Denon is in standby. (I have avr2112.) I do not have JRemote, but when working from computer the connection between MC and Denon freezes up if Denon is in standby. Only solution is to unplug Denon and close restart MC. I can give more details on this if interested. I've been just leaving the Denon on to avoid this.

bob · « **Reply #18 on:** February 26, 2013, 06:19:55 pm »

Quote from: Rubberduck0 on February 26, 2013, 04:50:47 pm

Interesting... However, it is definitely repeatable (100%). The exact circumstances are:

* JRiver Media Server is running (no matter if I just started it and this is first thing I do, or if it runs for a longer time already)
* Denon is in standby (network card is active, so JRiver will list it as zone)
* I use JRemote to start playback of any song (the play button becomes a pause button).
* Denon is switching on (which takes approx. 10+ secs)
* Approx. 7 secs after I hit the playback button, the error/information box from JRiver comes up
* JRemote "stops" playback (the pause button changes back to a play button).
* Until now no playback has ever been initiated. To solve this problem the only thing I can do is to go the the PC with JRiver on it and click away that dialog box. Anything else will not help (e.g. hitting playback again on JRemote).
* As soon as I close the message box, JRemote continues playback with the next song, which actually starts to play.

By the way, the same happens if I don't use JRemote, but use JRiver itself for playback. The only difference is, that after the first message box, a second one comes up, saying "Playback Problem: Something went wrong with playback. [OK] [Help]". After clicking OK, playback does not start with next song.

I hope this is what you wanted to know and helps to identify the problem.

Yup, this is good. The two message boxes when you are using MC are to be expected since it knows you are not remote.
It's possible JRemote is doing the playback differently, I've got it and will test it out. It's easy to duplicate given your instructions, I've simply got to pull the network cable out of a renderer and try to send it something with JRemote.

Quote

To be honest, I am starting to feel silly... Does nobody have the same problem, as I am the only one in this thread? Does nobody use Denon devices with DLNA capability? Or does nobody care about it, except me nitpicker...

I don't think there are many devices that go into a standby mode and can be woken up from that mode simply by sending it commands and waiting for it to respond so it would make sense that we've not seen this before.

Rubberduck0 · « **Reply #19 on:** February 27, 2013, 11:32:29 am »

Quote from: sskings on February 26, 2013, 05:56:49 pm

I also see that playback will not start when the Denon is in standby. (I have avr2112.) I do not have JRemote, but when working from computer the connection between MC and Denon freezes up if Denon is in standby. Only solution is to unplug Denon and close restart MC. I can give more details on this if interested. I've been just leaving the Denon on to avoid this.

According to the specs of the AVR2112 it seems to have the same always on network mode as the AVR4311. But according to your description it is not clear to me if it is the same problem as I encounter. Either the AVR2112 also needs about 10 secs to get ready and this is too long for our impatient

JRiver, then you should also get the message box, telling you that there is a problem with controlling the DLNA device.

If not, then this might be something different. Do you have the PlugPlayer (PP) app for iPhone/Android? Then please try it. This app works for me, i.e. if Denon is in standby and I start playback with PP, then Denon is going on, and after those ~10 secs playback starts. I think, that PP is just a little bit more patient then JRiver and retries to start playback for a longer time, if it does not get a reponse. Other apps (like 8player) work more or less: 8player, for example, will stop playback immediately if Denon is in standby. After the Denon is on and I press play again, then I get an error message (play command failed), but playback still starts to play.

However, I do not have to restart Denon and JRiver every time under these circumstances. Sometimes JRiver crashes and sometimes I also have to pull the power plug of the Denon, because it does not respond correctly (e.g. the same song is played over and over again). But this happens only occasionally. Usually all I have to do is to click away the JRiver message box and restart playback.

Quote from: bob on February 26, 2013, 06:19:55 pm

I don't think there are many devices that go into a standby mode and can be woken up from that mode simply by sending it commands and waiting for it to respond so it would make sense that we've not seen this before.

Very likely to be true. However, independent from this issue, IMHO a background/server application, which is very likely to run on a remote PC and/or is intended to be remotely controlled, should never throw up an interrupting message box, which requires interaction to continue. I understand that it is only a very minor group of people (anyone else?

) who bother, and that the effort to change this is not worth it. But maybe this could be considered for future development.

Rubberduck0 · « **Reply #20 on:** March 01, 2013, 04:27:13 pm »

Just in case anyone else is actually interested in this thread and having a similar problem:
The seek problem described at the beginning is fixed with build 18.0.135.
Many, many thanks again.

Rubberduck0 · « **Reply #21 on:** March 10, 2013, 07:36:56 pm »

Sorry, to warm this topic up, but I discovered a new issue with seek today:
It does not work with FLAC files.

Here is what I found out so far:
* As from release 133 on the high precision time is not used anymore. I use 144, so seek with MP3 works.
* Seek with FLAC does not (DLNA server settings are 'Never convert'). Moving the progress slider does not have any effect on playback (the slider returns to the old position after some seconds).
* I tried also an older release (128) with high precision time. Same result does not work.
* Then I tried the new conversion settings (DLNA server settings were 'Always convert') with 144 again:
** Uncompressed L16 - No header: there is some sort of seek behavior, although it is random... so whatever time index I want to set, the actual time index moves to a random position (back or forth), the progress bar gets out of sync and is also not synced after some time anymore
** Uncompressed 24 bit - LPCM - No header: does not play on the Denon ('File format error')
** Uncompressed: seek does not work at all (the song just continues to play) and the progress bar jumps back to the current position after some seconds
** Uncompressed - 24 bit: same as above 'Uncompressed'
* Then I tried to enable the advanced option 'Enable bitrate field' but the results were the same as above.
* Using a conversion option to MP3 works of course for all file types.

Is this the Denon again causing the problems or is there another reason?
Can this be fixed?

bob · « **Reply #22 on:** March 11, 2013, 11:27:50 am »

http://certification.dlna.org/certs/REG70183638.pdf

Doesn't specify any certified seek capability.

If you suspect MC might be doing it wrong, you could try manually sending a seek command with device spy from the developer tools for UPnP test quite.

I'm not surprised that headerless L24 isn't supported. It's actually kind of interesting FLAC is supported since that's not in the certification certificate.

Rubberduck0 · « **Reply #23 on:** March 11, 2013, 06:33:16 pm »

Maybe FLAC is not covered by the certification, as it is mentioned in the certificate, that the device's capability could exceed the certificate. However, I own the AVR-4311 not the 2112, but the certificate is practicallay the same.

I have the feeling that those certificates are not of great use. I looked for other Denon models, for Yamaha (Z7, Z11), Sony, and the certificates look more or less the same for all of these. They only certify 'Start' and 'Stop' capability (there was one model which only supports 'Start', so playback can never be stopped?!?!?!

). So according to this, Denon is as good or as bad as all the others. The more I get to know about DLNA, the more a certain picture forms in my head, and it's not a nice picture, not at all.

So, no, I am definitely not saying that MC does anything wrong. The only question is, if you want MC to do something right, what others did wrong, i.e. how compatible do you want MC to be? I assumed, that JRiver should become the quasi-standard in media center solutions for everyone, and should therefore provide a maximum of compatibility with many different devices. If you are telling me that the goal is to fulfill the official standards and if a device has a problem with that, then this is not your business, then I will accept this and stop reporting those issues.

Regarding the manual seek command thing: My knowledge is very limited on that subject, so I don't know, if I can be of much use here. I tried 'Device Spy' and confirmed the behavior, i.e. with MP3 the seek works, with FLAC it doesn't (the return value is 'Error Code 501: Action failed'). The full packet is:

Code: [Select]

POST /AVTransport/ctrl HTTP/1.1
SOAPACTION: "urn:schemas-upnp-org:service:AVTransport:1#Seek"
CONTENT-TYPE: text/xml ; charset="utf-8"
HOST: 192.168.4.30:8080
Content-Length: 393

<?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:Seek xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
         <InstanceID>0</InstanceID>
         <Unit>REL_TIME</Unit>
         <Target>1:30</Target>
      </u:Seek>
   </s:Body>
</s:Envelope>HTTP/1.1 500 Internal Server Error
CONTENT-LENGTH: 465
CONTENT-TYPE: text/xml; charset="utf-8"
EXT:
SERVER: KnOS/3.2 UPnP/1.0 DMP/3.5

<s:Envelope
		xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
		s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
	<s:Body>
		<s:Fault>
			<faultcode>s:Client</faultcode>
			<faultstring>UPnPError</faultstring>
			<detail>
				<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
					<errorCode>501</errorCode>
					<errorDescription>Action Failed</errorDescription>
				</UPnPError>
			</detail>
		</s:Fault>
	</s:Body>
</s:Envelope>

So, the question remains: Is this a Denon problem and there is nothing you can/want to do about this?

Rubberduck0 · « **Reply #24 on:** March 12, 2013, 02:35:35 am »

Ah, wait, I think I have the answer to my question right in my hands. MC only can use those DLNA commands, which I tried with Device Spy. And if it does not work with Device Spy, there is nothing you can do with MC to get it to work, right? Damned....

bubbleguuum · « **Reply #25 on:** March 12, 2013, 12:17:24 pm »

Quote from: Rubberduck0 on March 12, 2013, 02:35:35 am

Ah, wait, I think I have the answer to my question right in my hands. MC only can use those DLNA commands, which I tried with Device Spy. And if it does not work with Device Spy, there is nothing you can do with MC to get it to work, right? Damned....

Can you try 00:01:30 for Target ?

Rubberduck0 · « **Reply #26 on:** March 14, 2013, 04:39:46 pm »

Sending the seek time as 00:01:30 (or 0:01:30, or 01:30) did not work as well.

I will contact Denon support, although I doubt there will be any response. My experience so far with Denon support is not promising.

MartinBar · « **Reply #27 on:** March 21, 2013, 11:44:06 am »

Hello

I am seeing the same seek problems with Marantz (the MCR603) (same manufacturer as Denon - I have not done any testing yet as to exactly when/where yet

Rubberduck0 · « **Reply #28 on:** March 21, 2013, 07:31:39 pm »

Well I got a reply from Denon support just now. The answer is as expected and still strange:

"Seek can only be used with MP3 files. It is not possible to use seek with FLAC files. This cannot be fixed with a firmware update."

Does this mean, that there is a technical reason why seek does not work with FLAC files? Sounds strange to me... ?

Rubberduck0 · « **Reply #29 on:** March 22, 2013, 04:42:10 am »

Update from Denon support:
The reason why this does not work is because the hardware (chipset) used in the Denon products (even the newest ones) is not capable of doing a seek with FLAC files.

Does anyone own a renderer which is not associated with Denon (e.g. Sony, Yamaha), which is capable of doing seek with FLAC files?

I would be very grateful, if someone could confirm or correct the summary below:
As I understand it, you have two options to choose from:
A) 'Always convert' to MP3 and having seek, but this means also:
A1) lossy audio format (although is this really noticeable if you use 'high', i.e. 320 kbps?)
A2) only stereo, as MP3 does not support multi-channel
A3) are there any other disadvantages compared to FLAC/uncompressed?
B) 'Never convert' (or convert always to uncompressed) and forego seek functionality (for non-MP3)

By the way, I found this thread here 'Playing FLACs over DLNA'. However, I do not understand a word. Does this provide any hint to solve the problem (there is some talking that seek worked somehow, but how)?

JimH · « **Reply #30 on:** March 22, 2013, 07:05:47 am »

You could try using MC to convert to WAV when it plays. It's in the Media Network options.

Rubberduck0 · « **Reply #31 on:** March 22, 2013, 05:11:12 pm »

With WAV you mean the four uncompressed conversion options? If yes, then this does not work, as reported in more detail in an earlier post. The only option with some sort of seek is L16 but the seek position is random, it's really strange. With the other options seek is ignored.

Or is there another option for WAV?

bob · « **Reply #32 on:** March 25, 2013, 11:43:53 am »

Quote from: Rubberduck0 on March 22, 2013, 05:11:12 pm

With WAV you mean the four uncompressed conversion options? If yes, then this does not work, as reported in more detail in an earlier post. The only option with some sort of seek is L16 but the seek position is random, it's really strange. With the other options seek is ignored.

Or is there another option for WAV?

Try turning on "enable bitrate field" under the advanced options for your MC DLNA server. It helps seeking with some devices that read it properly (and messes up others like the WDTV which implement it improperly).

Rubberduck0 · « **Reply #33 on:** April 03, 2013, 02:06:38 am »

Didn't help. With all 4 uncompressed options only the L16 gave me at least any reaction. The other options just ignore a seek command. With L16 the Denon does jump to a position, probably the right one. But I cannot tell as the Denon then stops to communicate or something. So on the Denon display and on JRiver the progress bar is not updated anymore and constantly shows the time before the seek. Further seek commands are also performed but my impression is that these jump to a more or less random position. In the end this is not usable.

So I have to stick to MP3 conversion. However, many thanks for the advices.

INTERACT FORUM

Author Topic: DLNA with Denon (Read 24874 times)

sskings