Bugzilla – Bug 8931
Presets should be Per Player
Last modified: 2009-09-08 09:22:00 UTC
This was discussed a while ago on the forums, but I don't think a bug was ever opened... Since multiple Booms will likely be used by different users in different rooms of the house, they should be able to have different presets. Perhaps there should be a pref to select either per-player presets or favs as presets.
Related to bug 4528
The Presets should be a per-player Preference, where the Favorites should be a per-server (account) preference
I agree, James. One Boom's presets shouldn't affect others. I'd like to consider for 7.2.1
could we consider starting by breaking "presets" away from "hotkeys". Right now, it seems as if preset1 is the same as favorite1. then maybe it can then be reworked to create a <playerid>-preset.opml file for presets, distinct from the favorites.opml currently used. not sure currently how this impacts the favorites class.
Consensus is that hotkeys and presets should be the same thing, and should be per-player.
It makes Dean cry, but Michael wins the argument that we should fix it right for 7.3 instead of put a hack for 7.2.1 Triode, Dean suggests you might be willing to have a look at this? Let us know if not.
Well hotkey = presets in my mind. It would be relatively simple to have a per player favorite opml file and hence have favorites and preset be per player (we could have a pref to select this). Reason is the api already includes a client param in case we wanted to do it. What would be more work would be to keep favorites as a single list and have presets per player. So would a pref which allowed per player favorites and preset be acceptable?
Dean can you please comment? Thanks.
Yes, hotkey = presets. And these should be specific to a player. It's a good question whether favorites are per-player or per server. Brandon is working on adding the notion of users to the DB, and I'd say that Favorites are per user (while presets remain per-player). For now, we only have the one, default, user.
Ok - but that sounds like it is moving away from the whole concept of opml files to store user's radio stations and the idea of linked opml files as we have with alien and picks, wiki radio so that you can add an opml link in favorites to a remote opml feed? I'm happy to add the code to make the current solution per player and selectable. Per user sounds like it is worth discussing a lot more first as it needs to support into the architecture of opml or not. I had hoped we would be able to share opml favorites with SN for radio stations in the near future?
I almost feel like the presets are a separate list from the favorites, but when you save a preset, you also save a favorite. OPML would be fine as a storage format.
ok - sounds like there's no point allowing per player favorites&presets then which is what could be done in the short term.
bug 4528 related
So is 7.3 still a reasonable target for this, or should we wait for the new schema work to get more stable before trying to target this? Or what? Triode, does Dean's direction make sense to you, or does it need more clarity?
Dean, for your decision-making use, Michael notes that the presets and favorites really badly need an overhaul, and he hates to see us spending time on a feature which is broken.
should be covered by bug 9150
I imagine there will also be some UI design decisions that will be intertwined with this when user profiles are implemented. For example, maybe presets should really be per-user and there should then be some way to associate a user profile with a player. Maybe...
I won't comment on how badly broken the current implementation is :) What I will say is that we need a clearly defined set of requirement for any new solution. I do think that having separate presets and favorites and one of them being per user and the other per player probably requires more thought and clearly including in the requirements. No coding can start until the per user mechanisms are documented either... The original reason for merging a hierachical list of radio stations into favorites was to have single repository for "favorites" which could be shared with SN. We need to include this in the requirement for the new solution too.
closing as dupe, as Triode's right: this must be prepared by a clear design specification. Which is bug 9510. *** This bug has been marked as a duplicate of bug 9510 ***
Oops, sorry for the type. Dupe of 9150. *** This bug has been marked as a duplicate of bug 9150 ***
Reduce number of active targets for SC