Auto upload: wifi/charging only for specific filetypes

[tobiasKaminsky]

Back on old instant upload we distinguished between upload on type and "situation"

• video / wifi only
• video / charging only
• images /wifi only
• images / charging only
  all settings could be changed interdependently.

Now with auto upload it is "folder based" and only options are

• Upload pictures via wifi only (which is misleading as it applies for all file types)
• charging only

So my idea is to extend this to have a selectable pre-defined "mime-type" list:

• pictures
• videos
• other
  The menu setting would then be
• Upload via wifi only
• Upload when charging only
  Each setting has a second option line where the selected items are be shown:
• Upload via wifi only: videos
• Upload when charging only: videos, other

@AndyScherzinger @eppfel

[eppfel]

This sounds a little complex, especially because the auto Upload settings are already numerous. I would first think about the use-cases for the old options used in Instant Upload. Maybe it is more related to file size, than to file type?
And to achieve what you suggest one could easily separated file types in separate folders on their android system.

Anyway It would be a powerful feature to sync distinctive mime types, I just see bigger issues now.

The misleading description about "pictures" should be fixed independently.

[tobiasKaminsky]

The misleading description about "pictures" should be fixed independently.

This is done in #494

Maybe this is a topic for a meetup :)

[AndyScherzinger]

Yes, this sounds like a meetup would help a lot! 👍

[kvoit]

As I suggested and motivated in #587, I think the current possibilities are insufficient. I understand that the new auto upload feature is meant to be more general and I don't think we need complex rules. However, a size threshold for mobile upload would be help a lot: If file >10MB, wait for Wifi to upload. I don't think this would make it too complicated.

[jmclaren7]

It seems to me that upload conditions based on file size would be a first step in addressing the issue of conserving data (upload only on wifi). However, it wont help keep media organized. Most of my users and myself organize videos in separate folders and that feature was a must have of the old app.

I haven't made myself familiar with this project but maybe this concept would minimize the work needed:

• When scanning for media directories we should note ones that contain both photos and videos.
• Display the list of media directories as we currently do (combined videos and photos). ie a folder called "Camera" would be listed.
• Append to the list any directories that contained both types but apply a filter to only work with photos and display on the list as "Camera (Photos only)".
• Append to the list any directories that contained both but apply a filter to only work with videos and display on the list as "Camera (Videos only)".

For the general use case a file size option is probably more valuable but i imagine both these features would be possible if the technique I described for the file-type condition is possible. I imagine the file size option would fit into the dialog for the folder preferences and apply to that entire folder. In the case of the technique I described this would actually be rather versatile as it would give the option to control the upload size condition separately for videos and photos.

[AndyScherzinger]

@tobiasKaminsky @mario @eppfel @jancborchardt what do you think of @jmclaren7's approach? Technically this is doable and to me it seems to be one way to do it.

I am not a UX expert so I don't have (a better) idea how else this could be solved but I understand the requirement of having images and videos sorted into different remote directories and that is doesn't work for folders that contain images and videos (or even images/videos/audio).

[AndyScherzinger]

@tobiasKaminsky what do you think of splitting images/video into 2 "folders" e.g. for camera where we then would do it based on the file types? To me this would be a pragmatic solution in handling this, especially when custom folders are added to the game.

[mario]

There are other filetypes too however :)

…

On Mon, 3 Apr 2017 at 10:08, Andy Scherzinger ***@***.***> wrote: @tobiasKaminsky <https://github.com/tobiasKaminsky> what do you think of splitting images/video into 2 "folders" e.g. for camera where we then would do it based on the file types? To me this would be a pragmatic solution in handling this, especially when custom folders are added to the game. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#486 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAWsmwPkTohb1hCUyp0ciqRamo3KIayks5rsKkPgaJpZM4LXnpg> .

[tobiasKaminsky]

What about a nice UI like we have in sorting dialog:
In the rows we have the mime types (video, photo, other) and on the column we have a enabled/disabled icon for wifi / charging and a target folder.
The rows can be enhanced one by one, to e.g. support filter on file size, or to create a custom mimetipe rule.
This later ones are my longer term idea. But we can start with the UI and the three predefined mimetypes (photo, video, other)

[AndyScherzinger]

There are other filetypes too however :)

Well there are only 3 due to what we can query from the Media DB: audio/video/images ;)

In the rows we have the mime types (video, photo, other) and on the column we have a enabled/disabled icon for wifi / charging and a target folder.

Not sure about how this would be integrated into the dialog flow and how to handle the complexity. Wifi and charging are easy, path is a long string that needs to be displayed which isn't fun in portrait, which is why the actual config screen per folder has a vertical layout since it only shows the data for one setup, not 3. I'd really like to get some input from @nextcloud/designers since I don't see a proper solution yet while we all argue into different directions...

[kvoit]

Am I really the only one whose issues are just that I don't want to upload an imperial shit ton of data from a 4K video over my mobile plan? A simple threshold would do for now. It should be there anyway. I do want synchronize my KeePass database, i do not want to upload a 2gig binary image that accidentally ends up in that folder, regardless of it is the same media or mime type.
It is one line in the GUI, and it would probably cover 99% of the cases that you would cover with a distinction image/video/other.

[AndyScherzinger]

@kvoit unfortunately it doesn't since from (a very small) group of people we also get a lot of hate since videos and images now go into the same folder and that is the even more reported issue for users than the size or wifi vs. cellular network issue. So at least from my perspective it is not that simple since we need to look at all problems people report with today's auto upload solution so it then does truly cover 99% of the cases.

[kvoit]

@AndyScherzinger It is nice that you want to help those people, but in my opinion, it is not really your problem. Android decided to shove it into one folder, it is on Android to fix that (I actually tried to look if that is possible to solve my size issues, but apparently there is no easy way right now.)
So if it is about "getting hate", I would go with "screw those people". Right now, your job (no disrespect, keep up the awesome work, thanks a lot!) is to provide a a useful upload, and that contains some data volume control. A threshold fixes that. It does not contain fixing Android insufficiencies, necessarily.
If you want to provide such a service to users like that, good on you, that is nice, but it is another project, I guess.

[AndyScherzinger]

<3 Thanks @kvoit so the data volume control would have to work which way?

Looking at a folder (which would be one config item): What should the size limit imply? If set:

• everything below a certain value gets uploaded on cellular
• also meaning everything above the value gets uploaded on wifi only?
• any link to the "when charging only" setting?

The Android change is something Google did, true. While users are sometimes just users and no Android devs themselves it is hard to explain why a feature isn't there anymore which they were used to before, since the app doesn't do it anymore which is what you experience and usually people don't have such a detailed insight into Android's OS changes which force features to change or even die :(
But thank you very much for your understanding and your patience! I really appreciate this :)

• everything above a

[kvoit]

I don't really see any patience. You are providing a awesome open source project for free. Everything is an extra to be grateful for.

So for ME, it would be enough if everything above a certain threshold would not be uploaded on cellular but later on Wifi. I think this models the demands of most people in most countries. Modern smartphone videos (4k) exceed almost any volume plan and something has to be done about it to make mobile upload useful again. Right now, it is not, because each video would drain my data, even though I have 4GB, which is already pretty good for Germany.
Make a checkbox "Do not upload files larger than ... via cellular." If someone can spend the battery to squeeze a 6MB photo over an EDGE connection, he can also upload a 1GB video over 300MBit wifi, in my opinion. So more settings are not essential, I think. If you find a tidy way to put it in, feel free, but if the desire to keep it simple keeps you from implementing the whole thing, don't :)

Heck, this could even be a global setting for auto upload, not a per-folder one.

[AndyScherzinger]

uuuuuh, I like the idea of a general threshold which could then also be checked for manual uploads where the user could be asked if he/she really wants to upload that 2GB file on a cellular network :)
What do you think @tobiasKaminsky @mario

[tobiasKaminsky]

General threshold is really a great idea, also for uploading files, but it is not solving the specific issue how to handle different filetypes.
If @mario is fine with this, the general threshold should be a new issue.

[AndyScherzinger]

It doesn't solve the complete issue, true. But it solves an aspect of the whole discussion without introducing a limitation for possible solutions for the file type part, imho.

[duckulaj]

I am one of those pesky users that grew accustomed to the old auto upload, it worked intuitively.

If the OS changes in my experience as developers we have to find a solution that either maintains current functionality or improves upon it.

I understand that Nextcloud is free and appreciate your hard work, but implementing something which users do not like is not the way forward.

As for file size, the previously mentioned use cases seem appropriate.

[mario]

I think this issue is solved with newest auto upload. Please confirm? :)

[jmclaren7]

@mario I just installed the dev version and I don't see what's pictured in #797 or any other options related to differentiating media types.. should I be using something besides the dev version?

[mario]

Copy/paste :)

Dear users,

thank you for your patience. After lots of work, we’re super excited to be able to give you a test version with new auto upload implementation. Keep in mind we will only accept bugs related to Auto Upload in this APK, as other things might be broken.

https://cloud.nextcloud.com/s/ftZraTruRQjTe0R

This is a dev APK so it will not overwrite your existing play store/f-droid APK unless you’re already running dev version. Also, you might need to remove your existing dev version before installing this one.

Explanation of the current functionality:

added support for custom folders
separated image and video folders
checks for new files happens every 15-20 minutes
automatic retry every 15-20 minutes or when you force close/open the app
automatic pause once network is changed (untested!)
significantly less battery usage
All and any testing is more than appreciated, especially with large and ever-going files like Videos. (like, try to record a 30 min video).

Let me know if you’ve got any questions.

Cheers,
Mario

[mario]

IMplemented for 1.5. Closing.