starred/koel-koel

Fork 0

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

[GH-ISSUE #389] [REQUEST] Per-user media library (or multiple media path) #285

New issue

Closed

opened 2026-02-26 02:32:40 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @X-Ryl669 on GitHub (Aug 1, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/389

Would it be possible to handle multiple media path (instead of a single path), and better to assert some permissions for each path ?

Basically, I've installed Koel on a NAS that's serving music folder for all my users (they are all different). There is a common music folder where the "most compatible" songs are stored.

Ideally, I would like to set up Koel on the "common" folder (that's accessible for all) and each user would also be granted access to his own music folder.

Right now, I can do that with symlinks in the common folder back to the users' folders, but it's not very clean (and I need as many symlinks as there are users, and to allow www-data to access their directory for reading)...

Originally created by @X-Ryl669 on GitHub (Aug 1, 2016). Original GitHub issue: https://github.com/koel/koel/issues/389 Would it be possible to handle multiple media path (instead of a single path), and better to assert some permissions for each path ? Basically, I've installed Koel on a NAS that's serving music folder for all my users (they are all different). There is a common music folder where the "most compatible" songs are stored. Ideally, I would like to set up Koel on the "common" folder (that's accessible for all) and each user would also be granted access to his own music folder. Right now, I can do that with symlinks in the common folder back to the users' folders, but it's not very clean (and I need as many symlinks as there are users, and to allow www-data to access their directory for reading)...

kerem closed this issue

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

kerem commented

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

Author

Owner

@X-Ryl669 commented on GitHub (Aug 10, 2016):

Oh, by the way, Koel's sync does not follow links initially, so this patch add the feature:

diff --git a/app/Services/Media.php b/app/Services/Media.php
index 7c35975..4d992a9 100644
--- a/app/Services/Media.php
+++ b/app/Services/Media.php
@@ -113,6 +113,7 @@ class Media
         return Finder::create()
             ->ignoreUnreadableDirs()
             ->files()
+            ->followLinks()
             ->name('/\.(mp3|ogg|m4a|flac)$/i')
             ->in($path);
     }

@X-Ryl669 commented on GitHub (Aug 10, 2016): Oh, by the way, Koel's sync does not follow links initially, so this patch add the feature: ``` diff --git a/app/Services/Media.php b/app/Services/Media.php index 7c35975..4d992a9 100644 --- a/app/Services/Media.php +++ b/app/Services/Media.php @@ -113,6 +113,7 @@ class Media return Finder::create() ->ignoreUnreadableDirs() ->files() + ->followLinks() ->name('/\.(mp3|ogg|m4a|flac)$/i') ->in($path); } ```

kerem commented

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

Author

Owner

@X-Ryl669 commented on GitHub (Aug 17, 2016):

Here's how I intend to do it.
Unfortunately, this is going to change the database format a bit.
Right now, there is a single media path, that's stored in the "settings" table as a php's serialized value.
I don't think it's good to store PHP serialization in a DB field, so it should be changed anyway.
The idea would be to change the format of this table from:

CREATE TABLE `settings` (
  `key` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `value` text COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE TABLE `settings` (
  `key` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `value` text COLLATE utf8_unicode_ci NOT NULL,
  `user_id` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`key`)
  KEY `user_id_foreign` (`user_id`),
  CONSTRAINT `user_id_foreign` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

This way, we can link a setting to a user (NULL for 'all users').
Then in the interface, we select the music path from the user current logged in for sync'ing (and all the music path that are common).

A change is also required for the songs themselves in the same style so each song is attached a user ID.

What do you think, is the the right way to start ?

@X-Ryl669 commented on GitHub (Aug 17, 2016): Here's how I intend to do it. Unfortunately, this is going to change the database format a bit. Right now, there is a single media path, that's stored in the "settings" table as a php's serialized value. I don't think it's good to store PHP serialization in a DB field, so it should be changed anyway. The idea would be to change the format of this table from: ``` CREATE TABLE `settings` ( `key` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `value` text COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (`key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ``` to ``` CREATE TABLE `settings` ( `key` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `value` text COLLATE utf8_unicode_ci NOT NULL, `user_id` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`key`) KEY `user_id_foreign` (`user_id`), CONSTRAINT `user_id_foreign` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ``` This way, we can link a setting to a user (NULL for 'all users'). Then in the interface, we select the music path from the user current logged in for sync'ing (and all the music path that are common). A change is also required for the songs themselves in the same style so each song is attached a user ID. What do you think, is the the right way to start ?

kerem commented

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

Author

Owner

@phanan commented on GitHub (Aug 18, 2016):

I have no plan to support this, at least not in the foreseeable future. Btw:

I don't think it's good to store PHP serialization in a DB field, so it should be changed anyway.

You're entitled to your opinions, but the technique is very commonly seen (e.g. WordPress). There's no good or bad here, it depends on what we want to do with the field. Until JSON data type is more widely supported, I'll stick with the current approach. Thanks.

@phanan commented on GitHub (Aug 18, 2016): I have no plan to support this, at least not in the foreseeable future. Btw: > I don't think it's good to store PHP serialization in a DB field, so it should be changed anyway. You're entitled to your opinions, but the technique is very commonly seen (e.g. WordPress). There's no good or bad here, it depends on what we want to do with the field. Until JSON data type is more widely supported, I'll stick with the current approach. Thanks.

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

No description provided.

Rows
Columns