Redring's Override playback display brightness

af123 said:
The analysis isn't quite right though, nothing is sticking from previous steps.
Click to expand...
I first did this on one HDR and then repeated it twice on another. Results were the same each time. Also previous to that I had not realised that earlier actions were inpacting later ones in the same session, but once I did they also appear to be consistant.

To check my write up again I redid the ten steps, but this time it got stuck on step 5 and the display is still showing [Play 16:12]. :frantic:
Also trying it on my other HDR and that is stuck on step 5 with [Play 16:16].:frantic::frantic:
The time is now 16:19. I used the info button to generate a new redring log entry to check the time was 16:19.

Edit:
And I've just realised what the time is! Bye for today.
Hopefully everthewatcher can see what the situation is with his current redring options
 
Luke said:
I first did this on one HDR and then repeated it twice on another. Results were the same each time.
Click to expand...
Nothing wrong with your results but there's a different reason for why the screen gets stuck. If you do the same experiment on BBC ONE <region>, you won't see the problem.

The code sees the timestamp in "PAUSE 13:26", and sends "PLAY 13:26" instead.
Code: 
[RR] Mon Feb 27 13:26:45 2017: -> SetText(0x12) 50 41 55 53 45 20 20 31 33 3a 32 36
[RR] Mon Feb 27 13:26:45 2017:    [ P A U S E     1 3 : 2 6 ]
[RR] Mon Feb 27 13:26:45 2017: VFD timestamp: 13:26
[RR] Mon Feb 27 13:26:45 2017: Timeshift play assumed (elapsed: 0)
[RR] Mon Feb 27 13:26:45 2017: +> SetText(0x12) 50 6c 61 79 20 31 33 3a 32 36
[RR] Mon Feb 27 13:26:45 2017:    [ P l a y   1 3 : 2 6 ]

Within 15 seconds, you press stop, it sees the channel name being sent to the screen but still thinks that playback is in progress (as it' s< 15 seconds since the last timestamp was seen)

Code: 
[RR] Mon Feb 27 13:26:45 2017:    [ Pause = OFF ]
[RR] Mon Feb 27 13:26:46 2017: -> SetText(0x12) 42 42 43 20 54 57 4f
[RR] Mon Feb 27 13:26:46 2017:    [ B B C   T W O ]
[RR] Mon Feb 27 13:26:46 2017: Timeshift play assumed (elapsed: 1)
.[RR] Mon Feb 27 13:26:46 2017: +> SetText(0x12) 50 6c 61 79 20 31 33 3a 32 36
[RR] Mon Feb 27 13:26:46 2017:    [ P l a y   1 3 : 2 6 ]

As the channel name is short enough for no scrolling, no more screen events occur until you press a key, which is why the display is stuck.

Compare this with earlier where there was a 38 second delay between the last PAUSE message from the Humax firmware and you pressing STOP.

Code: 
[RR] Mon Feb 27 13:15:41 2017: -> SetText(0x12) 50 41 55 53 45 20 20 31 33 3a 31 35
[RR] Mon Feb 27 13:15:41 2017:    [ P A U S E     1 3 : 1 5 ]
[RR] Mon Feb 27 13:15:41 2017: VFD timestamp: 13:15
[RR] Mon Feb 27 13:15:41 2017: Timeshift play assumed (elapsed: 0)
[RR] Mon Feb 27 13:15:41 2017: +> SetText(0x12) 50 6c 61 79 20 31 33 3a 31 35
[RR] Mon Feb 27 13:15:41 2017:    [ P l a y   1 3 : 1 5 ]
..38 second delay..
[RR] Mon Feb 27 13:16:09 2017:    [ Pause = OFF ]
[RR] Mon Feb 27 13:16:09 2017: -> SetText(0x12) 42 42 43 20 54 57 4f
[RR] Mon Feb 27 13:16:09 2017:    [ B B C   T W O ]

In that case, it's more than 15 seconds since it last saw a timestamp so it doesn't interfere and the screen goes straight back to the channel name.

This is definitely a bug that needs addressing, it just isn't doing exactly what you thought it was.
 
redring 2.19-2 now in the beta repository. This one should fix the remaining problems (famous last words). I've simplified the screen handling code so it's now common with the traditional playback handling. Most of the time it should now detect the end of timeshift quickly and return the display to the way it was. On some channels (those where the name ends in a space and digit such as "More 4") it may take up to 20 seconds for the screen to revert.
 
af123 said:
redring 2.19-2 now in the beta repository. This one should fix the remaining problems (famous last words). I've simplified the screen handling code so it's now common with the traditional playback handling. Most of the time it should now detect the end of timeshift quickly and return the display to the way it was. On some channels (those where the name ends in a space and digit such as "More 4") it may take up to 20 seconds for the screen to revert.
Click to expand...
In redring 2.19-2 I could get the delay on More 4, but not redring 2.19-3. Was that the change for 2.19-3?
 
Luke said:
In redring 2.19-2 I could get the delay on More 4, but not redring 2.19-3. Was that the change for 2.19-3?
Click to expand...
Yes, the "More 4" case was fixed in -3 (and was the only change between -2 & -3). Well spotted!

I think I've covered all cases now so that the code won't need to drop back to the timeout method.

Code: 
                /*
                 * This is a playback screen if:
                 *      Empty (at least, assume an empty screen is)
                 *      Ends with :
                 *      Contains only single <digit>
                 *      Ends with <digit><digit>
                 *      Ends with :<digit>
                 *      Ends with <space><digit> and is 12 characters long.
                 */
 
Last edited:
Another small change with the latest webif package (along with the beta redring) is that the current front panel is shown in the output of 'status':

Code: 
humax# status
Watching 200: BBC Red Button
VFD: BBC Red Butt
Idle: 00:00:03

This will probably end up in the web interface somewhere too.
 
So, everthewatcher, can you confirm if beta 2.19-3 solves this problem for you?

Luke and others, do you think I should just make this the default behaviour when "Show elapsed time during playback" is set rather than retaining the separate option?
 
af123 said:
do you think I should just make this the default behaviour when "Show elapsed time during playback" is set rather than retaining the separate option?
Click to expand...
Yes.
The reason being is that it whether or not "how [Play HH:MM] instead of [clock > HH:MM]? " is set or not set then the result appears to be always an improvement. If there should be an instance where
it is not as good then the benefits still outweigh the disadvantage. Not increasing the number of options when this is released will also make it easier to limit any setting possibilities if someone claims something is wrong but is not clear about their settings or unknowingly their setting haven't yet been reloaded since last changed
 
Seems fine to me. The original issue has been dealt with, the fixes don't seem to have introduced anything new and any lags before overwriting seem about the same Well done.

As for changing the default behaviour I'd go with changing it as suggested.
 
You must log in or register to reply here.
Back
Top