[rs] Improved conflict detection

af123

af123

Administrator
Staff member
I've been working on a new algorithm for detecting recording conflicts that is more accurate and takes all scheduled episodes into account. I've finished initial testing and it looks good but I'd appreciate some more people testing it and seeing what it looks like against their schedules.

To enable it you need to make sure that you have updated to the latest version of the rs package and then run the rs/newconflicts diagnostic on your Humax to turn this on or off (it's a toggle).

Once it's enabled, you'll see a note next to the region at the top of the RS web page and a new Conflicts button will appear at the top left. This takes you to a page which shows the full expanded schedule (one row for each event, even those which are future episodes). Any conflicts will be highlighted in pink and any events which require the use of more than one tuner have a red icon at the left hand side (they should appear in pairs). This is just to help work out if it's doing the right thing.

Whilst enabled, the new code will also be used for highlighting any conflicts on the main page, and for any conflict alerts that are sent via email. If everything looks okay then I will switch in the new code for the old and look at whether it is practical to implement this new algorithm in the on-box web interface too.

Screenshot%202016-02-24%2014.26.24.png
 
I have some groups of 3 and 4 tuner buttons (not just pairs) where there is a series of overlapping recordings - but so far valid overlaps without 3 simultaneous events.

It can be quite hard to visualize the sequence of events when examining these overlapping events and to determine which event can be moved to an alternative time if there is a conflict.
I haven't thought through how it might work or look but I was wondering if it would be possible to display events on a timeline so show the overlaps visually and to provide links to allow scheduling of alternate broadcast times.
 
Oh this is very handy indeed, even without seeing conflicts. I know it's only testing for now, but in addition to MymsMan 's comments above, I would like to see an indication of whether the recording is part of a series. Although that would probably fall out of the comments above (although not just for conflicts).

great, thanks!
 
MymsMan said:
I have some groups of 3 and 4 tuner buttons (not just pairs) where there is a series of overlapping recordings - but so far valid overlaps without 3 simultaneous events.
Click to expand...
I was wrong to say that they would occur in pairs; I should have said that they will not occur alone.
Some visual representation would definitely be useful, I'll investigate.
 
One thing that has surprised me is how often I am relying on there being two tuners!
 
af123 said:
I was wrong to say that they would occur in pairs; I should have said that they will not occur alone.
Some visual representation would definitely be useful, I'll investigate.
Click to expand...
I had a little browse through jquery timeline packages - there are quite a few and this one looks quite promising http://www.jqueryscript.net/time-clock/Simple-jQuery-Schedules-Events-Plugin-graspSchedule-js.html
Demo http://www.jqueryscript.net/demo/Simple-jQuery-Schedules-Events-Plugin-graspSchedule-js
 
I wrote a perl script that generates the output shown below. If it would be useful I could send af123 the script in the hope it might speed up development of a timeline page in the WebIf. (The final output format could be different.)

My script is written in perl and I run it from my laptop computer. I just tried running it on the humax and it didn't work because it requires the perl Datetime module. But rather than spending time to get the perl script working on the humax I think it would be more fruitful to perhaps use it as a stepping stone towards a new WebIf page.
Code: 
2016-02-25 20:00 | 101 ┌   Room 101
2016-02-25 20:00 | 102 │┌  Big Dreams Small Spaces
2016-02-25 20:30 |     └│  Room 101
2016-02-25 21:00 |      └  Big Dreams Small Spaces
2016-02-25 21:00 |  28 ┌   Brooklyn Nine-Nine
2016-02-25 21:30 |     └   Brooklyn Nine-Nine
                 |         
2016-02-25 22:45 | 101 ┌   Question Time
2016-02-25 23:45 |     └   Question Time
                 |         
##### Fri ###### | ###     ########## Fri ##########
                 |         
2016-02-26 21:00 | 102 ┌   Philomena
2016-02-26 21:00 | 104 │┌  Gogglebox
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2016-02-26 21:30 |  13 ││┌ Food Unwrapped
2016-02-26 22:00 |     ││└ Food Unwrapped
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2016-02-26 22:00 |     │└  Gogglebox
2016-02-26 22:00 | 104 │┌  The Last Leg
2016-02-26 22:30 |     └│  Philomena
2016-02-26 23:05 |      └  The Last Leg

Note the blank line just before question time indicates there's a gap between blocks of recordings.
 
I appear to have an undetected 3 recording conflict.
Next Wednesday at 20:00 I have the following in the rs schedule list
Series, BBC2HD, 100k House: Tricks of the Trade (shown in conflict list)
Single, BBC1HD, Traffic Cops (NOT shown in conflict list)
Series, Pick, Sanctuary (shown in conflict list)

The conflict list does not have Traffic Cops in it at all, so doesn't report a conflict.
The 2 text boxes at the bottom of the list just contain Array ()
I cannot see anything unusual about that non-series recording, there are several others in the schedule and they all appear in the conflict list.
 
Excellent, thanks, that's found a bug in the new code. I will fix it now.
 
MymsMan said:
I had a little browse through jquery timeline packages - there are quite a few and this one looks quite promising http://www.jqueryscript.net/time-clock/Simple-jQuery-Schedules-Events-Plugin-graspSchedule-js.html
Demo http://www.jqueryscript.net/demo/Simple-jQuery-Schedules-Events-Plugin-graspSchedule-js
Click to expand...
I'm halfway through mocking something up (I've been wanting an excuse to play with inline-block layout) but I'll have a look at this plugin when it's finished.
 
I think it's a mistake to make it linear in time. The scheduling system is event driven, so you do not need to illustrate how long it is between events, only the order in which events occur. That's the main feature of Oatcake's solution.

The same philosophy was adopted during the development of logic analysers. In the beginning they captured the state of every sample input on every sample tick, but eventually the likes of Hewlett Packard realised that most of the time nothing changes from one tick to the next, so they were able to extend the sample window by only recording the times at which the input state changed. OK, so they then reconstructed a time-linear 'scope display because that's whet engineers were used to looking at (and is often the most useful), but when events that span a few microseconds occur over periods of seconds to days a 'scope trace isn't very useful for finding them, and you switch to an event listing view.

An event-based trace also means you are not trying to squeeze loads of property info about the event into a small length of time-linear trace. Oatcake's text solution can be prettied up in the general style of the WebIF, but for my money it's on the right track.
 
You must log in or register to reply here.
Back
Top