Closed shrikumarh closed 7 years ago
Could you send the logcat for two android syncplayers crashing while seeking? I'll look into that first.
It might also help me if you can share the tcpflow dumps where you saw linux and android seeking issues.
Thanks!
Sure thing.
Just realized that I uninstalled SyncPlayer on my 2nd android device (so that I could try linux syncplay under GNUroot Debian). I will be able to send you android logcats only later on.
But, meantime here are tcpflow from the android-syncplayer and linux-syncplay experiments.
The sequence was: I cued up the movie on both devices, let it play for a bit. Then I did a seek on the the android-syncplayer to roughly the middle of the movie, and the linux syncplay nicely caught up to it. Then I did a little seek with the keyboard on the linux mplayer/syncplay. Immediately syncplay linux told android/syncplayer to seek, and a moment later, android/syncplayer told linux/syncplay to jump back to 0:01, ie almost very start the video. Everything continues from then one, except now both are again at the start of the video.
The android/syncplayer has the nickname "zte". The linux/syncplay has no nickname. ' This tcpflow was captured on the linux device (obviously), whose IP addess is 172.20.2.122. The sever is syncplay.pl:8996.
Hope this is useful.
If you wish a logcat from the android side, please let me know and I can repro. Or, even better, if we can co-ordinate a time, you run an android/syncplayer on your device and sync with my linux/syncplay, you can grab as many logcats as you like.
syncplayer-syncplay-jumps-back-to-0.zip
-- //Shrikumar
I was starting to hack together a syncplay client myself and then I stumbled upon this. Seems to work, thats great! But came upon a debilitating bug. I suspect it might be a simple thing in the interaction with the media player. based on some experiments I did. Before I dive into the code myself, thought I'd ask. (More than happy to help debug if you like.)
(I ran tcpflow to see the traffic and I can see the sequence of linux announcing the seek, and immediately the android version responds with a seek 0, so both are now back to the start of the video).
Without looking at the code, just based on the bhaviour, I am guessing that when the linux client announces a seek, the android syncplayer does the seek to the announced offset, this maybe fails for some reason, and maybe causes a jump back to 0sec. This is then announced to the server from the android syncplayer. Just a guess.
Please let me know how I can help. tcpflow dumps. logcat, test runs of modified code, run connected to you when you are watching ... anything you like, just let me know.
-- //Shrikumar