Skip to content

Conversation

@sighops
Copy link

@sighops sighops commented Aug 14, 2025

Issue

Negative values are allowed for the Run Starts At time in the component settings. However, when that value gets formatted and saved into the layout XML, the dash character that a user types with their keyboard is converted into a minus character. When reloading the layout after save, the offset time is set to 0.0 instead of the saved negative value.

Implementation

The current regex allows a dash character but not a minus character, though the TimeFormatter converts the dash into a minus. Updated the regex pattern to use the MINUS and DASH constants defined in LiveSplit to allow both characters in an offset string.

Testing

I built and tested this component myself and verified it works as intended. Entering a negative offset value from my keyboard, which inputs a dash, is saved as expected and loads correctly when the layout is loaded. The video also starts at the correct offset. Also, I manually edited the layout xml to test both minus and dash characters in the offset string are loaded correctly and the video starts at the correct offset in both cases.

@wooferzfg
Copy link
Member

What does a negative value do with the video? How do you start the video at a negative time?

@sighops
Copy link
Author

sighops commented Aug 14, 2025

So for my use case I have a PB video that's trimmed a few frames too short and I'm putting in -0.10 to introduce a small playback delay. Maybe that's unintended behavior, but it works for me except for loading the saved settings from the layout xml. After looking through the code and seeing that original regex, it seemed to me like there was intent to allow negative values for a delay so then I made this PR. Let me know if there are other concerns that should be considered though, I only started using this component last night.

@sighops
Copy link
Author

sighops commented Aug 18, 2025

Had some time to look at this more, and leaning towards closing this PR. I think the delay just so happens to work because of the current logic in the SynchronizeTimer event. Large values cause the video to continuously restart for the equivalent time period(i.e -5.0 causes restarts for 5 seconds) before playback continues as normal.

Seems like a more robust feature to support delay more cleanly would be ideal. I could make a feature request and work on that when I find some time if that sounds ok to you. Sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants