* 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.
* Fixesviktorstrate/photoview#8
- Added new property CounterpartPath to Media struct to hold the path to the counterpart JPEG file (if any)
- Added new MediaType method isBasicSupportedisBasicTypeSupported()
- Added new function isFileExists() to minimize the code duplication
* Fixesviktorstrate/photoview#8
- Chaned CounterpartPath definition from string to *string
- Added new helper method FileExtensions()
- Simplified the logic inside scanForRawCounterpartFile() and scanForCompressedCounterpartFile() functions, reducing the code duplication
* Fixesviktorstrate/photoview#8
- Added debug to fileExists() function
* Cleanup fileExists logging
Co-authored-by: viktorstrate <viktorstrate@gmail.com>
