it seems to me there’s something wrong with the sync node.
the clients wont reset the position, but they seem to know that they’re off-sync.
i tried the sync node help patch with vvvv_45beta29.2_x86 and vvvv_45beta29.2_x64.
and the attached patch with vvvv_45beta29.2_x86, vvvv_45beta29.2_x64 and vvvv_45alpha29.3_x64.
i tried changing to several diffrent ports.
(picture of the attached patch)
it works the first time i start the patch but “reset the video” only resets the server.
test patch (6.9 kB)
the funny thing is that the old tonfilm video sync patch works perfectly in vvvv_45beta29.2_x86!
with the same port as above !
this works ! (17.2 kB)
interesting, does this also happen with the FileStream (not 2) boygroup node?
yes in vvvv_45beta29.2_x64 exactly the same… :(
i only tested it in vvvv_45beta29.2_x64.
just out of interest, does it change if you remove the IOBox between the TogEdge and the FileStream2? or try if it behaves different if you open the FileStream2 module patch. or try to add a counter in the module and connect it to the DoSeek pin to check whether the bangs are really arriving…
Came to the forums to report the same thing.
I got this boygrouped setup with Filestream2 (boygroup) node.
So I can report that I got 2 machines which fail as clients and severs. If I make them a boygroup server no clients work. If I connect them as clients they don’t sync video. In fact if you zoom into Filestream2 node you’ll see that the offset is constantly going to -infinity.
Latest vvvv version, win7 64 bit everywhere.
Just tested with 29.2, 29, 28.1 — the same result.
looks like blocked ports or so, check the firewall and network connections of the sync port. i don’t think that it is the same problem as soundreactors… especially if it only happens on certain machines, it indicates a problem of the computer and/or its settings.
We can’t find out what’s going on with that pc. Turned off everything.
Looks pretty similar to what the topic starter is saying — Sync nodes don’t sync o.O Maybe it’s some kind of firewall issue but I don’t know where else to look for )8
It looks like they are talking. 192.168.1.11 is the server, 192.168.1.10 is the out of sync client. I use port 4445 to sync and port 4444 for the boygroup.
please also check if something is going on on port 3334, which syncs the time base of client and server.
I changed default 3333 port of boygroup to 4444 because we got a multitouch device broadcasting TUIO to this port over network. So time base sync is still over 3334? Or it will be 4445 which I set up as sync pin in Filestream node o.O
Is there a place where all ports used are listed?
And how I can debug this behavior?
there are two independent systems, one which synchronizes the time of the Clock (Network Boygroup) node and one which syncs the video time. the former always uses 3334 and 3335 and the latter the port you set on the sync node and one above, so 4445 and 4446 in your case.
the reason of using two ports is that it can also work on the same machine where two applications cannot open the same port.
you can debug it if you create the Clock node and check whether the output time is the same on client and server.
what comes out of my client sided sync node looks pretty much the same as VVVValentins screenshot.
to answer the older question:
no the bangs are arriving. i saw them on the clients, inside of the filestream2(boygrouped) node. and just to be sure i banged the “do seek” on the clients by hand.
but it wouldn’t help anyways, because the sync node is constantly banging the “do seek”, trying to seek a enless position.
i don’t think its a firewall problem since the rest of the boygroup communication runns perfectly fine.
thanks, thats valuable information. can you upload the video which fails somewhere?
I am getting such behavior with this video: https://dl.dropbox.com/u/3601116/mjpegtest.avi
But for some other ones encoded with mp4v position gets to total length stops there but the video keeps playing. And I don’t see the sync this way. They just keep playing together because they were started like this.
hello, please test again with the latest alpha and report. it could be related to localization settings…