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

Division by zero error when adding photos #361

Closed
sirjaymond opened this issue Apr 16, 2020 · 11 comments
Closed

Division by zero error when adding photos #361

sirjaymond opened this issue Apr 16, 2020 · 11 comments

Comments

@sirjaymond
Copy link

So I'm getting the below error under the following circumstances:
[PHP] Error: Division by zero at /var/www/html/custom_apps/maps/lib/Service/PhotofilesService.php#407

I have a bunch of photos uploaded to NextCloud. I then add them to the scan job with the following command:
docker exec --user www-data nextcloud php occ maps:scan-photos

The next time the cron job runs, I get the division by zero error, and none of the photos appear on the map.
The error is not happening for photos that I've recently uploaded through the Android app, and these seem to be added to the map just fine.
The photos giving the error were taken previously, and uploaded via the Linux desktop app.

Thanks

@tacruc
Copy link
Collaborator

tacruc commented Apr 16, 2020

Frist of all you don't need to run maps:scan-photos, after you uploaded pictures. maps:scan-photos will triger a full rescan of all files. When a file is uploaded a scan of this file is automatically scheduled.

Related to #123.

Can you email me one sample picture, where the error occurs. Than I can see what's the exact problem. Otherwise I can just silence the error message by skipping the image.

@sirjaymond
Copy link
Author

sirjaymond commented Apr 16, 2020 via email

@tacruc
Copy link
Collaborator

tacruc commented Apr 17, 2020

I will close this issue as it seams to be a problem with the exif data.

@tacruc tacruc closed this as completed Apr 17, 2020
@ggeorgg
Copy link

ggeorgg commented Apr 27, 2020

I also found some lines in my log with this error:
Division by zero at /srv/www/nextcloud/apps/maps/vendor/lsolesen/pel/src/PelCanonMakerNotes.php#229
I guess it is also a problem that needs to be solved in the external library. Nevetheless, can we apply a catch for these lines as well? Where would I need to insert the logger line to get the path to these "broken" images? Is it the same as in the other issue?

@tacruc
Copy link
Collaborator

tacruc commented Apr 28, 2020

Is the same as the other. The pel library is only used once to get exif data. And it is only a backup if the PHP internal function is not working for what ever reason.

@AykutCevik
Copy link

@sirjaymond how did you upload the pictures so the originals had the GPS data but the uploaded ones not?

@TheBluestBird
Copy link

TheBluestBird commented Mar 21, 2021

I will close this issue as it seams to be a problem with the exif data.

I'm so sorry, but the cron job just silently fails because of that, and this is okay for you? No need to check or try-catch, or whatever you have there in php? The leak is on the other side of the boat?
How do I run my cron jobs again? I have no clue which of gazillons of pictures my users uploaded have wrong exif, how do I even find it?

@tacruc
Copy link
Collaborator

tacruc commented Mar 21, 2021

I will close this issue as it seams to be a problem with the exif data.

I'm so sorry, but the cron job just silently fails because of that, and this is okay for you? No need to check or try-catch, or whatever you have there in php? The leak is on the other side of the boat?
How do I run my cron jobs again? I have no clue which of gazillons of pictures my users uploaded have wrong exif, how do I even find it?

I'm totally fine by this. I'm programming this in my free time which works for my usecases and you can use for free.
My cronjob is starting ever 5 minutes. I don't care if it crashed some time.

You might try to fix the catch block in

} catch (PelException $exception) {

It might help to replace PelException with Exception. I'm happy to review your PR.

@TheBluestBird
Copy link

No, man, I'm sorry, I have a birthday today, and I have wasted it trying to figure out why my people don't see new files. Last place I thought it could be - is the maps app.
There you go, I have added some catches with new kind of exception appeared only in php8, that solved it for me and my cron is running now. If you care about other people cron jobs never been executed because of this silly poop - you should add it yourself
https://www.php.net/manual/en/class.divisionbyzeroerror.php

@tacruc
Copy link
Collaborator

tacruc commented Mar 21, 2021

I'm quite aware of the php docs. Thanks for posting it anyways, have fun on your birthday.

@mxm-tr
Copy link

mxm-tr commented Jul 15, 2022

The issue is still occurring on Maps 0.1.10 in my Nextcloud 24.0.2 install , the line number is now different though

DivisionByZeroError: Division by zero in /var/www/html/apps/maps/lib/Service/PhotofilesService.php:413
Stack trace:
#0 /var/www/html/apps/maps/lib/Service/PhotofilesService.php(264): OCA\Maps\Service\PhotofilesService->getExif(Object(OC\Files\Node\File))
#1 /var/www/html/apps/maps/lib/BackgroundJob/AddPhotoJob.php(56): OCA\Maps\Service\PhotofilesService->addPhotoNow(Object(OC\Files\Node\File), 'mxmtr')
#2 /var/www/html/lib/public/BackgroundJob/Job.php(79): OCA\Maps\BackgroundJob\AddPhotoJob->run(Array)
#3 /var/www/html/lib/public/BackgroundJob/QueuedJob.php(47): OCP\BackgroundJob\Job->execute(Object(OC\BackgroundJob\JobList), Object(OC\Log))
#4 /var/www/html/cron.php(151): OCP\BackgroundJob\QueuedJob->execute(Object(OC\BackgroundJob\JobList), Object(OC\Log))

The line is the following:

$gps[$key] = $temp[0] / $temp[1];

I manually patched it with the code from #648 and the error is gone now, maybe this PR could be merged? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants