This started happening in version 3.5, and my very non-educated Spidey-sense tells me that it may be related to the removal of the “scroll left of zero” option.
I edit a lot of the podcasts I listen to adjust their horrible levels and to remove commercials. When searching for commercials, I click where I think the commercial starts or ends and use the cursor keys to locate the exact position. If I click past (to the right of) the commercial start, I’m unable to use the cursor keys to go left of the point where I clicked. So now I have to err on the side of caution and click more to the left than I think I need to, thus wasting time seeking to the right.
I have no idea what the real purpose of not allowing scrolling left of zero anymore is, but, in my opinion, I’m not trying to scroll left of zero here. Any ideas on what I can do to make it work like it used to?
I don’t think that is related. If it were, then I’d expect the problem would affect everyone (because of it being a design issue), but using the left cursor key works for me.
On the other hand, I have no idea what the purpose of allowing scrolling left of zero was, though I do think it would have been useful to allow the “zero seconds” mark to be offset to the right so as to allow space for a count-in and similar purposes.
I have 3.7.1 and pre-3.5 versions installed. Both have the same key bindings, but the pre-3.5 works as desired.
The problem is not that the the left arrow (short seek left during playback) and down arrow (long seek left during playback) don’t work; they work as long as the playback position/cursor is to the right of the mark (where I clicked). The problem is that once it gets to the mark, it won’t go left anymore, even though I’m in the middle of the track.
Interestingly, the Shift + . shortcut for cursor long jump right works, but Shift + , for cursor long jump left does not work anywhere at all (the , for cursor short jump left works, but is also stopped by the mark where I clicked in 3.7.1).
I misunderstood your first post. I didn’t realise that you meant “during playback”.
The behaviour that you describe was a bug. It was not intended to work that way.
During playback, shifting the play position with cursor keys is supposed to move the play position within the current play region. When there is a selection, the “play region” is the same as the selected region. When there isn’t a selection, the play region is from the cursor position to the end of the project.
The reason for the intended behaviour is so that the selected region does not get inadvertently removed. You should be able to move forward and backwards within the play region without losing the selection. In Audacity 3.3.0 (and some other versions), this is broken, and you can move outside of the play region but in some situations this can cause Audacity to crash, freeze, or lose the selection.
(I’d imagine that it is particularly important for blind users that the selection is not lost).