[rs] Improved conflict detection

No, that's nothing to do with me. Events only show up on the conflicts page if they are scheduled for recording by your Humax. If an episode shows up as brown/orange in the EPG then that means that it is part of a /series/ which is scheduled but that the episode is not. That usually means that the particular episode has already been recorded or has not yet been selected for recording by the Humax - it could be that the Humax's EPG data isn't new enough yet.
Humax's schedule page was listing them (right arrow from the series entry).
Anyway, they have now reappeared on the [rs] conflict page as scheduled recordings. Maybe just a result of the time change working through the pipeline of transfers between Humax and [rs].

(EDIT- just re-read what you said at the end and realised that my "pipeline" is effectively what you were talking about when you suggested "new enough yet".)
 
I have a feeling that it will be stuck on 4HD+1 from now on. Unfortunately we have to wait a week to find out!
Unfortunately we won't be able to find out. Since the middle of the week the moved (4HD+1) programme has been in conflict with the programmes that it was originally moved to avoid. The schedule now shows all programmes times as they were last Monday Tuesday, so I will have to resolve it by moving the recording back to 4HD. I wonder if the conflict was just the result of the various channel's initial handling of the EPG data for post-clock-change programmes.
 
Last edited:
I wonder if the conflict was just the result of the various channel's initial handling of the EPG data for post-clock-change programmes.
Could be - It was the standard on-TV interface that flagged the conflict wasn't it?
 
Queued is harder since I can't be entirely sure how it will be incorporated into the schedule.

I'll second the request for the above please. Even if it just handles the very obvious simple case, of something being scheduled where there's no existing conflict or anything. Could be highlighted as a different colour to indicate its tentative status?

thanks much...
 
I'll second the request for the above please. Even if it just handles the very obvious simple case, of something being scheduled where there's no existing conflict or anything. Could be highlighted as a different colour to indicate its tentative status?
Yes, I plan to improve this feature over the next couple of weeks - just need a couple more tuits.
 
I had actually done some work on this which I hadn't uploaded. Here is what queued events now look like in the grid.

upload_2016-4-4_15-15-0.png

For this set of queued events:

upload_2016-4-4_15-16-58.png

Here's the hover-over for JAG

upload_2016-4-4_15-17-30.png

I haven't added support for other types of queued event yet - what do you think they should look like?

I intend to use this purple colour for anything which is queued but what about things which are queued for something like a folder change? Would you want to see that with a strike-through (like the unschedule) or just in purple with the reason being shown on hover-over?

Once the queued event handling is sorted out, I'll move onto doing the same for pending events.
 
I prefer the strike through only on unschedules and skip episode (though I would prefer the strike through only on the episode being skipped and not the other episodes in series)

In my mind strike through = deletion and therefore shouldn't be used for other changes
 
Just a suggestion - would it be possible to have a legend to describe the different colours (eg, I have not seen a brown and do not know what it is) and the strikethroughs.
This may help future newcomers to the Conflicts page.
Thanks for doing this...
 
I've settled on purple for pending schedule/unschedule and orange for any other pending change. This should now be working for both queued and pending events.

Screenshot%202016-04-04%2021.44.41.png
 
I've settled on purple for pending schedule/unschedule and orange for any other pending change. This should now be working for both queued and pending events.

super! thanks.

one niggle: since the hover-over works for more than just Pending events, that note should be moved from the Pending button in the key, to e.g. "Key (hover over for more details):", perhaps?
 
one niggle: since the hover-over works for more than just Pending events, that note should be moved from the Pending button in the key, to e.g. "Key (hover over for more details):", perhaps?

which I now see you have already changed :) thanks much.
 
Yes, I made the key shorter to fit on one line (once I'd added the conflict colour).

I've also added a new feature with RS 1.4.5 which allows you to trigger a refresh. That forces the Humax to rescan the EPG and rebuild the list of events to record. This is useful when broadcasters change things in the EPG data such as the episode change for Scorpion a couple of pages back. Refresh can be triggered from the OPT+ button on the main recordings view and also from the More button in the Visual-view popup dialogue window.

The button at the top is also now called Visual and is available to everyone. The 'testing new conflict code' flag is no longer necessary.

Tonight I will look at the alignment issue reported in another thread!
 
I tried this using the More button on the Home page and selected Refresh Events on one of my scheduled recordings. It duly queued the command. I tried to cancel the command using the 'dustbin' but nothing happened. I left the page and came back and this time, using the 'dustbin', I had the option to Cancel and, when selected, the queued command disappeared.
Using the option from the Visual page worked fine - going to the Home page and deleting the queued command worked okay.
 
Yes, I made the key shorter to fit on one line (once I'd added the conflict colour).

I've also added a new feature with RS 1.4.5 which allows you to trigger a refresh. That forces the Humax to rescan the EPG and rebuild the list of events to record. This is useful when broadcasters change things in the EPG data such as the episode change for Scorpion a couple of pages back. Refresh can be triggered from the OPT+ button on the main recordings view and also from the More button in the Visual-view popup dialogue window.

The button at the top is also now called Visual and is available to everyone. The 'testing new conflict code' flag is no longer necessary.

Tonight I will look at the alignment issue reported in another thread!

Now that the logic to Skip/Reschedule/Unschedule recordings appears to be reaching perfection would it possible to implement the same logic when clicking on an already scheduled recording in the RS and Webif EPG screens?

When scheduling a new recording that would create a conflict it would be nice to be able to move or cancel the conflicting recordings without having to leave the EPG screen.
 
Thanks for the work put into this, I find it very useful.

The 'Visual' page is good, especially with the colours for the different stages. I do like the layout of this as it really does help with working out how to avoid conflicts, much easier than the table on the home page.
 
A conflict over midnight is not being recognized.

I have two programs starting late on Sunday ending at 00:20 Monday and a third starting at Midnight but the conflict is not detected.
Unique Identifier 574031595
hpkg.tv Remote Scheduling - Mozilla Firefox 13042016 192315.jpg
To detect these you might need to use a 25hour day where 00:00-01:00 is included at start and end of the day
 
Is it being recognised on the main page?

Edit: Yes, it is.

Visual grid should look better now.
 
Last edited:
For what it's worth, here's the over-midnight span causing alignment issues that I mentioned elsewhere:

Screen Shot 2016-04-13 at 11.56.55 pm.png

which has caused progs on Thurs to be wrongly right-shifted, including the 0420 Disable OTA.

[and please do consider optionally ignoring the OTA event, to allow for better horizontal space use? thanks...]
 
Back
Top