View Full Version : [VU+ Uno4KSE] Recording indicator on EPG
I use recordings often to zap channel to watch news. Thats why i put margin before recordings to 0 min. So it is 0 min also for all recordins. Now if i select several programs to record for evening, only part of the events turns to red and some stay grey.
If i select margin time other than zero, all selected events turn to red.
Is it possible to modify image so that all for recording selected events turn to red is precording time is selected to zero.
abu baniaz
24-08-22, 12:23
It would have been a better representation to keep all the images separate instead of combining them on one thumbnail.
Anyway, are you sure that they are not subject to timer conflict?
What you mean by timer conflict. With zero prerecord time the conflict should be smaller. I have tried this several times, and always the same result. Prerecord time is needed at least one min (which is minimun selectable). The epg pictures are captured from the same events (finnish epg) few minutes after each other.
Agree thumbnails. Tried to connect settings and result together.
No timer conflicts ! I have also tested it by selecting margin before recording (minutes) to 0, then that decribed above happens. When margin before recording (minutes) is set to 1 min, every event is red. I have 4 terrestial tuners.
In Finland programs start often late but never earlier than scheduled. That`s why prerecord-time is not needed.
@posi, can you check if it is the start time, finish time or both that cause this.
64197
64198
Margin before recording (minutes) is set 0.
I can't tell if it is the start time, the lenght or the finish time. But looks like if they have the same start time, only the first is red. Posi's pics is the same.
@posi, can you check if it is the start time, finish time or both that cause this.
If i set margin before recording to 1 and after recording to 0, each selected event turns to red. So the after recording time is not the reason.
Maybe it depends on which skin is used?
I can't reproduce this.
Definetly the problem is related to the program's start time. If they start at the same time, only the first rec is red.
Definetly the problem is related to the program's start time. If they start at the same time, only the first rec is red.
So long story short, starting timers is not tread safe. e.g. if we started 2 timers at the same time the control commands would both be sent to the LNB at the same instant and therefore not be understood. This is only a problem with Unicable where multiple tuners are talking to the same LNB.
So to fix the above problem simultaneous timers are staggered by one second, i.e. if the program starts at 20:00:00 the first timer will start at 20:00:00, the next timer at 20:00:01, and the next timer at 20:00:02, and so on.
That means if you set the margin to zero the first timer background will display correctly and the subsequent ones won't.
# Only highlight timers that span an entire event
https://github.com/OpenViX/enigma2/blob/Developer/lib/python/Components/EpgListGrid.py#L541
I guess maybe we could add a margin to workaround this, e.g. here: https://github.com/OpenViX/enigma2/blob/Developer/lib/python/Components/EpgListGrid.py#L533
timer, matchType = RecordTimer.isInTimerOnService(serviceTimers, stime, duration)
Change to:
timer, matchType = RecordTimer.isInTimerOnService(serviceTimers, stime + (20 if config.recording.margin_before.value == 0 else 0), duration)
That means if you set the margin to zero the first timer background will display correctly and the subsequent ones won't.But no conflicts are reported, and all timers are actually set (according to the OP).
Shouldn't the EPG just display the timers that are set and not care about anything else? Why would that code be doing any conflict checking?
pre 0 post 0. Same start time. Ok
64200
pre 1 post 0. Same start time. Ok
64201
pre 0 post 3. Same start time. Error
64202
pre 0 post 3. Different start time. Ok
64203
Note. If the post time is zero, still there is a mark on the following event.
Skin Simple Ten Eighty
Why would that code be doing any conflict checking?My comments have nothing to do with conflict checking, and I don't mention it. Please re-read.
I guess maybe we could add a margin to workaround this, e.g. here: https://github.com/OpenViX/enigma2/blob/Developer/lib/python/Components/EpgListGrid.py#L533
Change to:
timer, matchType = RecordTimer.isInTimerOnService(serviceTimers, stime + (20 if config.recording.margin_before.value == 0 else 0), duration)
I can confirm that change did the trick (Margin before recording (minutes) is set 0), thank you Huevos.
64204
64205
BTW, why would anyone want to set their default start margin for every recording to 120 minutes before the program begins?
BTW, why would anyone want to set their default start margin for every recording to 120 minutes before the program begins?Why would you wish to stop them if that is their desire?
I think the idea is that in some cases (Unicable) asking two tuners to retune at exactly the same moment doesn't work.
So a workaround was made so that there never are two timers starting at exactly the same time: a timer starting at the same time as another will be changed to start 1 second later instead.
Later:
How about changing it to 1 second earlier instead?
I think the idea is that in some cases (Unicable) asking two tuners to retune at exactly the same moment doesn't work.
So a workaround was made so that there never are two timers starting at exactly the same time: a timer starting at the same time as another will be changed to start 1 second later instead.Isn't that what I already explained?
How about changing it to 1 second earlier instead?Because the whole idea of zero is to reduce timer conflicts. Adding -1 would create start times before the program boundary, adding conflict when resources are limited.
Or why not do it properly and implement a critical region using semaphores in the code that sends Unicable commands?
Or why not do it properly and implement a critical region using semaphores in the code that sends Unicable commands?I look forward to receiving your pull request.
timer, matchType = RecordTimer.isInTimerOnService(serviceTimers, stime + (20 if config.recording.margin_before.value == 0 else 0), duration)[/CODE]
@Huevos, are you going to commit this ?
@Huevos, are you going to commit this ?I was but Littlejim says I'm doing it all wrong and c++ needs a rewrite.
I was but Littlejim says I'm doing it all wrong and c++ needs a rewrite.You can do mutex locking in Python.
You can do mutex locking in Python.Nothing to do with Python.
This issue was unsolved for months before the workaround was introduced. Now someone knows exactly the correct way to fix it. Well if he is so clever let him send a pull request.
I was but Littlejim says I'm doing it all wrong and c++ needs a rewrite.
But commit this version, please. Rewriting is maybe coming later ?:whistle:
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.