Closed 5shekel closed 5 years ago
Thank you for this. I've used it but I ran into a (simple) issue so I figured I'd share my experience in case someone else tries this. So it works fine but whenever you run the script, the list.txt lines will be APPENDED meaning that after running the script 3 times you end up with a list that will concat the video 72 times. You will eventually run out of space and will have trouble booting your pi. The solution is to connect via ssh and delete the file to free up space.. Or just start over with another .IMG. The SD card isn't damaged, it's just full.
So basically, you want to delete "list.txt" before running this script.
added delete command to the script
TLDR: i think its worth mentioning in the readme that seamless looping on slaves is not reliable.
i am working on a 7 pi installation that requires a seamless loop of a single video. as mentioned in issue #32 and #23 , omxplayer-sync will introduce a small pause on the slaves as they sync to master every loop point. on my system its ~8 second into video the slaves playing. screenshot with -v. note, the master plays seamless.
@DSPeelJ suggested starting a video with a few seconds of blank frame helps mitigate. but again, this is not seamless.
SYNC_GRACE_TIME
tweaking (#79) didn't solve the issue for me, sometimes it did, but not consistently.i used both my own video and the test video supplied. raspi3b+ running stretch
my hack for this is to concat the single video im running using ffmpeg to fill most of the space left in the SDcard, allowing for ~3-6 hours of "seamlessness" , based on compression ratio and size of card (~22G is what i'm left with on a 32GB card). this is not a solution, but tolerable in my situation.
here is my ffmpeg concat script. i upload to each pi the (9 minute) source as tmp.mp4, then concat it 24 times using following script.
other then that, omxplayer-sync works great, its been running for a few days now without losing sync, just this small issue needs mentioning me think.