OSD Zap delay in milliseconds ms (1 Viewer)
- Thread starter arneman
- Start date
Re: AW: OSD Zap delay in milliseconds ms
I'm sure someone will look at this issue after your post... and what comes to the zero as delay bug, fix for it wont be allowing ms precision to be used
I'm sure someone will look at this issue after your post... and what comes to the zero as delay bug, fix for it wont be allowing ms precision to be used
I couldn't disagree more. In my opinion this is clearly a bug when a setting causes MP to hang.. It shouldn't be considered a feature request, but a bug report. Having the same issue though. Please fix it - or at least consider it as a bug and not as a feature request..
This is a bug that has been there like forever, just seems that noone had the courage yet to report it..
- April 4, 2010
- 32
- 12
- Home Country
-
Turkey
Unfortunately 0.5 does not work. Can it be considered as a bug
- January 26, 2006
- 892
- 39
- Home Country
-
Germany
AW: OSD Zap delay in milliseconds ms
besides that there may be a bug, I do not get the point.
When zapping with chup/chdwn you can easyly and fast zap multiple channel up or down, plus you see the Info of the running show, and if you do nothing for a second (if 1 second is set) the channel is tuned.
Where would be the benefit of setting this to 0.1 second? Because tuning takes 2-5 seconds (depending on your setup) anyway, and you would not see the respective channelinfo long enough to read it.
cheers
joystick
besides that there may be a bug, I do not get the point.
When zapping with chup/chdwn you can easyly and fast zap multiple channel up or down, plus you see the Info of the running show, and if you do nothing for a second (if 1 second is set) the channel is tuned.
Where would be the benefit of setting this to 0.1 second? Because tuning takes 2-5 seconds (depending on your setup) anyway, and you would not see the respective channelinfo long enough to read it.
cheers
joystick
AW: OSD Zap delay in milliseconds ms
i've tried "0.5" months ago when RC1 was out. there seems to be an "integer-check" not allowing float values.
i don't want to set it to "0.1". anything lower than 250ms would be ridiculous.
my dvb-s2 card tunes < 1 second! with a value of "1" MP is longer idle than my card needs to tune the channel actually. what would you say, if you have a 500ps porsche, which needs 12s from 0-100km/h just because someone intergrated something in the engine to delay the acceleration for some seconds???
a value of "0" is not optimal though, but as there is a feature-freeze it would be a step in the right direction when this hangs would be fixed before the stable 1.1 gets released. i can imagine why 0 causes this hangs. when you press the ch+ button and then press it again very close after, MP hasn't finished with tuning and creating the timeshift-file for the last channel yet and then gets stuck.
so imho, this problem should not be solved by adding different options to the zap-delay-field, instead it should be handled in the code.
a setting of "0" should be interpreted as "150ms" in the coresponding code for channel-tuning. should be a good compromise, or?
i've tried "0.5" months ago when RC1 was out. there seems to be an "integer-check" not allowing float values.
i don't want to set it to "0.1". anything lower than 250ms would be ridiculous.
my dvb-s2 card tunes < 1 second! with a value of "1" MP is longer idle than my card needs to tune the channel actually. what would you say, if you have a 500ps porsche, which needs 12s from 0-100km/h just because someone intergrated something in the engine to delay the acceleration for some seconds???
a value of "0" is not optimal though, but as there is a feature-freeze it would be a step in the right direction when this hangs would be fixed before the stable 1.1 gets released. i can imagine why 0 causes this hangs. when you press the ch+ button and then press it again very close after, MP hasn't finished with tuning and creating the timeshift-file for the last channel yet and then gets stuck.
so imho, this problem should not be solved by adding different options to the zap-delay-field, instead it should be handled in the code.
a setting of "0" should be interpreted as "150ms" in the coresponding code for channel-tuning. should be a good compromise, or?
...because there are people that don't care about the description and just want to actually _SEE_ if there is something running on this channel they want to watch, because either they don't know what this program is or just want to zap...
besides: if they get the "0"-Setting to work, there is no need for milliseconds..
PS: 2-5 seconds? not even my cheap terratec tv-card need that much time to tune in a channel, and as far as I can remember my FloppyDTV was even much faster than that..
besides: if they get the "0"-Setting to work, there is no need for milliseconds..
PS: 2-5 seconds? not even my cheap terratec tv-card need that much time to tune in a channel, and as far as I can remember my FloppyDTV was even much faster than that..
I agree that the "0" resulting in lockup is a bug - let's see if MP team can reproduce it. I can anyway
Hi,
To answere that i actually can't reproduce it 0 - 0 in that settings means Zap OSD on all the time, so a proper bug report in correct forum with the needed system specs & logs are needed, nothing more to discuss in this thread, but the original in this thread is nice & after freeze could indeed be something.
Regards
Roy
I agree that the "0" resulting in lockup is a bug - let's see if MP team can reproduce it. I can anyway
I haven't seen a bur report thread about the issue. Someone please open such so this issue wont get lost. In any case it is not a show stopper issue since it can be avoided with quite ease by not selecting zero as the setting. So, something to be fixed in 1.2.0.