"Image Slide Show" source's "Randomize Playback" option doesn't affect "next slide" hotkey

[nivomi]

trafficstars

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

27.2.4

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/C8qf7kqu82Xz5l3G

OBS Studio Crash Log URL

No response

Expected Behavior

When using "Randomize Playback", it should be possible to manually advance slides while still randomizing their order. I expected this to be the existing behaviour when using the "next slide" hotkey.

Current Behavior

The "next slide" hotkey is unaffected by the "randomize playback" option and causes the slideshow to proceed to the next slide in the default, unrandomized order.

Steps to Reproduce

1. Create an Image Slide Show source
2. Add several images to it
3. Select the "Randomize Playback" checkbox
4. Under Settings > Hotkeys, assign the source a hotkey for the "next slide" action
5. Press the hotkey a few times, observing that it proceeds to the next image in the default order, not randomized.

Anything else we should know?

This may be a circumstance where adding a new, separate "random slide" hotkey would be better than changing the existing behaviour, but I think that having this be possible, one way or another, makes sense. If you can shuffle while playing a slideshow on a timer, you should be able to shuffle it while advancing it manually, right?

[gxalpha]

Can confirm this behaviour with the context bar controls (internally, they do the same as the hotkey).

This issue poses an interesting UX question: What should the "previous" button do? For "next" it's pretty clear that a random new slide should be selected (not through a separate hotkey or something, I think this is what the "next" hotkey should do by default). The correct UX for "previous" would likely be to go back to the previous slide. However, we don't store the order of these, and I feel like that might be overkill for a simple control like this. This will make solving this more complicated than it should be, because the only thing worse than the "next" button behaving in a way the user wouldn't expect is the "previous" button working differently than the "next" button.

This probably needs more UX discussion.

[nivomi]

I definitely agree that there's multiple ways this problem could be solved, and that this merits some planning ahead and discussing the UX implications. It's an interesting problem.

I often try to look at how other people solve similar problems to see what behaviour users might be expecting. If we look at shuffle behaviour in things like music players, there's not quite a consensus.

Many applications return to the previous item in the 'shuffle order' (i.e. the song that was being listened to before 'next' was pressed, or before the song ended and advanced to the next one). However, as you've said, this would require keeping a shuffled version of the list in memory instead of just proceeding to a random item each time, which I think might be why other applications just do a naive "back one step in the unshuffled ordered list".

This is part of why I thought that a 'random slide' hotkey option could be an alternative worth considering. This would side-step the issue of having to consider what changes to make to the 'next item' and 'previous item' keybind functions, and would also side-step any concerns about whether existing users might be relying on the current behaviour.

This also isn't quite ideal, though, for the reason you've mentioned - intuitively, it feels like "next" should mean the same thing as "the slideshow advances on its own".

Also, for reference: at the moment, I'm using a workaround where I have the slideshow set to a very small delay, and I just unpause it and then pause it again to shuffle out a new result.

[tuduweb]

does this issue need to fix (or enhance)? i'd like to do some work for this issue. @gxalpha

[gxalpha]

I don't think this had any in-depth discussion yet. You're always welcome to PR changes, but keep in mind that there's the chance of them getting rejected.

[RytoEX]

I believe this was actually implemented in #3450. Please retest in OBS Studio 29 Beta 2 (or newer).

[cg2121]

I can confirm #3450, does fix this issue.