Jiotty on Raspberry Pi #113
Comments
|
Hi. Last time I checked, the google photos library I am depending upon uses pre-built native binaries that they only ship for 64 bit Intel architecture. This is the reason Jiotty can’t run on anything else. having said that, I have not checked their latest versions. Maybe they already support other architectures. I do have a Raspberry PI 4 at hand for my home automation, so can easily check. will do in the nearest future. As for your run - this task runs UI, so nothing is printed to the console. All the logs to go |
|
Just realised there was a typo in README.md. Plus Just tried on RPi - it fails because there are no arm javafx libraries. javafx is the java UI library: OK, we don't really need the UI on RPi, although it'll be a little more difficult to specify configuration without the UI. So I've tried building the binary (BTW just added command line to build it to README.md). Problem with this is that by default a build on linux tries to build both rpm and deb packages. So I temporarily patched The build failed, but that's because I hard code the architecture in the name of the .deb file (can be fixed later) The key point is that the binary is now ready in I had a few times where gradle daemon crashed during the build and a single occurrence of an integration test failing, probably because it timed out on a slower machine. So I had to retry a few times. An oh boy how slow the builds are one RPi compared to my MacBook Pro 2019 :) |
|
Hi, I hope it will work :) Perhaps you had crashes because of lack of swap space? I have increased mine from 100MG to 1GB. You refer to a Best regards, |
|
Anyway, my main priority now is to make CLI work. |
|
Alright, if you |
|
Alright, UI now works too on RPi, was just a matter of using a proper JDK with RPi-compatible javafx (Full distribution of Liberica OpenJDK 16) - follow the updated steps in README.md. While the binary works, I am not sure whether the resulting .deb installer will be self-sufficient to work without the installed JDK at all. I'll test that later. |
|
Hi, I still got a problem. Here's the output for building a native binary: Here's the error report from If I do the |
|
Did you do |
|
Hi, before my previous message, I had done a I reinstalled the jdk using the download link in your previous message. Originally I had installed it using these instructions, which is perhaps not taking the full jdk: https://bell-sw.com/pages/repositories/#apt Just to make sure, here's the installation path: When I do the binary build, I still get the test failure: When I do the run command, there seems to be progress. I very briefly see the GUI popping up, but then it crashes. The output: When I look into the log, this seems the error that throws it off: When I then run again, the same happens, but now on the console the build is reported successful. Yet the same error is in the log. |
|
|
Made a few more fixes - it now builds the .deb fine, and that .deb installs and runs fine on my RPi. I'll soon release 2.0.0 with the RPi binary. The binary will not require and JDK installed, obviously, as it packages it all together. It even adds a shortcut to "Accessories"! :) |
|
On my RPi, I sometimes see an error in the log like in a submitted issue #115 when started via gradle run. If this is what you see to, then starting from binary is the only way. |
|
Hi, I have a Raspberry Pi 3. Again making progress, but not there yet. The fullpackage build succeeded, after burning one of my cores for 30 minutes. The 150MB deb could be installed. Running jiotty just flashes a window that disappears immediately and writes nothing on the console, but I attach the main.log in this message. I repeated the build while storing the output to build.txt, as well attached. Then I also did the 'run' again, same result: GUI flashing briefly, then nothing. Output is in run.txt. I hope you can make something out of it... Best regards, |
|
The log just shows that the 10 seconds the app gives to initialise the UI is just not enough for the slow RPi3. I've just increased it to 30 and pushed - you'll have to rebuild again or try the faster "run" task again. BTW if you add Just an observation that fullpackage on RPi4 takes 9.5 mins. Another hint: later, when you've done with building Jiotty for good, you can remove |
|
Released 2.0.0 with the RPi deb in it, so you don't have to build. If we discover any more issues, I'll do a patch release 2.0.1. |
|
Hi, I've rebuilt the deb and now Jiotty GUI is showing and interactive, but after a few moments it's gone again. Same behaviour when I install from the released build. main.log attached for both runs. |
|
Took me a while to figure this out. Th login dialog is supposed to show an integrated browser, using the native WebKit javafx library. That library is not included in Liberica JDK. https://bell-sw.com/pages/liberica-release-notes-16/ even says "Java FX Webkit - does not work." It worked on my RPi because I logged in from the command line. You can do this too - just run the command line version specifying the directory to upload. Since we can't use integrated browser on RPi, I've made a small improvement to use the system browser in this scenario, so the UI login will work now too. Released 2.0.1 - please try. |
|
Hi, Me again :) The login request is now coming up in my browser, but it won't succeed. When I enter my credentials, the browser returns a screen saying "Error 401 (bad request) - The server cannot process the request because it is malformed. It should not be retried. That's all we know." and the app is frozen.
I tried this on the GUI and on the command-line executable. I also tried logging in to some other Google website on the Raspberry Pi, and that worked. The console output of the command-line is not consistent. Here's the console output for three subsequent tries, each time with the above behaviour in the browser: I've attached today's logfiles, which cover a number of tries in the GUI as well as on the command-line. |
|
I am at loss with this one. I presume that when you run the console app, it opens the browser too? Can you please, instead of using that browser window, close the browser completely, copy the URL from the console (the one after "Please open the following address in your browser:") and paste it into a fresh browser instance? If it still does not work, can you try going to Chromium browser settings, privacy and security, clear browsing data, time range=all time, and click "clear data" (I hope you don't mind it forgetting all your previous browsing data), then try launching Jiotty again? Finally, if that does not work either, can you copy the URL from the browser URL field immediately after Jiotty opens the login URL but before you enter your credentials, and paste it here? All this Google OAuth thing does is an HTTP GET to google, and google calling the "redirect_uri" bad when the login is successful. While typing this, I remembered having the same issue on RPi Chromium earlier, with another app of mine that uses similar login style with manual copy-pasting of the URL into a browser and a subsequent callback to localhost. I was not too concerned with this at that time as I was the only user of this app and also because it worked with another browsr. At some point it just started working again with Chromium. I did do a few RPi package updates in between. Can you check your Chromium version? Mine is |
|
I understand that logging in to other Google services works, but this callback style OAuth is not really the same in terms of code path as logging in to web-based apps. |
|
Hi, none of the above worked. This was the browser version:
I upgraded to the same version as yours:
And now it works! It's getting late now :) Tomorrow I'll check if I can configure Jiotty to use my own client secret and then I'll close this issue. Thanks for all your support! Best regards, |
|
Great! Seems to have been a bug in Chromium. |
|
Hi, configuring my own client secret seems to work as well. I did a couple more tests with the command-line tool and although the pictures and albums are uploaded to Photos without problem, this error is displayed on the console before the program exits. Should I worry about this? Could it be related to the Raspberry Pi setup? Best regards, |
|
Is this error reproducible or random? Can you please try doing it in the UI and then send me the log? Hope is that it will also happen in the UI and then I’ll have a lot more context from the log. Thanks. |
|
Hi, |
|
OK so I found a bug (introduced together with #105) where any errors during the free google account space refresh are “swallowed” (instead of being displayed to the user). I’ve fixed the bug, which will allow you to see the root cause. I’ll push soon. The error is related to Google Drive API requests. Do you remember, when logging in, whether you allowed access to “app data on your google drive” or denied this access? If you denied, this would cause the issue. The permission only allows the app to read and write to its own data folder (the so-called Application Data folder: https://developers.google.com/drive/api/v3/about-auth) - the app can’t see any of your Drive files, so it’s safe. |
|
As far as I remember, I just confirmed any permissions that were
requested.
28 Jun 2021 12:15:53 Alexey Yudichev ***@***.***>:
… OK so I found a bug (introduced together with
#105[#105])
where any errors during the free google account space refresh are
“swallowed” (instead of being displayed to the user). I’ve fixed the
bug, which will allow you to see the root cause. I’ll push soon. The
error is related to Google Drive API requests. Do you remember, when
logging in, whether you allowed access to “app data on your google
drive” or denied this access? If you denied, this would cause the
issue. The permission only allows the app to read and write to its own
data folder (the so-called Application Data folder:
https://developers.google.com/drive/api/v3/about-auth) - the app can’t
see any of your Drive files, so it’s safe.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on
GitHub[#113 (comment)],
or
unsubscribe[https://github.com/notifications/unsubscribe-auth/AABHZDFLJKC7T3OJOTARYA3TVBDVHANCNFSM47COI6HA].
|
|
OK then we need to see what exactly the problem is. I've just pushed the aforementioned improvement. Could you We're getting there! |
|
Now I get an error even before it attempts to upload pictures. Is that what you're looking for? Logfile attached. |
|
Yes - it's now clear what the reason is. You're using your own Google project & client secret. You need to enable Google Drive API in your project - Google were helpful enough to even include the URL to go to in the error message! This reminds me to update my instructions on the wiki to mention enabling the Google Drive API. |
|
Wiki updated. Let me know if there are any more issues or not. If not, I'll release a new version. |
|
Added Drive API and the error is gone! |
|
Great collaboration, thanks! Will release 2.0.2 soon. |
|
2.0.2 is released with all the latest bugfixes |
Hi,
I'd like to run Jiotty on my Raspberry Pi (Raspbian 10) as part as a back-end script that synchronizes images onto Google Photos (so Jiotty will be used in command line modus).
Since there's no ARM build, I've followed these steps:
sudo apt install gradle)./gradlew -DDCLIENT_SECRET_PATH=/home/pi/client_secret.json run(as in the README)This is what it returns:
Then it just finishes, there's no GUI popping up and as far as I can tell there's no binary produced.
I'm not familiar with building java applications, so maybe I missed something... Would you think it's feasible to get Jiotty running on an ARM based system?
Best regards,
Vic
PS. Here's the extra warning that is returned when running with
--warning-mode all:The text was updated successfully, but these errors were encountered: