Devices > Video Cards, Monitors, Televisions, and Projectors
Bump - Support Request: Playback engine command 28038 cleanup / enhancements
tij:
so ... using "I" key works? ... maybe automate around that in combination with Playback Info field and command 28038 ... for example use 28038 to closest known good value then send predetermined number of "I" keystrokes to MC to fine tune.
I know its not an elegant solution but at least it might work
--- Quote from: Movieman on July 02, 2020, 09:49:57 am ---I suspect it won't and the resulting playback will be at an incorrect 102% zoom.
--- End quote ---
also its always better to confirm a problem rather speculate over it. Speculation wont get much attention.
Movieman:
--- Quote ---I know its not an elegant solution but at least it might work
--- End quote ---
I'm not looking for something that "might work". GIGO (garbage in garbage out) means that you can't create a solution when the input data is possibly invalid.
I have been a JRiver user since version 19 and have always paid for my upgrades.
I'm looking for an acknowledgement that this is a bug in the zoom implementation, which it clearly is when at least two different zoom values 102% and 103% store the same value in the playback info data.
I'm sure this same behavior exists for many other zoom values as well, and is affecting the consistency of zoom when a title that has been played is replayed, since it depends on the playback info data which has been generated (incorrectly) previously.
It seems to me that I have invested a fair share of effort debugging this issue and providing data to explain why it's happening. Since JRiver is a paid software product, it also seems reasonable to me that JRiver acknowledges that it is a bug and fixes it.
Thanks in advance, hoping to see a fix soon . :(
Movieman:
Now hoping for any response at all from the developers ?
Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same value in the playback info data?
It seems to me that this issue is affecting anyone who uses the zoom function I and O keys and expects JRiver to always use the exact same zoom percentage value for any subsequent viewing of the same media, not just those like myself who are depending on the accuracy of the zoom presets.
Awesome Donkey:
--- Quote from: Movieman on July 14, 2020, 07:39:04 am ---Now hoping for any response at all from the developers ?
--- End quote ---
Hendrik, who is one of JRiver's developers, already responded above.
Movieman:
--- Quote from: Awesome Donkey on July 14, 2020, 08:57:39 am ---Hendrik, who is one of JRiver's developers, already responded above.
--- End quote ---
That's not actually a response to the latest discovery of what is actually broken. It's a response to my earlier questions.
This: Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same internal representation value in the playback info data? is a flat out bug in the code. Having two different zoom percentages create the same internal representation zoom value in the database playback info field is just flat out broken, and has nothing to do with what an existing user may have come to expect.
And it's not just 102% and 103% that exhibit this behavior, either. It occurs throughout the zoom range.
Navigation
[0] Message Index
[*] Previous page
Go to full version