mirror of
https://github.com/koel/koel.git
synced 2026-04-25 08:46:00 +03:00
[GH-ISSUE #636] Postgres error while syncing: invalid byte sequence for encoding "UTF8" #455
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#455
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @svalo on GitHub (Aug 18, 2017).
Original GitHub issue: https://github.com/koel/koel/issues/636
Hello, I'm encounering some issues while using postgres with koel, tryied with mariadb and did not have problems.
I'm not sure whether this is an issue with koel itself or not.
OS: archlinux
Postgres version:9.6.3
MariaDB version:10.1.26-MariaDB
Php version: 7.1.8
Koel is configured using php-fpm + nginx
Issue is:
While scanning koel excepts and dies with errors like
and
Checking the entry which caused the first error in MySQL db results in:
and similarly for the second error
The characters are somehow accepted.
If it's not possible to sanitize in some way the characters it would be nice not to exit due to the exception as this results in failing to scan the rest of the library.
Thanks for the nice work!
@djelic commented on GitHub (Sep 7, 2017):
Tripped on this one too, solved by wrapping fetching
$lyricsinutf8_encodehere app/Models/File.php.Not sure if it is the best solution but I agree that sync should not fail because of single track.
@phanan commented on GitHub (Dec 29, 2023):
Each scan is wrapped in a try//catch now.