Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve speed #10

Open
javl opened this issue Aug 9, 2023 · 8 comments
Open

Improve speed #10

javl opened this issue Aug 9, 2023 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@javl
Copy link
Owner

javl commented Aug 9, 2023

Multiple users have responded saying printing through this script is (much) slower than through the official app.
I know the Android app uses bluetooth sockets, which in my tests seem way faster, but can't be used cross-platform.

Would be great to find a way to speed things up.

@javl javl added enhancement New feature or request help wanted Extra attention is needed labels Aug 9, 2023
@javl
Copy link
Owner Author

javl commented Jan 7, 2024

To add to this: an alternative would be to at least be able to select what backend system to use, so platforms that do work with sockets can use those, while other platforms use the current (slower) method.

@bezmi
Copy link

bezmi commented Jan 12, 2024

I have an instax square link printer. I reverted to a982f16 in order to use the socket backend as I couldn't make the latest BLE-only version work via my linux device (that's a separate issue).

Wireshark logs between my android device and the printer show that the data is actually being sent in chunks of 9891 bytes, which would imply a chunkSize of 9880 (removing 10 bytes for the header and 1 for the checksum). Setting this as the chunkSize instead of 900 or 1808 works and results in faster printing.

@javl
Copy link
Owner Author

javl commented Jan 12, 2024

The current backend already takes chunksize into account based on the printer model, see types.py.
I still would like to have an option to use both backends, in which case it would be good to implement this in the socket part as well so thanks for the reminder.

@bezmi
Copy link

bezmi commented Jan 12, 2024

The current backend already takes chunksize into account based on the printer model, see types.py.

Yep. The current default for the square link is 1808. I tried 9891 which is what the app uses instead and it was way faster with the socket code. I'd assume that increasing chunkSize would have similar effects on the speed of the BLE code, but I couldn't get it to connect to test this.

@javl
Copy link
Owner Author

javl commented Jan 12, 2024

Sorry I completely misread your message! I thought you suggested using 1808.

Your new size could mean a huge improvement. I don’t have a square myself but maybe someone else could try.
Thanks for letting me know!

@dtristany
Copy link

@bezmi I have square link as well. I tried firmware 0100 and 0101 and neither worked with chunksize of 9880 nor 9891

@bezmi
Copy link

bezmi commented Dec 16, 2024

@dtristany I set up a photobooth for my wedding with over 200 images taken using the larger chunksize and it worked just fine with the larger chunksize in late March. I will test again on my printer when I have time, it gives me an excuse to tidy up the photobooth app and release it publicly as well.

@dtristany
Copy link

dtristany commented Dec 17, 2024

@bezmi That's a really cool idea.
Was 9891 the size of the packets or data size on wireshark? According to #this you have to remove 26 bytes so that would be a 9865 chunk size.
Or maybe the bluetooth protocol varies slighly between different platforms and the length is off. I'm on windows 10 and my printer seems to be listed twice as INSTAX-XXX (IOS) and INSTAX-XXX (ANDROID). I've been connecting to the IOS one.

EDIT:
A quick way to check if the protocols are different is for you to turn on verbose on this script and we can compare the DOWNLOAD_START packets. Mine is :
event: EventType.PRINT_IMAGE_DOWNLOAD_START ; packet: b'aB\x00\x0c\x10\x00\x00\x00\x00\x07\x10)'
710 in hex is 1808 in decimal. If you saved your wireshark packets, you can also see if that has changed since March.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants