Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dr_Hoon]

I'm rendering audio from MC27 to a DLNA receiver and the playhead won't change the track position with untranscoded FLAC files. It works fine if transcoding to MP3 but when I interact with it for untranscoded FLAC, the playhead just reverts back to its original position after a few seconds while the audio track continues playing unaffected. This is the case when interacting with it via JRemote2 or MC directly. Any ideas? Thanks.

[JimH]

Maybe you mean DLNA Renderer,  but what is a playhead?

There are a lot of different FLAC files.  44.1, 24 bit, 96 kHz, multichannel?

[Dr_Hoon]

Yes, my receiver is a DLNA renderer.

The GUI element in question is called a playhead in video editing software, I don't know what it's officially called in MC - it's the graphic element used to to change the playing (time) position by clicking/touching and dragging along the timeline.

The following stereo FLAC files all exhibit the same behaviour: 44.1KHz 16-bit, 44.1KHz 24-bit, 48KHz 24-bit, 96KHz 24-bit.

[JimH]

OK.  I understand now.  Thanks.

What is the DLNA Renderer?

[Dr_Hoon]

Yamaha receiver (RX-A3080).

[bob]

It's possible it doesn't suppose the GetPosition call properly on flac files.
Try right-clicking on the zone and look at DLNA controller options->Ignore GetPosition failure.
MC will just keep time on the track then ignoring the error.

If you know another format, say wav works you can so the "Specified output format when necessary" option for the MC DLNA server and choose to decode the flacs to wav (PCM 16 or PCM 24) under audio->advanced in that section.

[Dr_Hoon]

Thanks Bob. I've tried the DLNA Controller Options and nothing seems to make any difference. I ran a DMR report with Whitebear and my receiver supports everything except SyncPlay. I also get the same issue when playing to a different renderer, a streaming box (admittedly also by Yamaha). Do you know if there's any way of knowing whether the fault lies with MC or Yamaha?

[bob]

Thanks Bob. I've tried the DLNA Controller Options and nothing seems to make any difference. I ran a DMR report with Whitebear and my receiver supports everything except SyncPlay. I also get the same issue when playing to a different renderer, a streaming box (admittedly also by Yamaha). Do you know if there's any way of knowing whether the fault lies with MC or Yamaha?

MC does some pretty extensive logging in that area.
Can you turn logging on (help->Logging), start playing a track, then when it fails stop logging and either post the log here or email it to me?
bob (at) jriver (dot) com.
Thanks.

[Dr_Hoon]

Thanks Bob. I've emailed you some log files. Please let me know if they didn't come through.

[bob]

It looks like the issue is with the Yamaha. These are the relevant lines from the log:

Code: [Select]

0012133: 4085498896: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {Lounge} Playback state is PLAYING but GetPosition is returning 0. Estimated = 1121, Returned = 0

0017412: 4085498896: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {Lounge} Playback state is PLAYING, ignoring GetPosition failure, Position 4000 Duration 1356000
So the playback position isn't being reported correctly by the Yamaha. MC sees that and reports position (in MC) based on it's calculated position (the second line).

You should be seeing the position  (in MC) update based on the estimate.

If you are viewing the track using a remote option, JRemote, MC media client, Gizmo, Panel, etc you probably aren't seeing that since they report only accurate position.

In MC28 we added a fallback to the calculated position when the "Ignore GetPosition Failure" controller option is set.

I don't think it will make a difference in this case but you might try turning on the DLNA SERVER ADVANCED option "Enable bitrate field" to see if that extra information will help the renderer figure things out.

[Dr_Hoon]

Thanks for taking the time to look into this.

I don't think it will make a difference in this case but you might try turning on the DLNA SERVER ADVANCED option "Enable bitrate field" to see if that extra information will help the renderer figure things out.

Unfortunately, it didn't help.

In MC28 we added a fallback to the calculated position when the "Ignore GetPosition Failure" controller option is set.

I'm unsure what the implications are - are you saying MC28 will resolve my issue? I actually have an MC28 license, I'll just need to hassle another user to create an ARM docker image.

[AndrewFG]

It looks like the issue is with the Yamaha.

.. the playback position isn't being reported correctly by the Yamaha. MC sees that and reports position (in MC) based on it's calculated position (the second line).

I just ran a trace on my own Yamaha RX-A820 Receiver, and I can confirm that this device always (wrongly) returns zero values in its response to GetPositionInfo(). So bob is correct in saying that the bug is with Yamaha (at least for my unit) and not with JRiver.

Note: I never noticed this bug myself before, since I never push to the Yamaha via DLNA, but instead have my HTPC outputting directly to the Yamaha via HDMI.

Anyway, bob's suggestion to take advantage of the new MC v28 Ignore PositionInfo setting, makes sense to me. I will check this also later, and get back to you..

[AndrewFG]

^
Hmm. It seems to be weirder than I thought..

When I push to my Yamaha from MC v28 I can see that it does actually report position values in response to GetPositionInfo(). But the oddity is that it reports DIFFERENT values in RelTime than in AbsTime. The following is an example from 1 minute into the playing of a 6 minute MP3 track. The RelTime value is apparently correct; and from the trace I can see that it increments in an orderly manner throughout the playing process. On the other hand, I cannot see any logic to its AbsTime value (?)

Code: [Select]


<TrackURI>http://192.168.1.38:52100/Music/F1994.mp3?Reader=7</TrackURI>
<RelTime>0:01:00</RelTime>
<AbsTime>0:33:09</AbsTime>


I guess MC uses the (seemingly wrong) AbsTime value rather than the (seemingly correct) RelTime value. => Bob, is that so?
Also I am pretty sure that other Control Points would generally tend to use RelTime too. (??)

EDIT: I also get the same odd behaviour playing a FLAC version of the same track; so it is not a media dependent problem.

[AndrewFG]

^
See quote below from the AVTransport specification. i.e. RelTime is the position within a given track and AbsTime is the position within the whole album or play-list. And Control Points would normally display RelTime. But since MC pushes single tracks and not whole albums/playlists, I would expect AbsTime to be identical to RelTime.

2.2.22.RelativeTimePosition
This state variable contains the current position, in terms of time, from the beginning of the current track.

2.2.23.AbsoluteTimePosition
This state variable contains the current position, in terms of a time, from the beginning of the media.

[JimH]

Thanks, Andrew.

[bob]

Did a quick check, MC's control point is using RelTime:

Code: [Select]

mapArguments.SetPropertyInt(_T("InstanceID"), 0);
bResult = Control(DLNA_SERVICE_AVTRANSPORT, AVTRANSPORT_FUNCTION_GET_POSITION_INFO, strStatus, &mapArguments, 6000, true);
if (!bResult || (mapArguments.GetProperty(_T("RelTime")).IsEqual(_T("NOT_IMPLEMENTED"))))
{
CLogHelper::Log(LOG_TYPE_PLAYBACK, _T("CDLNADeviceControl::GetPosition"), _T("GetPosition returned NOT_IMPLEMENTED for RelTime"));
bResult = false; // still need to set false if the call succeeded but returned NOT_IMPLEMENTED
}
}

// parse
if (bResult)
{
nPositionMS = JRMath::DTOI(JRDateTime::UnformatDurationHoursColonSecondsHighPrecision(mapArguments.GetProperty(_T("RelTime"))) * MILLISECONDS_IN_SECOND);
nDurationMS = JRMath::DTOI(JRDateTime::UnformatDurationHoursColonSecondsHighPrecision(mapArguments.GetProperty(_T("TrackDuration"))) * MILLISECONDS_IN_SECOND);
strTrackURI = mapArguments.GetProperty(_T("TrackURI"));
strTrackMetaData = mapArguments.GetProperty(_T("TrackMetaData"));
}

[AndrewFG]

^
Ok, so MC is behaving correctly according to the specs.

So the mystery is why the OP’s Yamaha sometimes returns RelTime = 0?

On retrospect, I think my DMRA can’t help here, because the only time that it calls GetPositionInfo is before it calls Play() where a 0 value is actually quite correct.

[AndrewFG]

PS Bob, I guess there could be two reasons why the MC “playhead” could not update itself: 1) missing RelTime, or 2) missing Duration (which presumably you get first hand from the MC library tags, rather than second hand reflected back from the renderer). Perhaps you should ask OP to send you his file and see if there would be some reason why MC can’t extract a Duration tag from it?

[bob]

PS Bob, I guess there could be two reasons why the MC “playhead” could not update itself: 1) missing RelTime, or 2) missing Duration (which presumably you get first hand from the MC library tags, rather than second hand reflected back from the renderer). Perhaps you should ask OP to send you his file and see if there would be some reason why MC can’t extract a Duration tag from it?

Actually it does use the duration from the renderer.
That's because as a controller we could just be looking at a track someone else pushed to the renderer.
If I remember correctly though when the duration is available locally we do retrieve it there.

[AndrewFG]

^
In either case, it might be interesting to see the file. Or?

[bob]

^
In either case, it might be interesting to see the file. Or?

Yes, I agree.
Dr_Hoon could you send a sample flac file that doesn't advance the seek bar to
bob (at) jriver (dot) com
Thanks.

[Dr_Hoon]

File sent. Thanks everyone, for the time and effort spent investigating this issue.

[AndrewFG]

I just tested Dr_Hoon's file by pushing it from MC 28 to my Yamaha RX-A820 while monitoring the traffic with WireShark...

... and it played just fine! To be specific the renderer did the following:

• changed its TransportState as it should
• reported TrackDuration of 00:00:27 as it should
• responded to GetPositionInfo requests as it should

Notes:

• MC called GetPositionInfo at 1 second, 7 seconds, 13 seconds, 18 seconds, and then 24 thru 27 seconds
• Unlike my previous test, the renderer reported both AbsPos and RelPos as the actual play position

So in other words, we are none the wiser; it works perfectly on my Yamaha but not on Dr_Hoon's (different) Yamaha(s).

[Dr_Hoon]

Unlike my previous test

What did you do differently this time? If possible, I'd like to replicate your success

[AndrewFG]

^
Sorry, I can’t remember..

[Dr_Hoon]

Did you push the FLAC file to your receiver untranscoded via DLNA over wifi? I don't experience issues when MC transcodes to mp3.

[AndrewFG]

^
All pushed via hard wired Ethernet..

- I pushed an original MP3 about 6 minutes long
- I pre- converted that MP3 to a Flac and pushed it
- I pushed your Flac about 27 seconds long

All of the above worked fine with my Yamaha (the only anomaly being the AbsTime in the first two cases).

[AndrewFG]

Did you push the FLAC file to your receiver untranscoded via DLNA over wifi? I don't experience issues when MC transcodes to mp3.

I wonder if this might indicate a potential WiFi or Router bandwidth problem? Did you try it over hardwired Ethernet?

[bob]

It's a docker installation which throws another wrinkle into the equation.

IF GetPosition isn't working, MC27 won't update the position in JRemote2 but it will update position on the slider in it's own UI.
I've just verified this with my non-position updating Raumfeld speaker.

MC28 will update the position on the remotes based on the estimated position.

This is assuming of course that MC is the controller AND the server. There are more variables if the server is somewhere else (like a DLNA server).