I agree this seems weird, but that makes me wonder why it's there in the first place. I've kind of lost track of the quartz interfaces; can you write a test for this? E.g. Set two positions near each other and Get to verify it changed. I also noticed MPEGSplitter_seek and AVISplitter_seek have similar code. I think writing a test for one and duplicating that logic in the others would be fine. Andrew On Sun, Sep 23, 2018 at 02:22:26PM -0600, Alex Henrie wrote:
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=34302 Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- For some reason, the game sets the audio stream position to a negative value, then seeks to 0. If Wine decides that it doesn't actually need to do the seek operation, it then reads garbage data from the negative offset.
Unfortunately, there is still another bug with the audio in this game: Wine keeps reading past the end of the audio stream, causing a crash at the end of the audio clip. --- dlls/quartz/waveparser.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/dlls/quartz/waveparser.c b/dlls/quartz/waveparser.c index fa9cd45d27..995e43196d 100644 --- a/dlls/quartz/waveparser.c +++ b/dlls/quartz/waveparser.c @@ -211,10 +211,9 @@ static HRESULT WINAPI WAVEParserImpl_seek(IMediaSeeking *iface) return E_INVALIDARG; }
- if (curpos/1000000 == newpos/1000000) + if (curpos == newpos) { - TRACE("Requesting position %s same as current position %s\n", - wine_dbgstr_longlong(newpos), wine_dbgstr_longlong(curpos)); + TRACE("Requesting position %s same as current position\n", wine_dbgstr_longlong(newpos)); return S_OK; }
-- 2.19.0