FunSync Player [1000+ Users] - All-in-one video player with built-in editor, EroScripts search, multi language, and multi-device sync

Software
, , , , , , , , , ,
329

you did not miss a setting, that is how it works at the moment, but it is a fair ask so it is going in as one. next build there will be a toggle in settings, playback, called start playing on open. turn it on and opening a video from the library plays it straight away instead of loading it paused.

it will be off by default, only because a single click can set a device moving and i would rather that never happen to someone who did not ask for it. once you switch it on it just works the way you described.

1 Like
330

Great app! Possibly silly feature suggestion but, duplicate file checker/finder, some collections are quite big, and i sometimes forget what i’ve downloaded and end up with duplicates.

1 Like
331

not a silly suggestion at all, and there is already a bit of it in there, so let me check which thing you actually want before i build the wrong one.

what exists today is settings->appearance-> hide duplicate names. it is off by default. it shows one entry when several videos share an identical filename, the classic case being the same file sitting in two source folders, and it keeps the copy that has a script attached so you never lose the scripted one.

but that is display only, and it only matches on the filename being exactly the same. it hides them from the grid rather than showing you what you have got, and it will not spot the same video saved twice under different names, which i suspect is closer to what actually happens when you forget what you downloaded.

so, two different features. is the existing toggle what you were after, or do you want something that finds likely duplicates and shows them to you in a list so you can look through them and delete the ones you do not want, including ones whose names do not match. the second one is a proper feature rather than a setting, and matching on things like file size and duration rather than the name, but it is doable and it is a reasonable ask for a big collection.

let me know which you were asking for or whether it was something else.

1 Like
332

It’s the latter, because anyone who has a big collection also knows we are always out of space, so finding duplicates helps get some space back, but this might not be worth it for this app depending on how difficult the implementation is. Not sure how many people would want it, and there might already be dedicated software that does this, but just thought i’d throw it out there :)

1 Like
333

Hey there o/

I’m having a bug that goes back a few versions now, and scrolling through the thread might be some problem on my end to be honest.

First off, thank you Dave! I got the Handy 2 Pro back through the crowdfunding campaign and everything was just a little much of a muchness to get it going and have things working smoothly.
What you’ve made here has made it infinitely more accessible for my little brain. You’re a godsend, thank you for your hard work :folded_hands:

The only way I can get my Handy to work with the program is by the first connection it establishes when you open the program, if the stroker is already on.
If I pair it manually after the app is already launched, or god-forbid I Re-Sync after they connect to each other (ie. any connection style where it is now able to display my firmware version under the connection key) the Handy can start a script, I can even jump around within the same playback and script, but if I pause or try to exit that video it just keeps playing the script.
After that point I can then also short-press the start/stop button on the stroker and it will pause/resume the script. So it’s probably disconnected or the like at that point.

I have had this issue since I first found the community here and installed 0.9.0, I believe.

I can DM a fresh log after replicating the issue, but I first want to ask:

The bulk of my log files looks like this:

[2026-08-22 13:58:44.633] [info] [Backend] INFO: 127.0.0.1:54012 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:46.637] [info] [Backend] INFO: 127.0.0.1:54012 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:46.638] [info] [Backend] INFO: 127.0.0.1:56699 - “GET /api/media/rescan-request HTTP/1.1” 200 OK

[2026-08-22 13:58:48.625] [info] [Backend] INFO: 127.0.0.1:56699 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:49.616] [info] [Backend] INFO: 127.0.0.1:54019 - “GET /health HTTP/1.1” 200 OK

[2026-08-22 13:58:49.632] [info] [Backend] INFO: 127.0.0.1:56699 - “GET /api/media/rescan-request HTTP/1.1” 200 OK

[2026-08-22 13:58:50.628] [info] [Backend] INFO: 127.0.0.1:56699 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:52.633] [info] [Backend] INFO: 127.0.0.1:56699 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:52.634] [info] [Backend] INFO: 127.0.0.1:63526 - “GET /api/media/rescan-request HTTP/1.1” 200 OK

[2026-08-22 13:58:54.621] [info] [Backend] INFO: 127.0.0.1:54019 - “GET /health HTTP/1.1” 200 OK

[2026-08-22 13:58:54.638] [info] [Backend] INFO: 127.0.0.1:63526 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:55.630] [info] [Backend] INFO: 127.0.0.1:63526 - “GET /api/media/rescan-request HTTP/1.1” 200 OK

[2026-08-22 13:58:56.625] [info] [Backend] INFO: 127.0.0.1:63526 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:58.628] [info] [Backend] INFO: 127.0.0.1:63526 - “GET /api/media/vr-activity HTTP/1.1” 200 OK

[2026-08-22 13:58:58.629] [info] [Backend] INFO: 127.0.0.1:65453 - “GET /api/media/rescan-request HTTP/1.1” 200 OK

[2026-08-22 13:58:59.634] [info] [Backend] INFO: 127.0.0.1:54019 - “GET /health HTTP/1.1” 200 OK

Over and over and over again. Is that normal or is something even weirder going on at the ground level here? :sweat_smile:

1 Like
334

Hi,

found a bug with playing a script on the Autoblow Vacuglide 2.
When selecting/clicking a video in the library the default script gets automatically loaded onto the device for playing. Which works fine. But if I have more than 1 script and I select another script (from the script selection at the bottom) that one doesn’t get loaded onto the device. It’s still playing/syncing the already loaded script. Only if I do a quick disconnect/connect in the device window the selected script gets loaded. On all other devices (Handy, Tcode, buttplug.io) it’s working though.

1 Like
335

thanks for the detail in that, it is a better description than most bug reports i get and it gave me somewhere specific to look.

first, your actual question. yes that is normal. the repeating vr-activity, rescan-request and health lines are three background checks the app runs every second or two, and they will fill your log whatever else is happening. nothing is wrong at ground level. they are also about 95 percent of every log anyone sends me, which is my problem rather than yours, but it does mean the useful lines are buried.

on the actual bug, i think i know the mechanism and i can be specific about what would confirm it.

when you pause, the app sends a stop to the handy. that call can be refused by the handy api, and until now the app caught that refusal, wrote one line to the log and carried on as if it had worked. so the device keeps playing its own copy of the script from the cloud, the app shows paused, and there is no way for you to tell the difference except by watching the stroker. that matches what you describe exactly, including the physical button still working, because that is handled on the device rather than by us.

i have already got one log from someone else with that refusal in it, and the reason the api gave was “update required”, which would fit a 2 pro on different firmware to mine.

so, what i need. next time it happens, could you

  1. note roughly what time it was when you hit pause, even to the nearest minute
    1. then go to settings, help, open log folder, and send me main.log
    1. tell me which way you connected that run, ie already on at launch, paired by hand afterwards, or re-synced
      the line i am looking for starts with “HSSP stop error:” near your pause. if it is there, the device is refusing the stop and i know exactly what to do next. if it is not there, then the stop is not even being attempted and it is a different bug in how we listen for the pause. those two need opposite fixes, which is why i would rather not guess.

two things so you are not misled.

i could not reproduce it here. i have a normal handy, not a 2 pro, and i tried all three of your connection styles, played, paused, re-synced, paused again, and every stop went through cleanly. so this does look specific to your device or its firmware.

and in the next build the app will tell you when a stop fails, with a message saying the handy may still be moving and to press the button on it. if you see that message when you pause, that on its own confirms the whole thing and you can just tell me you saw it, no log needed.

one more thing since you mentioned it. you said the trouble happens on any connection style where the firmware version shows under the connection key. on the current build that field only fills in when you connect by clicking the connect button in the panel, and stays blank when the app connects on its own at startup. so what you were noticing may really be “the times i connected by hand”. i have fixed that display bug for the next build, which means the firmware will show every time, so it stops being a useful tell either way. worth knowing before it changes under you.

no rush on any of this, and thanks for sticking with it since 0.9.0.

1 Like
336

thank you, that is a really useful report. the detail about it only happening with more than one script, and about a quick disconnect and reconnect fixing it, is what let me find it straight away.

you were right that it was only the vacuglide. the app was sending the new script to the handy and to tcode and buttplug devices, but for the autoblow it decided a script was already loaded and quietly skipped sending the new one. so the device carried on with the first script while everything on screen, the heatmap and the script name and so on, updated to the new one. that is why it looked like the switch had worked. your disconnect and reconnect was just a longer way of clearing that out, which is why it fixed it every time.

it is fixed for the next release. switching script now always sends the new one to the device, and stops the device first so it is not being swapped mid stroke.

one thing i should be upfront about, i do not own a vacuglide so i have not been able to test the fix on the actual hardware. i am confident in it, but if you could give it a go when the next build lands and tell me either way, that would be a big help. and if it is still doing it i would want to know quickly.

thanks again for taking the time to write it up properly.

337

I’m glad the details helped!

If I learned anything from my brief window in gamedev, it was that giving a code wizard as much detail as possible is (almost) always helpful :face_with_hand_over_mouth:

I’ll try to do you one better, and make a fresh log file that should only include a single session of the startup connection to the handy working with a few scripts, then the playback issues after a re-sync.

Should have that in your DM’s soon :saluting_face:

1 Like
338

Is the Heresphere intergration still being worked on? I’m having issues with disconnects and the sorting/listing features not working correctly in Heresphere, but that might not be something you can fix if the bugs are on the Heresphere side.

2 Likes
339

Hi,
just a heads up and info. When starting the app today (5 days after installing the latest version) Windows Defender on my Win10 put the file “…/resources/backend/funsync-backend.exe” into quarantine because it detected the trojan “Program:Script/Wacapew.A!ml”
Hopefully a false positive.
But also when checking this file on virustotal.com 8 of 70 security vendors flagged the file as malicious.

1 Like
340

log came through, thank you. i have to correct myself first though, because what i told you to look for is not in there and never would have been. there is no HSSP stop error in your log, every stop came back successful, so the warning message i said would confirm it would never have fired for you.

the real cause is a queue. commands go to the handy one at a time so they cannot arrive out of order, and in your session one play took 20.59 seconds to answer. your pause went in behind it and sat there for the whole twenty seconds. app says paused, device carries on, nothing errors because nothing failed, it was just late. your normal is 1.4 to 2.5 seconds, so that one was ten times worse than your own baseline.

fixed for the next build. a stop no longer waits behind a play, that went from 20,590 milliseconds to 2 when i measured it. every call now has a deadline, five seconds for play and stop. and there is a new amber connection state for when the handy is answering slowly, instead of sitting on green while nothing you press does anything.

one favour when you get it. that five second deadline is a guess and yours is the worst connection i have seen, so if you start getting told a play failed when it would have landed just past five seconds, tell me and i will raise it.

1 Like
341

still being worked on, and both of those are mine rather than heresphere’s.

the sorting was the daft one. heresphere asks for the library as a plain list of links with no titles in it, and the code was sorting the links instead of the titles. every link ends in a hash of the file path, so you were getting your whole library in hash order. sorted by title now, headings too. on top of that heresphere had nothing to sort with until it had fetched every video one at a time, so there is now a single request that hands it the lot, titles, durations, dates and tags. i do not own a headset though, so i have verified that against the endpoint and not against heresphere itself. whether its sort and filter ui actually lights up is yours to confirm.

the disconnects i owe you an explanation for. there is a fix, it has existed for about four months, and it has never been in a release. found that out this week. when the headset goes to the background heresphere stops talking to the app entirely, and the app used to give up and wait for you to press connect. it will now keep retrying by itself. in the next build for real this time.

one question. do the drops line up with pausing? if heresphere goes quiet while paused, any pause over about eight seconds looks identical to a dead connection from where the app is sitting. that would be a different fix and i would rather know than guess.

also your duplicate finder is built and working. groups by size and runtime rather than by name, tells you which ones are certain and which are only likely, and shows you the space you get back.

1 Like
342

thanks for flagging it, and for checking virustotal rather than just binning it. it is a false positive.

the five days is the tell. the file did not change, a definition update arrived and retro flagged something that had been running fine all week. the ml on the end of Wacapew.A!ml is defender saying so itself, that is a guess from a heuristic and not a signature match. what it objects to is the shape of the file, the backend is python packed into a single exe that unpacks itself on startup, and malware does that constantly so anything built that way sits near the line. 8 of 70 is normal for an unsigned build like that.

i already do the one mitigation i can, the backend is built without executable compression and has been since may, which is in the version you have, so that was not enough on its own.

the actual fix is a code signing certificate, and that is a licensing cost i cannot justify right now. they run to a few hundred a year, and this is a free project that has brought in a few donations from some wonderful supporters, but it is not affordable at the moment. i would rather say that than promise you a fix that is not coming.

the fastest thing is for you to submit it to microsoft from your own quarantine, there is a submit link right there and it takes a minute. reports from affected users move much quicker than me saying my own file is fine, and a clear fixes it for everyone on that definition. otherwise an exclusion on the resources/backend folder gets you going again. either way it needs to come out of quarantine, that file is the bit that reads your library and makes thumbnails, so nothing works without it.

343

That was fast, thanks! I’m not sure if they lineup with pausing, it’s possible, i kind of gave up using it with heresphere after the constant disconnects, the try again window error was there and it just refused to connect again, i think funsync ended up crashing too. I tried this a couple of times and it just wouldn’t work properly.

1 Like
344

sorry you had that much hassle with it, that sounds genuinely miserable and i do not blame you one bit for giving up on it. thank you for telling me anyway, the try again message means heresphere’s timestamp server was not listening at all, so toggling it off and back on in heresphere’s settings is worth a go, and without that retry fix there was simply no way back in once it dropped. if you still have the log from the crash i would really appreciate it, settings, help, open log folder, main.log.

345

[sweats profusely] Uhm, well.. Fuck.

So uh.. 1.4 - 2.5 seconds is not a normal time people have to wait for a script to be sent to their device so it can start syncing?.. Hah.. haha.. fuck
I mean, I can pause and play with much quicker.. normal response times.. after that..

I should probably check it with some other tools and complain to the Handy people, huh? :melting_face:

1 Like
346

sorry that may have been a little harsh :sweat_smile: its likely just your connection is slow or your ping. have you tried putting it in bluetooth mode and using with intiface?

347

Haha, my feelings are fine! Dismiss your distress :face_with_hand_over_mouth:

I have been meaning to try a bluetooth/intiface setup but the only BT I am able to give my PC is the old white lovense branded one.
I keep meaning to get an actual BT dongle for it but uh.. yeah.

Might finally be worth looking into to be honest. I did a little research and it looks like it might just be my lot in life, for the internet mode, being in the land Down Under. If the handfeeling servers and whatnot are US based that might be the reason.

1 Like
348

good news on the lag, once the script is on the handy it plays it from the device itself, so the internet is only involved when you press play or pause or skip. that means your actual sync has been fine all along, its just the buttons that are slow, which is a much smaller problem than the one you think you have. the white lovense dongle wont do it though, that one only talks to their own toys, you would need a normal bluetooth adapter that windows sees as plain bluetooth. worth saying i have not tested a handy over bluetooth myself so i cannot promise it will be better, it should be since it cuts the servers out completely. if you do get one let me know how you get on, and ill pass it on to anyone else stuck a long way from the servers.

1 Like