* Refactored code; temp disable workflows on push
* remove printf leftovers
* A better sanitizing code
* extend auth routes tests
* more tests, fix 2 bugs in token processing
* more refactoring and fixes
* optimize video mediaURLs DB query and make testCachePath in utils thread-safe
* fix always passing test
* and more refactoring; 1 more test, but cleanup still has to be fixed
* more debug code in the test
* fix the test
* Final commit
* Adding a defer function just in case of panic
* Address some of review comments
* Protect the shared var by mutex; implement correct context-aware scanning
* Better error; better initial func wrap/capture; better log messages in `photos.go`;
* Addressing a few more review comments
* Order the query results; a better error type catch; setting the MP4 content type header explicitly
* try to fix the cancelation detection condition
* Extract a function and call it by name
---------
Co-authored-by: Konstantin Koval
* Handle media not found issue
* temporary run workflows for master pushes only; tests
* revert temp workflow changes
---------
Co-authored-by: Konstantin Koval
* names, constants of reusable strings, removed unneeded `if`, replaced deprecated imports
* more deprecated imports replaced
* What is this?))
* Fix a path and quote a var in Dockerfile
* Addressing review comments
---------
Co-authored-by: Konstantin Koval <kkb@ukr.net>
I encountered with the following error:
> 2023/02/05 07:33:00 /app/scanner/face_detection/face_detector.go:92 sql: transaction has already been committed or rolled back
> [0.042ms] [rows:0] SELECT * FROM `media` WHERE `media`.`id` = 823 ORDER BY `media`.`id` LIMIT 1
> 2023/02/05 07:33:00 ERROR: Error detecting faces in image (/photos/Borzsony2017/DSC_0028.NEF): sql: transaction has already been committed or rolled back
It turned out it comes from the api/routes/photos.go
I found a very similar code in album_scanner.go.
The difference I saw was that while in the single photo request the
transaction passed to the `scanner_tasks.Tasks.BeforeProcessMedia` call,
in the album_scann.go the transaction created after this call and
created from the context which returned by `BeforeProcessMedia`.
Another difference was that in the `ProcessSingleMedia` call the
`AfterProcessMedia` call was called with the same - db transaction -
context, in the album_scanner it was called outside of the transaction.
I changed the logic by merging the two behavior:
Create the transaction from the context of `BeforeProcessMedia` and also
use the transaction context in the `AfterProcessMedia`.
After the change the error disappeared.
So to have it in a common place I extracted that logic into a function
and use for both the single photo request and in the album scanner.
I did not go more deeper to find out what's going on with the context
under the hood.
if the argument is a model. This ensures that the proper gorm hooks are
called which was causing the full screen view on the Places page to
crash.
Also fixed a bug in Messages.js that caused a crash.
This replaces the current implementation
where a bearer header holds the auth-token.
Now the same token is being sent using a cookie instead.
This greatly simplifies fetching resources (images and video),
since the header is sent along implicitly with each request.
To prepare for video support
Migrate database rename tables and columns:
- photo to media
- photo_url to media_url
- photo_exif to media_exif
- Update api accordingly
