Unable to upload Resources #29
Labels
No Label
Bug
Cantfix
Duplicate
Enhancement
External
Help Wanted
In Progress
Invalid
Question
Waiting
Waiting For Info
Waiting for Upstream
Wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Elara6331/itd#29
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It seems like I was unable to upload the resources file using either
res loadcommand or thefw upg -rcommand.After running,
I got the latest firmware, but the new watch faces were greyed out. When running
I only see
then the command exits with code 0. Those zip files do exist in the filesystem.
The watch faces are still greyed out.
I am using itd 0.0.8, specifically the .deb for aarch64 on a Librem 5.
As another data point, using the
itguiFS broswer, I can see a new "fonts" folder with the contents7segnments_115.bin, other than that andsettings.datI don't see any other resources.Can you run
itdwithITD_LOGGING_LEVEL=debugset, perform the resource load again, and provide the output? Thanks.I'm also having the same problem using the x86.64 .deb file. The resources file appears to install correctly the first time, but it's not recognised by the pinetime. After that I get the "removing" message if I attempt to install again.
What's the syntax for running the itd service with ITD_LOGGING_LEVEL=debug set?
output from running resource load after running
itd ITD_LOGGING_LEVEL=debug:I had a similar issue (itctl just sits with "Removing") but in my case it was due to itd trying to send the resources to the old watch firmware (1.6.0) which doesn't have support for the external fs. It might be handy to have itd check the version of the watch fw before trying to do fs operations, but also indicates perhaps an issue with error handling on the client/server part.
Perhaps if existing firmware < 1.11.0 && options include a resource file, break out instructing the user to upgrade firmware first, then load resources.
Client:
I had to Ctrl-C out of it. The second
Removingline is due to me pressingenterbefore doing that.Server:
Uploading the firmware alone after that worked fine though, using
ictl fw upgr -a pinetime-mcuboot-app-dfu-1.11.0.zipNow I seem to have trouble sending the resources though:
client:
(I pressed enter a few times to check client wasn't hung).
server:
Then I tried on the client:
Which resulted on the server:
I restarted the watch and itd and got the same results again trying to load the resources - first attempt gets 100% and times out, second attempt gets the "only one file can be opened for writing at a time".
I'm also having some trouble getting the pairing done (getting prompts from itd instead of via blueman-applet, and it is either not taking my keyboard input or the pairing is timing out), but I am sure it's unrelated, and the above is what happens after I do get it successfully paired and connected.
My guess is that it might be an issue on the InfiniTime end of the process, but there also appears to be a small bug in ITD not clearing its "write-lock" on the file after a timeout.
Yeah, the timeout happens because the watch hasn't sent back a response within a minute of sending a request. I am not sure exactly why that would be happening.
The "only one file" issue suggests ITD isn't closing the file if there's an error. I will fix that.
This error means that an error was reported by DBus, most likely from BlueZ. This is not an ITD issue, though I should probably improve the error message there by properly handling errors that aren't
FSErrors.You want to stop the systemd service first with
Then, run ITD manually in a separate terminal window with
Once you're done, you Ctrl+C to stop it and copy/paste the output here.
In order to restart the service, use
I've fixed some stuff. Please try again and see if it works. If your version of InfiniTime doesn't support BLE FS,
itctlwill now print a warning.Here are some packages for people who don't want to compile it themselves. Arch users should just use the
itd-gitAUR package to get the latest version compiled from source.If anyone needs files for a different architecture, let me know.
It has just come to my attention that the email functionality of my gitea instance broke (again), and I've fixed it, so I'm sending this to alert everyone participating in this issue of the changes and new packages.
updated to the latest provided ltd-0.0.9-next-linux-x86_64.deb package, and was able to get more meaningful output this time when attempting to run
itctl res load:using InfiniTime v1.11.0
Ok, that one I know. This is an error coming from BlueZ. The problem is that the filesystem feature attempts to request the MTU from the watch. This feature was only added in recent BlueZ versions, so my guess is that you're using an older version.
I have installed version 0.0.9, and now it doesn't get hung on "Removing", using
itctl res loadhowever issues still persist, even after restarts and multiple runs.Using
itctl fs list fontsthe file that is uploaded is zero bytes, so a successful transfer did not occur.The debug logs are below and back this up
That's weird. The logs suggest that ITD is trying to send 4928 bytes immediately. This should definitely not be happening, and points to something being wrong in BlueZ's MTU request feature. It would definitely explain the timeout. I will investigate further.
| That's weird. The logs suggest that ITD is trying to send 4928 bytes immediately.
FWIW, once I got my bluetooth issues sorted, and also resolved my pairing issues with the watch (it seemed to have invalid pairing data persisted) I was able to transfer the resources just fine with bluez 5.65-1 on debian sid.
I now have two systems at hand. On one it works and on the other it doesn't.
Working system:
Not working system:
Let me know if this would help you debug.
Here's my non-working setup:
Ah, you're using BlueZ 5.55. That would make sense because it doesn't have the MTU feature. What doesn't make sense is why it didn't return an error and instead just returned an incorrect value. What I'll do is check the BlueZ version and if it's too low, I'll just assume the MTU rather than checking.
I have the same problem. After flashing the firmware and resource package using the single command (with the v0.0.8), I still see that the two additional watch faces are grayed.
I wanted to report the same issue. I had flagged this on the infinitime github, but I think it may be an itd issue, as the other commentators have reported the same symptoms. I've tried multiple times to load the resource file after successfully updating and validating the latest 1.11 infinitime firmware. The resource load using itctl looks like it completes. However, running the debug command you provided didn't output anything during the attempt.
Those who have had issues with uploading resources, please try the attached ITD packages. I now assume MTU to be 256 if it isn't available, which should resolve the issues.
The latest version did work and solved my issue, even on BlueZ 5.55.
Thank you!
@mathemagician @ljishen Can you please try the new packages? If it's fixed your issues, I can close this and tag a new release with the fixes.
Just tried it and it worked! Thank you!
This version works for me as well. Great work!
Perfect, then I will make a new release.
@khimaros These errors suggest you are not actually running 1.11.0. Maybe the firmware reverted? Did you validate after installing it?
You can see messages like
This tells me your PineTime isn't exposing the filesystem transfer characteristic required for BLE FS.
sorry about that, i deleted my comment because i had come to the same conclusion.
newbie here, i didn't realize i needed to "verify" new firmware releases in order to prevent the system from rolling back to the previous.
thank you for making itd. it's a great tool!
I am new to all of this as well, the stack traces were only informative in that it led me to search in this project's issues. It would be lovely to somehow check the fw version against the resource version, or suggest that as an error when this failure comes up.
I thought I had updated the fw to 1.11 but it didn't take, user error on my part.