starred/koel-koel

Fork 0

mirror of https://github.com/koel/koel.git synced 2026-04-25 08:46:00 +03:00

[GH-ISSUE #617] koel:sync is slow #441

New issue

Closed

opened 2026-02-26 02:33:13 +03:00 by kerem · 5 comments

kerem commented

2026-02-26 02:33:13 +03:00

Owner

Originally created by @alashow on GitHub (Jul 1, 2017).
Original GitHub issue: https://github.com/koel/koel/issues/617

I installed Koel from the master branch.
I have +170000 mp3s in my storage. When I run koel:sync, some mp3s take more than a minute, some of them a little bit faster, and others sync as fast as it looks like it's skipped.

I was watching it, and it went like this:
215/174517 - ~1 minute
216/174517 - ~40 seconds
217/174517 - ~30 seconds and then jumped to 221

Example screencast

Originally created by @alashow on GitHub (Jul 1, 2017). Original GitHub issue: https://github.com/koel/koel/issues/617 I installed Koel from the master branch. I have +170000 mp3s in my storage. When I run `koel:sync`, some mp3s take more than a minute, some of them a little bit faster, and others sync as fast as it looks like it's skipped. I was watching it, and it went like this: 215/174517 - ~1 minute 216/174517 - ~40 seconds 217/174517 - ~30 seconds and then jumped to 221 [Example screencast](https://drive.google.com/open?id=0B5up2CgQawSDVlJISVNKaWxobVU)

kerem closed this issue

2026-02-26 02:33:13 +03:00

kerem commented

2026-02-26 02:33:13 +03:00

Author

Owner

@phanan commented on GitHub (Jul 2, 2017):

Koel doesn't handle mp3 tag reading (which is the essential part of syncing), but relies on getID3 for it. From my understanding, getID3's reading speed mostly depends on the mp3 file's binary structure, whether they have tag errors, then your system's performance, and so on. Basically there's not much Koel can do in this case.

@phanan commented on GitHub (Jul 2, 2017): Koel doesn't handle mp3 tag reading (which is the essential part of syncing), but relies on getID3 for it. From my understanding, getID3's reading speed mostly depends on the mp3 file's binary structure, whether they have tag errors, then your system's performance, and so on. Basically there's not much Koel can do in this case.

kerem commented

2026-02-26 02:33:13 +03:00

Author

Owner

@alashow commented on GitHub (Jul 2, 2017):

I don't think it's my system's performance issue. It's dedicated server hosted by Hetzner (EX41S-SSD).
Although, my files are located in a storage box, which is also hosted by Hetzner, in the same data center. But the speed is not that bad to process one mp3 file for 40+ seconds).

$ dd if=/dev/zero of=/storage/ethen/file bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.6508 s, 57.6 MB/s

I will try to debug it in my free time to find out the issue.

@alashow commented on GitHub (Jul 2, 2017): I don't think it's my system's performance issue. It's dedicated server hosted by Hetzner ([EX41S-SSD](https://www.hetzner.com/dedicated-rootserver/ex41s-ssd)). Although, my files are located in a storage box, which is also hosted by Hetzner, in the same data center. But the speed is not that bad to process one mp3 file for 40+ seconds). ```bash $ dd if=/dev/zero of=/storage/ethen/file bs=1G count=1 oflag=direct 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.6508 s, 57.6 MB/s ``` I will try to debug it in my free time to find out the issue.

kerem commented

2026-02-26 02:33:13 +03:00

Author

Owner

@phanan commented on GitHub (Jul 2, 2017):

If the files are stored in a separated box (albeit in the same data
center), then the speed may suffer, too.

On Sun, Jul 2, 2017 at 7:21 PM, Alashow notifications@github.com wrote:

I don't think it's my system's performance issue. It's dedicated server
hosted by Hetzner (EX41S-SSD
https://www.hetzner.com/dedicated-rootserver/ex41s-ssd).
Although, my files are located in a storage box, which is also hosted by
Hetzner, in the same data center. But the speed is not that bad to process
one mp3 file for 40+ seconds).

$ dd if=/dev/zero of=/storage/ethen/file bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.6508 s, 57.6 MB/s

I will try to debug it in my free time, to see what's issue.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/phanan/koel/issues/617#issuecomment-312508187, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHrt0iI8HKI-AgfREieDixf_EBRB88Uuks5sJ9-NgaJpZM4OLW8Y
.

@phanan commented on GitHub (Jul 2, 2017): If the files are stored in a separated box (albeit in the same data center), then the speed may suffer, too. On Sun, Jul 2, 2017 at 7:21 PM, Alashow <notifications@github.com> wrote: > I don't think it's my system's performance issue. It's dedicated server > hosted by Hetzner (EX41S-SSD > <https://www.hetzner.com/dedicated-rootserver/ex41s-ssd>). > Although, my files are located in a storage box, which is also hosted by > Hetzner, in the same data center. But the speed is not that bad to process > one mp3 file for 40+ seconds). > > $ dd if=/dev/zero of=/storage/ethen/file bs=1G count=1 oflag=direct > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.6508 s, 57.6 MB/s > > I will try to debug it in my free time, to see what's issue. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <https://github.com/phanan/koel/issues/617#issuecomment-312508187>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AHrt0iI8HKI-AgfREieDixf_EBRB88Uuks5sJ9-NgaJpZM4OLW8Y> > . >

kerem commented

2026-02-26 02:33:13 +03:00

Author

Owner

@alashow commented on GitHub (Jul 2, 2017):

Yeah, that i/o speed test result with dd from above is the actual speed.

@alashow commented on GitHub (Jul 2, 2017): Yeah, that i/o speed test result with `dd` from above is the actual speed.

kerem commented

2026-02-26 02:33:13 +03:00

Author

Owner

@gerroon commented on GitHub (Jun 3, 2018):

I have this issue with v3.7.2 :(

I just created a a fresh database and it only synched 27000 songs out of 62000 in 14 hours :( It is still going on and has waysss to go.

I am using Koel on Debian Testing with MariaDb. Both drives (installation and music) are on the same system. MariaDb is on an SSD drive while music is on a usb3 drive.

@gerroon commented on GitHub (Jun 3, 2018): I have this issue with v3.7.2 :( I just created a a fresh database and it only synched 27000 songs out of 62000 in 14 hours :( It is still going on and has waysss to go. I am using Koel on Debian Testing with MariaDb. Both drives (installation and music) are on the same system. MariaDb is on an SSD drive while music is on a usb3 drive.

kerem referenced this issue

2026-02-26 03:30:20 +03:00

[PR #441] [MERGED] Password hashing. #1254

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/koel-koel#441

No description provided.

Rows
Columns