#16922 closed bug (fixed)
MediaPlayer does not hold settings
Reported by: | vidrep | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta3 |
Component: | Applications/MediaPlayer | Version: | R1/beta2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
hrev55046 x86_64
MediaPlayer -> settings -> resume
When set to "ask every time", it will fall back to "always" when resuming playback of a media file.
Change History (11)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
The commit that I suspect broke MediaPlayer settings: https://git.haiku-os.org/haiku/commit/?id=6375ef053d7770a8af1389fda494fac25c131360
comment:3 by , 4 years ago
This can be fixed by removing the settings file /boot/home/config/settings/MediaPlayer and relaunching.
comment:4 by , 4 years ago
That's because the sign of the fields have been changed, so the code does find a "resume" field in the message but with the wrong type, and it can't replace it.
Maybe we should add code to convert the old settings.
comment:5 by , 4 years ago
But how can this commit brake that? it's the same code(more or less) https://git.haiku-os.org/haiku/commit/?id=6375ef053d7770a8af1389fda494fac25c131360
To make a converter we need to know what type it was before. But if we don't do a converter we need to have this workaround in Known fixes in the Release documentation for Beta3
The only thing I can think of can brake this are that now handle uint32 "correct".
Before
uint32 SettingsMessage::GetValue(const char* name, uint32 defaultValue) const { int32 value; if (FindInt32(name, &value) != B_OK) return defaultValue; return (uint32)value; }
now
uint32 SettingsMessage::GetValue(const char* name, uint32 defaultValue) const { uint32 value; if (FindUInt32(name, &value) != B_OK) return defaultValue; return value; }
comment:6 by , 4 years ago
That's the thing: it was stored as an int32, and so the new code doesn't find it.
comment:7 by , 4 years ago
as we have this for int32 I would say this are bug fixed. So now's the question. Do we make a workaround when we a bug are solved?
I wouldn't, but mention this in the release notes?
comment:8 by , 4 years ago
What's the big problem in staying compatible? Just also search for int32 after uint32 failed.
comment:9 by , 4 years ago
Milestone: | Unscheduled → R1/beta3 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in hrev55056.
comment:10 by , 4 years ago
Except now it does load the value from the settings but is not able to change it.
The commit that I suspect broke MediaPlayer settings: https://git.haiku-os.org/haiku/commit/?id=6375ef053d7770a8af1389fda494fac25c131360