qwksilver
commented
3 years ago I see a potential hard loop forming in step 3, it may be relevant to actually do the size compare (if called for) just after each file is vetted, so if step 3 generates 5 matches to say mary.jpg it would pick one random hit, check the filesize and if not identical use it and move on. if identical use then rng on the remaining 4 matches and so on until none remain or a file is selected.
I'm hoping that all this can be done with basic sql queries and no need to load the whole db into memory.
I'm also hoping for a set of switches that will allow the complete skipping of anyone of the compares, especially 3 on a large db. but not sure of the need.
the reason of the match/no match is I personally don't want the same file to show up on multiscreens if i happen to point them both at the same collection. but i can also see that others might want to point all the frames at 1 filebase, and have all the screens show the same photo, reasons here might be a doctors office that wants the all the infocards to show up in the same order together no matter where in the building you are. or a family with desktop frames that will show the same photo in both mom & dad's office + the fireplace mantle. there are plenty of use cases that show a need for both excluding and allowing same photo display.
Geektoolkit
Sync has been broken by Database implementation in 2.24
Basic Idea of a file sync revamp, phase 1:
Step 1: from Main Frame send ?SETFILE=/home/pi/Pictures/Portrait//Web/IMG_20190125_110611.jpg The receiving frame will break that down to: basepath="/home/pi/Pictures/Portrait" and filepath="/Web/IMG_20190125_110611.jpg" by looking for the double //
Step 2: the receiver frames begin a set of compares, level 5 to 1, to determine next file, exiting to step 3 when a number or numbers are matched.
Sidebar: a new setting for allow exact file match to add to sync screen on receiver screens, if no and 5 above matches, then a file size compare will need to be checked, this also means filesize needs sent with SETFILE or maybe and &FILESIZE=
Step 3: check to see if allow exact is false, if so compare the filesizes and if they match, return up to step 2, but the level below where the match was found (ie match 5 would return to 4 and so on)** extra discussion for this below
Step 4: the highest ranking file is sent to be displayed with a normal fade in, and a duration of x+4000ms. the purpose here is to both reset and lengthen the wait on the next photo. if another SETFILE doesn't come in the frame itself will resume normal rotation and timing. but if a new file comes through the frame has more than enough time for the compares.
Basic Idea of a file sync revamp, phase 2:
Make use of a "network time protocol" which can bring machine clocks in line to the ns, to send the setfile command with a new &setnext= portion. each pi would be linked to the same time server, like time.nist.gov or time.windows.com.
setfile=unchanged, setfilesize=see sidebar above.
setnext= so something like 07022021-150114.000 would tell the receiver that the next photo change is today, at 3:01 and 14.000 seconds. this would come a few second before the change, then the main and subframes would do the compares, pick the file, then schedule the files to all appear simultaneously. this stage will greatly increase the viability of syncronized mp4 cinegraph.
none of the other logic from phase 1 Changes except adding times alignment to Step 4.