You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
notes from a conversation a month ago, as best I remember =p
rarely, someone might remap a track (or more rarely, remove) while someone else is listening to it
since remapping/removing a song doesn't push the change to all queues (and this would be undesirable), the change on the back end is invisible, and querying the db before every play means that the change is made visible only when the intended song is replaced without warning/if removed, however we handle the db having no match for it.
our querying the db before every play was originally/mostly? a lazy way to not have to update duplicates on remap, and assumed that the most up-to-date version would be the one desired. this no longer holds, and currently we don't want to do per-user overrides or handling across the shared queue/stashing, internal playlists and such
instead, seeing as the queue already has all of the needed information to create the audio resource and embeds and is more likely to be what the user requested and expects, we will remove the db calls from play. remap/remove will change the db and effect subsequent retrievals, but should otherwise only modify the queue of whoever issued the command.
between or across long sessions, this could result in repeated remaps by either party. it may not be the best user experience, but the incidence is expected to be low, remap permission could be more gated by roles, and we've worked around this somewhat already in our decision to allow for directly linked youtube resources to persist in stashes and internal playlists
The text was updated successfully, but these errors were encountered:
notes from a conversation a month ago, as best I remember =p
rarely, someone might remap a track (or more rarely, remove) while someone else is listening to it
since remapping/removing a song doesn't push the change to all queues (and this would be undesirable), the change on the back end is invisible, and querying the db before every play means that the change is made visible only when the intended song is replaced without warning/if removed, however we handle the db having no match for it.
our querying the db before every play was originally/mostly? a lazy way to not have to update duplicates on remap, and assumed that the most up-to-date version would be the one desired. this no longer holds, and currently we don't want to do per-user overrides or handling across the shared queue/stashing, internal playlists and such
instead, seeing as the queue already has all of the needed information to create the audio resource and embeds and is more likely to be what the user requested and expects, we will remove the db calls from play. remap/remove will change the db and effect subsequent retrievals, but should otherwise only modify the queue of whoever issued the command.
between or across long sessions, this could result in repeated remaps by either party. it may not be the best user experience, but the incidence is expected to be low, remap permission could be more gated by roles, and we've worked around this somewhat already in our decision to allow for directly linked youtube resources to persist in stashes and internal playlists
The text was updated successfully, but these errors were encountered: