mirror of
https://github.com/koel/koel.git
synced 2026-04-26 17:25:59 +03:00
[GH-ISSUE #425] Koel:sync --force always Killed at 50% #302
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#302
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 @Porco-Rosso on GitHub (Aug 25, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/425
Hey, thanks for contributing to Koel! To save time for both of us, please make sure these checkboxes are checked before submitting the issue:
All checked? Now also make sure your issue
Hi! Once again great project.
I recently logged in to my koel install after updating to the newest version and noticed the album art was missing.
I found that running
php artisan koel:sync --forcerepopulated the saved images, and I no longer got 404 errors in the browser.However, when executing the sync with the --force trigger the scan gets killed at exactly 50%
Running a normal scan completes without errors, but does not restore the images.
Running another forced resync always gets killed at the same point and so I can't progress.
Any idea what might be causing this?
I am running Debian 8, with the latest version of Koel.
@BernardGoldberger commented on GitHub (Aug 25, 2016):
To start with check the
storage/logs/laravel.log, you can also runphp artisan koel:sync -v --forceso that it logs to the console.@Porco-Rosso commented on GitHub (Aug 25, 2016):
Adding the -v switch gives no additional information, only that the scan died 12 minutes in.
here is the laravel.log, but from what I can see it has no relation.
@BernardGoldberger commented on GitHub (Aug 25, 2016):
One of the differences when running with
--forceis that it uses more memory, try to increase thememory_limitand see if it changes anything.@BernardGoldberger commented on GitHub (Aug 25, 2016):
Have a look here
@Porco-Rosso commented on GitHub (Aug 25, 2016):
yup, that turned out to be the problem!
Upped the RAM and Swap temporarily on the VM and gave it another shot.
Didn't post as I was waiting to see if the scan would complete, and it did.
Thanks for the help @bdgold !
@Porco-Rosso commented on GitHub (Aug 25, 2016):
Actually although the scan worked. I still get missing errors for some of the artwork (404).
Is there a way to regenerate the thumbnails? (newly added tracks display proper artwork)
@BernardGoldberger commented on GitHub (Aug 25, 2016):
php artisan koel:sync --force --tags=cover@Porco-Rosso commented on GitHub (Aug 26, 2016):
Sorry to comment, but
--force --tags=coverstill didn't do it. I still have many missing images@phanan commented on GitHub (Aug 26, 2016):
Hmm. Actually
php artisan koel:sync --force --tags=covershouldn't fix your problem. I'm not sure what went wrong honestly. Is it an option to empty the database and start from scratch, given that you've just installed Koel?@Porco-Rosso commented on GitHub (Aug 26, 2016):
I've had it installed for some time. But yes, I can empty the database.
Is there a way to just clear the songs from the database? I rather not have to re-setup the user accounts.
@phanan commented on GitHub (Aug 26, 2016):
In such a case then no, don't empty the database, but maybe try another installation elsewhere and see if the covers are there. Again, I don't know the cause of your problem (yet), so am just suggesting here.
@BernardGoldberger commented on GitHub (Aug 26, 2016):
I was able to reproduce it by simply deleting one of the cover files from
/public/img/covers/, now no matter what I have done it wont regenerate.@phanan commented on GitHub (Aug 26, 2016):
It might be a bug, but why would Koel (assuming it's Koel) delete a cover from the first place?
@BernardGoldberger commented on GitHub (Aug 26, 2016):
It happened to me a while ago when I reinstalled Koel and exported the DB but not the public/img folder, I ended up restoring from a backup.
@Porto-Rosso can you check the image file name in the DB for and album that gives a 404, then go to public/img/covers and check if the file exists or not.
@Porco-Rosso commented on GitHub (Aug 27, 2016):
@bdgold So I checked which albums are giving 404 errors.
Most (but not all) missing images begin with
56XXXXX.XXXXXX.png, however in mypublic/img/coversall the filenames begin with57XXXXX.XXXXXX.png@BernardGoldberger commented on GitHub (Aug 28, 2016):
@Porco-Rosso that confirms that the images are indeed gone, the question now as @phanan pointed out is, why?
Do you remember doing what I did https://github.com/phanan/koel/issues/425#issuecomment-242772433? Maybe there is something else you did that can try to replicate?
@Porco-Rosso commented on GitHub (Aug 29, 2016):
Besides running the scan multiple times, and the process getting killed due to limited RAM no.
My suspicions are that whatever happened occurred during the updating process of Koel.
Seeing as I am having other minor issues with Koel (not being able to get a login cookie when using a reverse proxy) I think at this point I might just save myself some time by reinstalling everything from scratch.