Weird repeat loop

[pukster]

I am still debugging this, so I don't know if this is the exception or the rule, but after a while the slave player loops back, generally to the beginning of the film and starts twitching while trying to synchronize. I am going to get a pizza and sit down and debug this over the next few hours =) but in the mean time, has anyone encountered this problem? Is it as a result of overly sensitive settings?

[turingmachine]

Did the players synchronize beforehand? What is output of both the master and the slave output log when this happens? What did you expect to happen? Are you running in loop mode? How many movies are you playing? Was the master in the middle of a file or at the end?

[pukster]

Here is the Video information (in case that's relevant)

Video codec omx-h264 width 1920 height 800 profile 100 fps 23.976025 Audio codec dca channels 6 samplerate 48000 bitspersample 16 Subtitle count: 0, state: off, index: 1, delay: 0 A:PortSettingsChanged: bits:32 mode:0 channels:6 srate:48000 nopassthrough V:PortSettingsChanged: 1920x800@23.98 interlace:0 deinterlace:0

I issue the following command on the master computer first omxplayer-sync -v -m -x <ipaddress> <full-video-path>. Next I issue this command on the slave computer omxplayer-sync -v -l <ipaddress> <full-video-path>. Upon entering, the slave seeks forward, pauses and eventually synchronizes itself. A few minutes in, the slave computer rewinds to the beginning (menu reads 00:00:01/01:35:51 or something like that), then it starts seeking to 00:00:11 then to other values like 00:00:21 or 00:00:30 or 00:00:40 or 00:00:59 but never exceeding 00:00:59, then it goes back to 00:00:01. During all of this, sometimes the master computer displays some performance issues, but nothing this severe.

In the terminal, the master displays just the usual local: xxx.xx yy timing information, while the slave displays its usual local:...master:...deviation:...wait: False but every time these 'jumps' happen it writes seeking forward...

[pukster]

I isolated the output for the slave computer and about 7740 lines in, the seek starts, and that's when the problems also start. The deviation jumps from 0.52 s to 107 s. I uploaded the logs to the link below

http://www.filehosting.org/file/details/439784/output.slave.txt

[pukster]

Being a genius I figured out the problem. If you launch your version of omxplayer and frantically hit the right arrow button like a lunatic, it will for some reason keep going back to the beginning of the movie. I suspect this is what is happening in the script. Note that this does NOT happen with the regular version of omxplayer

[pukster]

I discovered some other interesting things after much debugging. Look at the following log

  10859 local: 150.40 master: 150.63 deviation: 0.23 wait: False
  10860 local: 150.40 master: 150.72 deviation: 0.32 wait: False
  10861 seek forward...
  10862 local: 150.45 master: 151.26 deviation: 0.80 wait: False
  10863 seek forward...
  10864 local: 152.44 master: 151.86 deviation: -0.58 wait: False
  10865 pause...
  10866 local: 0.00 master: 152.33 deviation: 152.33 wait: True

What's happening is that between lines 10859 and 10860 the video drifts out of the tolerance range, so in 10861 we seek forward, this should move the time from 150.40 to something like 160.40 but if you look at line 10864 it stays 150.45 (technically moved up 50 ms). The code, not aware of what's just happened, attempts to run the same code again. Once again the time is not moved 10s ahead, and instead we are at 152.44. At this point, however, we are ahead of the main video so we pause.

Unfortunately, and here is where I am just guessing, the damage has already been done as we submitted two right arrow signals and the player went nuts and went back to position 00:00:00. There are two problems here:

1) The fast forward signal was sent twice 2) The initial fast forward signal did not fast forward the video (at least it did not fast forward for the full 10s we expected it to)

My guess is that the reason this is happening has to do with the fact that you are reading the logs (omxplayer -s...) and the logs are not being updated fast enough so even though you issued the fast forward request, omxplayer sh!ts a brick and returns the current time position before the fast forward request is processed.

Right now I'll try including a conditional to space out fast forward requests by at least 1s, and post the results.

[turingmachine]

please use the most recent version, the syncing meachnism now use a different approach to control the player.