More > JRiver Media Center 24 for Windows

NEW: Zone Sync 2 [Old instructions]

<< < (4/9) > >>

AndrewFG:

--- Quote from: jmone on March 15, 2018, 03:16:37 am ---Andrew, your DMRA reports SyncPlay as "NOT Supported"

--- End quote ---

Yes. Obviously. Because MC does not yet support it. But it could easily do so now. This is a new feature added in DMRA specification V2..

jmone:
Sorry - I thought you were asking if this new feature was reported as SyncPlay.  FWIW I too agree that it would be best as advertised as DLNA-SyncPlay

AndrewFG:
Below is an extract from UPNP:AVTransport v3..

http://upnp.org/specs/av/UPnP-av-AVTransport-v3-Service.pdf

+++++++

5.4.26 SyncPlay()

..

This action behaves the same as the Play() action except that the playback of the current content binary shall be synchronized with the device’s internal time-of-day clock as specified by the ReferencePosition and ReferencePresentationTime input arguments.
..

The renderer shall start rendering the content at the ReferencePresentationTime argument at an offset inside the content specified by ReferencePosition argument.

The ReferencePositionUnits argument identifies the format of the ReferencePosition argument, for example, time vs. frame count, etc.

The ReferencePosition argument identifies a specific location within the content binary, for example, 1 hour, 10 minutes, and 34 seconds from the beginning.

The ReferencePresentationTime argument identifies a precise time of day at which the ReferencePosition is to be played for example, June 6, 2009 at 21 hours, 14 minutes, and 36.152 seconds (past midnight).

++++++++++

JohnT:

--- Quote from: AndrewFG on March 15, 2018, 02:04:18 am ---If you have created a new UPNP soap command that gives the renderers a time to start, then you have reinvented the wheel. The DMR V2 UPNP DLNA standard specification defines a UPNP soap command called PlaySync (or SynPlay) that is exactly the same as the regular Play() command except that it adds an extra argument providing the time to start.

Before you release your home made version, I seriously and strongly advise you to look at the existing UPNP DLNA V2 standard, and if possible simply rename your custom special command as PlaySync (or SyncPlay).

If you go your own way you will have a proprietary solution. Which being a copy of an already existing standard, will not be attractive for other vendors to adopt. So you will be on your own.

Whereas if you adopt the already existing standard as a first mover, you will be onto a runner.

--- End quote ---
Thanks Andrew.  Do you have or know of a device that supports that PlaySync command?  I'd like to get hold of one and test it out.  It would be trivial to modify the DLNA commands we're using if we decide to support that standard, the hard part for now is getting the system working well in a variety of environments and playback scenarios.

JohnT:

--- Quote from: jmone on March 15, 2018, 04:02:26 am ---Did a quick test between two MC instances.  Works as advertised and the Sync is perfect.  :)  I did not even have to "Adjust link timing".... though, you really do need to make sure the settings are the same on both PC's as JohnT outlines or the sync falls apart on a track change. 

Couple of things I noticed:
1) If you do a Sync right at the end of a track (say the last 10 sec) then sync falls apart (the remote machine started playing the next track quicker the the local).  A seek fixes it
2) Oddly, I'm hearing a "click" on track starts with these settings for some reason (even when not linked)
3) The Delay in Seeks is (as reported) slooooowwww

I'll get a bunch of PC's, DLNA Speakers etc all linked up on the weekend and see how it goes!

--- End quote ---
Thanks for testing!  I've noticed the occasional "click" on a pause or seek, but not starting a new track.  Do you hear it on starting a new track?  I've got the seek problem (#1 on your list) on my list to look into.  The delay is hard coded right now, but we'll add some code to gather latency information from remote zones and use that info to shorten the delay as much as possible.

Navigation

[0] Message Index

[#] Next page

[*] Previous page