When I take a picture that I need on my computer, I open the app and sometimes it starts uploading that picture. Great. But sometimes it doesn’t upload it.
Expected behaviour
There should be a way to trigger the picture-upload. If just starting the app doesn’t work, then there must be a menu item to trigger a check of the picture upload feature.
Steps to reproduce
Take a picture
check server if picture is uploaded yet.
open the app, nothing happens.
Check the uploads tab. Nothing happens, new picture is not listed.
Can this problem be reproduced with the official owncloud server?
Yes, I think it can I think I have this. I do not think the server matters though.
Environment data
Android version: 14
Device model: moto G54 5G
Stock or customized system: stock.
ownCloud app version:4.4.1 (4ef4cc200)
ownCloud server version: old, but works-for me.
Logs
Web server error log
Log is irrelevant as the client never contacts the server with this upload.
ownCloud log (data/owncloud.log)
Log is irrelevant as the client never contacts the server with this upload.
Adding extra information by quickly editing the post is not possible??? Then it will have to go in a reply.
Of course the upload eventually happens. In the case at hand, I manually pushed the upload to a different directory by share->owncloud, and while writing this question, it was uploaded automatically to the pictures directory. But I often don’t want to wait that long if someone asks me for a reply-with-picture that I need/want to write on my PC.
Yes, I have automatic upload of the pictures I take enabled.
When someone asks me: Can you send a picture of xxx and I want to type something more than “here it is” I prefer to do that on my computer (and I don’t have email on my phone). So I’ll go and take the picture and then want to send the reply and not wait 15 minutes for it to upload. If I go and do something else, I’ll forget I have to go back to sending that reply. And I also don’t want to sit around doing nothing for 15 minutes.
I can hit refresh on a shared directory 15 times in a row, but you’re saying the app is prevented from doing a “check now” on user-request? I can imagine that android forbids you tot check more often in the background. But surely it is not forbidden to do something in response to a user-action ?
Well, for that use case, you should use “Pictures form Camera” instead of automatic uploads. “Pictures from Camera” allows you to upload one picture from the camera at the moment. You’ll find this by clicking the floating button (+) → Uploads → Picture from Camera.
Automatic uploads are intended to be done in background. Typically: you are on a vacation, a visit… you are taking pictures and videos that will be synced to the server at any moment (short term, for sure). In background, Android system does not allow to trigger more ofter, as i commented before. Checking the existing files with a button to force the upload, is not implemented.
Back to the initial problem. You take pictures automatic uploads that are not enqueued in the uploads view (bottom bar). I guess, after 15 minutes is there, or not? Is your camera folder correctly setup in the app’s Settings view?
I have my own server without public IP address. So my phone can upload when it is connected to the right WIFI network (of which there are two). On my old phone it also worked when I enabled the VPN, but I havn’t set up the VPN on my current phone yet.
Slightly annoying, that when is active it doesn’t check for a “sudden restoration” of the connection to the server, at which point it could upload the “failed upload because server was unreachable” files. I have to hit “retry” manually in the uploads tab.
I just tried “pictures from camera” and it uploaded the picture to a different place than where it would go if the automatic upload triggered. I already have that by opening the picture and hitting “share” and then “owncloud”. And in that case I put it where it DOES get synced to the PC…
Yes, it is correctly set up, and it will show up in “uploads” after a while. When I’m on the right wifi, the upload happens. So when I’m not in a hurry to use the picture I sometimes see the “a new file was added” popup on my PC.
So there is no workaround that’s better than what I already have. And the button I’d like to have is not implemented.
My phone is a Motorola moto G54 5G.
Uploads restart by themselves when the error comes from device connection. Device can handle connection loss and recover scenarios to resume the pending work.
But, device can’t guess when the server becomes available after an outage (whatever the reason of the outage). Sure, we could poll it to resume automatically the pending uploads when it is back, but this was not the implemented policy. For that reason, every failed upload for any reason but a connection loss must be resumed by a manual retry. This is not an odd decision.
“Pictures from camera” works in the same way as manual uploads. File is uploaded to the current folder.
My server has an uptime of 695 days today. I suspect I installed it around two years ago and it has never rebooted. So “server outages” are minimal.
As I regularly find pictures that I didn’t immediately need a few days later, I don’t think the “caused by connection issues” and “caused by server outage” detection is working correctly in my case.
I wouldn’t advocate the program trying to poll “all the time” for a re-established connection. But if there are uploads that need to happen and there is a verifiable connection to the server (i.e. a n upload that seems to work), that would imho warrant a retry.
When my phone is on a public network like the “mobile network” it’ll see a “host unreachable” for the private IP address that my server holds. It seems that the owncloud app then interprets this incorrectly as a “host problem” instead of a “network problem”.
Let me state for the record that I REALLY think it is allowed and reasonable to check for new (automatic) uploads say when I go to the “uploads” tab. And a new “upload now” button can then trigger the “not yet failed” uploads.
Just as a quick response: does not matter how long is your server available if the mobile device does not detect it, for example, if you go out of the network scope. For the app, this is the same as an outage.
Anyway, the topic of this thread was the trigger for automatic uploads, i think that is already clear. If you have other regards, ideas or suggestions, we are happy to interact with everyone in the community but in an specific thread either here in Central or in the open Github Android repo: GitHub - owncloud/android: ☎ The ownCloud Android App
Also, if the initial request is still interesting for you, you can open a feature request in GitHub that the team will estimate and schedule inside the roadmap. Thanks again!
Someone earlier implied there was a difference between a server outage and a network outage. When I go out of “network scope” I consider that a “network outage” (will retry) but the app seems to react as if it is a “server outage” (no retry).
I tried the “wait for the uploads to happen automatically” tactic yesterday. I was about to go write: “but the uploads actually never happen”, when they did start to happen.
Sometimes way later than “15 minutes” after I took the pictures.
Good: Pic taken 20:53 uploaded at 21:01.
Medium: pic taken 20:29 uploaded at 20:53.
bad: pic taken 17:34 uploaded at 18:06 (together with pics taken 17:41-44).
bad: Pics taken up to days earlier uploaded at 09:24.
The app does not seem to request “autorun” permission, Does this mean that the permission was removed from android or that the app DOES NOT autorun?
Can I make a suggestion? (old tab in my browser positioned me at connection vs server problems).
Why wouldn’t you retry a “server problem”? Problems that you should not retry are “login incorrect” “storage full cannot upload now”. That sort of problems.
Any “cannot establish a connection with the server” problem should be considered a network problem.
There is one “tricky” case to classify. “host unreachable” or “network unreachable” are firmly in the “cannot establish a connection” class, so network problems → retry.
But “port unreachable” which is firmly FROM THE HOST, might be considered either way. IMHO, I would make it easy for the code and consider this a network problem with retry: If this happened, you’re probably trying an upload with the server rebooting ffor some reason, a retry is likely to succeed.
You go outside (with decent connectivity) and take a photo.
Put the phone in your pocket. The connectivity turns terrible, basically no connection.
Hit the 15 minutes mark. The app tries to upload, but without usable connection it fails.
After a while, you take out your phone again to take another photo. Again, the connectivity is decent.
Put the phone back into your pocket.
Another 15 minutes mark is hit. Again, the app tries to upload the files (including the photo taken in step 2), but there is no connection.
Basically, the app retried the upload, but both times it couldn’t upload. This could explain why the app sometimes take 1 hour or more (until it has decent connection) to upload the files.
There are a couple of things they can implement to improve things:
Include logs or a way to trace when the automatic upload runs and what files (or from what time) is trying to upload. This will help to prove that the automatic uploads runs on time, or if there is some kind of problem. Basically, traceability of the automatic uploads.
I think it’s possible to run the app when you recover the connection. It should be possible to run the automatic uploads if we’ve recover the network connection AND the job should have been run before (basically a fast retry). I assume that overlapping executions isn’t possible (just queue the job)
Why wouldn’t you retry a “server problem”? Problems that you should not retry are “login incorrect” “storage full cannot upload now”. That sort of problems.
Any “cannot establish a connection with the server” problem should be considered a network problem.
Well, the “network outage” and “server outage” seems similar but under the hood, they are very different situations that are handled in pretty different ways. As i commented before, device knows when it has a connection active or not, but it does not know the reasons an external server is not reachable. In order to schedule automatic retries for a non-reachable server outage, we have to poll the server every X time (not desirable)… however, the network outage is notified to the app by the system at the moment. Feasible? yes. But, in order to implement this in a clear way, server should be the first to implement something to notify when it’s available or not.
About the times to execute the uploads, take in account the scenario @jvillafanez comments. The point is, the uploads do not happen exactly 15 mins after the picture was taken. There is a background job that catches the new pictures and enqueues them to the upload service. This job is executed every 15 mins minimum , and is the Android system who decides when (not us), depending on the load and work that it has to do with other available and installed apps, battery level and so on… We have nothing to fix there, system just assures the job will execute, not when it will be executed.
For example:
Job runs at 11:00 and enqueues nothing (not pictures taken)
Take a picture at 11:14
Job runs at 11:15 and enqueues the picture taken at 11:14. You only had to wait 1 minute.
Then, think that s has the reverse situation: taking a picture just after the job, and, for system reasons, it takes 25 mins to execute again. You had to wait 24 mins. Not in our hands.
You can check the last job’s execution in the Automatic uploads section, in Settings.
So you’re confirming that when I’m out of reach of my wifi (but have 5G coverage) owncloud misclassifies my network problem (server unreachable from current network) as a server problem…
Yes, because this is not a network problem. Out of your wifi, the device has connection, therefore network is ok. The error (or the global status) to show is based in the device’s perception, not in the app’s perception, because the device is who provides the network service to all the apps. As i told you, could we change that? yes, it’s feasible. But the solution will not be clean.
IMHO, keeping the “server seems down” failed uploads in “will never retry” is silly. It would be much better to retry them on “confirmed connection to the server”. The confirmed connection would be a successful upload, but (to be implemented separately) maybe also an empty connection-attempt say every 1.25 hours.
I understand the need for a distinction between: “will never succeed” errors and “might retry”. But imho too much gets lumped into the “will never succeed” category.
The way I live, about 90% of the time there is a connection possible to the server. So I don’t expect to find “failed uploads, waiting for manual retry” ever. I don’t expect to find not-uploaded files in my upload queue that are a week old.
I want to automate stuff I would otherwise need to do multiple times. So “backing up pictures I take to my server” is one of those. And it’s not automated if I have to manually trigger the upload.
Why do people use “owncloud”? Because they don’t want to auto-upload to “the cloud”, right? So is it so uncommon that I have my own server? Is it uncommon that I want it unreachable from “the internet” ?
I’ve set up an HTTPS server on the internet on an uncommon port. Now 3 days later, apparently my phpmyadmin server has been probed by 139.87.112.16 15600 times for common defects… So indeed putting a server on the internet is dangerous. If you want to install-and-forget you’ll get hacked pretty quickly.
Edit: Update: It is currently uploading pictures I took 5 days ago (4 pcs) and 11 hours ago. I’ve been “out of reach” of the two only “good” wifis for about 15 minutes twice a day. So the server has been reachable for 117 out of the last 120 hours and it has not uploaded my pictures. As a non-computer-user I’d completely “not understand”. As a computer-nerd myself. I can understand the circumstances leading up to the misclassification, but not the attitude: “that’s the way it is and we don’t feel it needs to change”.
I’d want to be clear for that. Community is a pretty important part of our process. For that reason we are here in central as well as in other feedback channels. There are plenty of features and fixes in the app that come from the community and we expect to keep following that path.
Unfortunately, not everything is posible/feasible at any moment. The last suggested change sounds very good in the perspective of the user, but it will carry total disruptive changes in the code that will change an important part of the sync engine, just for avoiding clicking a button due to an device’s external condition like server out of scope. Is that ok? yes, for sure, and we are thankful for any suggested improvement. But, as a team, we have to balance our priorities and efforts with all the suggested features and making decisions. This does have nothing to do with the total respect we have for every contribution in the current channel or others.
This is not a matter of attitude. Never. If it’d be, this thread wouldn’t have lasted so many messages.
Sorry if my message was misunderstood, and thanks again for all the ideas and contributions.
PD: The first initial suggestion about a button to trigger uploads in foreground can be checked and it would be an improvement. Just to be clear as well.
And the button I’d like to have is not implemented.