starred/koel-koel

Fork 0

mirror of https://github.com/koel/koel.git synced 2026-04-25 16:56:02 +03:00

[GH-ISSUE #347] [Feature] Allow download #252

New issue

Closed

opened 2026-02-26 02:32:35 +03:00 by kerem · 9 comments

kerem commented

2026-02-26 02:32:35 +03:00

Owner

Originally created by @phanan on GitHub (Jun 2, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/347

Even though Koel is meant to solve the local media storage issue, it might be good if users can download individual songs, an album, or a whole playlist from time to time.

Originally created by @phanan on GitHub (Jun 2, 2016). Original GitHub issue: https://github.com/koel/koel/issues/347 Even though Koel is meant to solve the local media storage issue, it might be good if users can download individual songs, an album, or a whole playlist from time to time.

kerem closed this issue

2026-02-26 02:32:35 +03:00

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@alex-phillips commented on GitHub (Jun 2, 2016):

I think this is a great idea.

A couple of things to consider:

multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file.
Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint.

@alex-phillips commented on GitHub (Jun 2, 2016): I think this is a great idea. A couple of things to consider: 1. multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file. 2. Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@fatryst commented on GitHub (Jun 2, 2016):

？

发自我的 iPhone

在 2016年6月2日，20:51，Alex Phillips notifications@github.com 写道：

I think this is a great idea.

A couple of things to consider:

multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file.
Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@fatryst commented on GitHub (Jun 2, 2016): ？发自我的 iPhone > 在 2016年6月2日，20:51，Alex Phillips notifications@github.com 写道： > > I think this is a great idea. > > A couple of things to consider: > > multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file. > Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint. > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@phanan commented on GitHub (Jun 2, 2016):

multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file.

Exactly that.

Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint.

Actually on a mobile device (at least on iOS), you can't download anything – a media "download" will just open the native media player. So, I'll just hide the download controls away.

@phanan commented on GitHub (Jun 2, 2016): > multi-song download could (optionally?) be zipped up before download, whereas single songs could just send down the raw song file. Exactly that. > Might be worth adding support to transcode song files (such as FLAC) before downloading. I think this would be useful in the event that if you wanted to download the songs to load up on a mobile device - not only would the mobile device potentially not support some formats, but smaller files are better from a storage standpoint. Actually on a mobile device (at least on iOS), you can't download anything – a media "download" will just open the native media player. So, I'll just hide the download controls away.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@alex-phillips commented on GitHub (Jun 2, 2016):

Sorry, I meant that if you downloaded via your computer and wanted to transfer them over. Not download directly on the device.

Like say you wanted to load them onto your iPhone's iTunes player for offline playback.

@alex-phillips commented on GitHub (Jun 2, 2016): Sorry, I meant that if you downloaded via your computer and wanted to transfer them over. Not download directly on the device. Like say you wanted to load them onto your iPhone's iTunes player for offline playback.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Jun 2, 2016):

Things I believe should be considered...

It should be optional, meaning that the Admin should be able to disable downloading altogether [although without the feature you can still download if you know how to, I think some might not want it directly available] .
Since Koel does not modify metadata directly to the files we should consider that when downloading the songs through Koel it should downloaded with the metadata in Koel.
I agree with @alex-phillips that transcoding should be available.

@BernardGoldberger commented on GitHub (Jun 2, 2016): Things I believe should be considered... 1. It should be optional, meaning that the Admin should be able to disable downloading altogether [although without the feature you can still download if you know how to, I think some might not want it directly available] . 2. Since Koel does not modify metadata directly to the files we should consider that when downloading the songs through Koel it should downloaded with the metadata in Koel. 3. I agree with @alex-phillips that transcoding should be available.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@phanan commented on GitHub (Jun 3, 2016):

It will be optional.
This is to be considered, but I'm more on the "no" side. Rule of thumb: Koel doesn't modify the original files.
Transcoding for download will not be available. If the users want to convert their FLACs, they can do it themselves.

@phanan commented on GitHub (Jun 3, 2016): 1. It will be optional. 2. This is to be considered, but I'm more on the "no" side. Rule of thumb: Koel doesn't modify the original files. 3. Transcoding for download will not be available. If the users want to convert their FLACs, they can do it themselves.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Jun 3, 2016):

In regards to item 2 I was referring to the file being downloaded not original, maybe it could be done by creating a temp copy and writing out the metadata.

@BernardGoldberger commented on GitHub (Jun 3, 2016): In regards to item 2 I was referring to the file being downloaded not original, maybe it could be done by creating a temp copy and writing out the metadata.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@phanan commented on GitHub (Jun 3, 2016):

Come to think about it, there's no easy way to tell if the metadata has been changed. Top of my head, we can:

Apply the metadata writing procedure to ALL songs and just attempt to write regardless (bad approach).
Compare a song record's data with its original state to determine (unnecessary IO/CPU/RAM/server fan – not much better).
Compare a song record's updated_at and created_at value. If they're different from each other, we assume that the song's metadata have been changed. I use the word "assume," because there are other actions that change updated_at value as well (slightly better approach).

As you can see, none of the approaches is optimal. Also, getID3's writing is not really up to the game. From the official homepage:

getID3() can write (some formats are only partially supported and/or buggy, use with caution):
ID3v1 (v1 & v1.1)
ID3v2 (v2.3, v2.4)
APE (v2)
Ogg Vorbis comments
FLAC comments

Looking at the offical demo code, you'll find quite a few edge cases / hacks / workarounds, and the effort is undoubtedly not worth it.

So still, I'm on the "no" side.

@phanan commented on GitHub (Jun 3, 2016): Come to think about it, there's no easy way to tell if the metadata has been changed. Top of my head, we can: - Apply the metadata writing procedure to ALL songs and just attempt to write regardless (bad approach). - Compare a song record's data with its original state to determine (unnecessary IO/CPU/RAM/server fan – not much better). - Compare a song record's `updated_at` and `created_at` value. If they're different from each other, we _assume_ that the song's metadata have been changed. I use the word "assume," because there are other actions that change `updated_at` value as well (slightly better approach). As you can see, none of the approaches is optimal. Also, getID3's _writing_ is not really up to the game. From [the official homepage](http://getid3.sourceforge.net/): > getID3() can write (some formats are only partially supported and/or buggy, use with caution): > ID3v1 (v1 & v1.1) > ID3v2 (v2.3, v2.4) > APE (v2) > Ogg Vorbis comments > FLAC comments Looking at the [offical demo code](http://getid3.sourceforge.net/source/?p=demo.write.phps), you'll find quite a few edge cases / hacks / workarounds, and the effort is undoubtedly not worth it. So still, I'm on the "no" side.

kerem commented

2026-02-26 02:32:35 +03:00

Author

Owner

@phanan commented on GitHub (Jun 5, 2016):

Done with e334ec20d6.

@phanan commented on GitHub (Jun 5, 2016): Done with e334ec20d6ca48d8f76b63e6a5299285badb037f.

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#252

No description provided.

Rows
Columns