[rs] Improved conflict detection

It's intentional that New: is removed to give more space for the title, but not that it is removed from New Tricks, no!
 
I've uploaded a new version of rs and other associated packages which contains these new experimental helpers for dealing with schedule conflicts.
You will need to wait until the RS server spots that you have rs version 1.4.4 (running the rs/sync diagnostic should do it) and you need to have the new conflict testing enabled (run diag rs/newconflicts if you don't already have this).

It's still a work in progress but I'd appreciate any testing and feedback (Eastenders and Coranation Street are great test subjects). There are four options that can be presented when you click on an event, depending on whether it's a one-off or series entry and whether you have switched to an alternate showing of that event (by clicking on one of the Also: links as shown in the video above).
  • Cancel Entire Recording
  • Skip This Episode
  • Record This Showing Instead
  • Switch to This Series
Skip is the only really new feature, the others are shortcuts to more than one operation. For example, 'Record This Showing Instead' effectively runs 'Skip' then schedules the replacement as a one-off episode. As BH noted earlier, this then ends up in the top level recording directory instead of alongside the rest of the series, but I have a plan for solving that.

Episode skipping works by altering the schedule database so that the Humax thinks that the episode in question has already been recorded. It also forces the Humax to perform a new search for episodes - the schedule can take a minute to completely update following reboot. One gotcha though; the list of recorded episodes can only contain five entries so this won't work if there are more than four episodes to be recorded between now and when this episode should be skipped (that is rarely a problem in practice).

I still need to include some feedback on the screen that something has been done and there is the usual problem of showing the old information whilst the commands are queued rather than pending. It should, however, be possible to skip more than one episode in the same series without waiting for the commands to go through the whole cycle - it will just add them all to the same pending skip event.

Screenshot%202016-03-21%2020.33.43.png
 
I've added some on-screen feedback (growl-style notification at top right). Still not entirely happy with it..

Also found that skipping several episodes of the same series in the same transaction doesn't work. Will be fixed in a further update this evening.
 
I have just schedules a series recording through the SUI; Obsessive Compulsive Cleaners (for the wife) at 8 tonight. The SUI detected a conflict next week and offered the +1 for next week, which I accepted. The SUI schedule shows the recording as 8 tonight and 9 on the +1 next week. The webif, rs and rs conflict report all show next week's schedule at 8, but at least they then show it as a conflict.
 
I'll be interested to see how that pans out after tonight's recording! I don't know what mechanism is being used to pick +1 next week but if it works it could be useful.
 
af123 said:
I'll be interested to see how that pans out after tonight's recording! I don't know what mechanism is being used to pick +1 next week but if it works it could be useful.
Click to expand...
Possibly worth taking a look at the schedule database to see what entries have been created.
 
af123 said:
I'll be interested to see how that pans out after tonight's recording! I don't know what mechanism is being used to pick +1 next week but if it works it could be useful.
Click to expand...
Me to, I have a recollection of the SUI doing this before, but I am not sure whether it came up with the goods in the end!

MymsMan said:
Possibly worth taking a look at the schedule database to see what entries have been created.
Click to expand...
I presume that you need /var/lib/humaxtv/rsv.db? I have attached it (don't be fooled, it is the db not a zip, I have just used that extension so that I can get it to upload). Hope that works OK. It was copied during tonight's recording.

By the way, first time I have seen the [rs] schedule page showing conflicts on later episodes... nice.
 

Attachments

  • rsv.db.zip
    28 KB · Views: 4
Hmm, szsttime has an unusual character at the end:

"000000000000000\245"

Otherwise, I can't see anything which suggests it will not just schedule the 8pm episode next week. The aulEventToRecordInfo field contents is what is showing the future episode next week within the webif and RS.

Code: 
sqlite> select * from TBL_RESERVATION where szevtname like '%compulsive%';
              ulslot = 6
            ersvtype = 3
                hsvc = 786700
             nsttime = 1458676800
            szsttime = 000000000000000¥
           nduration = 3600
             erepeat = 0
             usevtid = 10875
           szevtname = Obsessive Compulsive Cleaners
         ulPreOffset = 0
        ulPostOffset = 0
         ulProgramId = 0
          ulSeriesId = 0
            ucVolume = 0
         ucInputMode = 0
             usChNum = 0
           ucRecKind = 4
          ucCRIDType = 50
              szCRID = WWW.CHANNEL4.COM/C4ED0013021316218751
        szFPBRecPath = Obsessive Compulsive Cleaners
  szRecordedProgCrid =
     szEventToRecord = 1WWW.CHANNEL4.COM/60961/009|1WWW.CHANNEL4.COM/60961/010|
aulEventToRecordInfo =<binary>
           bRecomRsv = 0
usLastRecordedEvtId = 0
              eReady = 30
 
During the recording, I checked the SUI schedule and although next week indicated recording at 9, it still indicated 4HD, not the +1.
However, now the recording has finished, it seems to show the correct information 9:00 and 4HD+1.
The webif and rs agree with the SUI and the conflict has gone.
The latest database file is attached
 

Attachments

  • rsv.db.after.zip
    28 KB · Views: 1
Out of curiosity, at what point does Humax scheduling adjust for BST? I have noticed that some functions stick to GMT, the EPG download for example.


Sent from my iPad using Tapatalk
 
Just shows that we don't know everything yet!

I'm not sure about the BST adjustment. The daily wakeup will look wrong in the conflict view at least because of the way I'm calculating the repetitions.
 
4ndy said:
Out of curiosity, at what point does Humax scheduling adjust for BST? I have noticed that some functions stick to GMT, the EPG download for example.
Click to expand...
The internal scheduling is all GMT. It is only on display that conversion to BST is done. Whether or not it converts the time to BST on display is dependent on the date&time of the event and the BST/GMT range that is included in the broadcast transmission but not itself displayed. Manual timers are taken literally and during BST will be treated as BST and during GMT will be treated as GMT.
 
Which is great until the UK changes its rules on BST implementation (which will cock up our computers too).
 
That's fine, assuming you are running a supported OS and trust Microsoft enough to allow updates rather than run it in isolation with a "don't fix what ain't broke" security policy.
 
"Broke" would include downloading an update which caused my bunkered Win7 installation to pick up a Microsoft update-to-Win10-or-else earworm.
 
I have a strange conflict case this morning:

upload_2016-3-24_9-43-0.png

upload_2016-3-24_9-44-26.png

This looks like a broadcaster error..

Decoding the aulEventToRecordInfo field in the schedule database gives:

Code: 
{65537 1458853200 1458856800 43532} {65537 1458853200 1458856800 44589}

So the two showings of Scorpion are on the same service in the same time range but have different event IDs.

Looking on the RS server, both of these were present in the EPG at the same time earlier:

Code: 
+----------+----------------+
| event_id | left(text, 10) |
+----------+----------------+
|    43532 | Da Bomb: U     |
|    44589 | Fractured:     |
+----------+----------------+

but only one of them is there on my Humax now:

Code: 
humax# epg -S8325 -E44589 dump | grep Text: | cut -c1-50
                          Text: Fractured: US mili
humax# epg -S8325 -E43532 dump | grep Text: | cut -c1-50
humax#

I wonder if this is similar to the duplicates that other people have reported - I think they were ITV2 as well.
 
I have the same. The following weeks Scorpion is not shown in the Conflicts and looking at the EPG I can see that the 31st program is also scheduled for the 24th
Capture24-03-2016-10.00.00.jpg
 
You must log in or register to reply here.
Back
Top