Summer Time confusion

Kirbett

New Member
Ok. We've just moved onto BST from GMT. And I wasn't surprised to see some discrepancies in the Web-If's list of scheduled events, specifically in the timings shown for manually entered repeated events, including an Auto-Update event listed as occuring at 05:30 rather than 04:30. So I thought backing-up and restoring the schedule might resolve these differences, and it did seem to straighten out the Auto-Update event, now listing that as occurring at 04:30, correctly overlapping the manual reminder I have programed in for 04:20-04:40.

However, all of my five other manually entered repeated recordings now show correctly on the PVR's own listing of scheduled events, but show as being one hour later on the Web-If's listing. This is despite having rebooted the PVR and having closed and reopened my browser and relogged into the Web-If. The recordings are a mix of 1/5/7-days per week. AR recordings seem to be being listed correctly.

I was under the impression that the WebIf would be retrieving its schedule info directly from the PVR. So if the PVR has got it right, how can the WebIf get it wrong? Could it be that the WebIf itself has not yet moved onto BST?

The Remote Scheduler is exhibiting the same discrepancies. And the apparent shift in time in one of the manual repeated events is causing it to claim a recording schedule conflict where none actually exists.

I am inclined to cancel and reenter the manual events, but at the moment, I'm not sure what the consequences of doing that would be.

Bill R

Running WebIf 1.2.5-6, and CF 3.03 (build 2368) on Humax 1.03.12
 
The HDR-FOX operates on GMT internally, and it only converts to BST when appropriate for presentation to the user. If the SUI (standard user interface) shows the correct times etc in the recording schedule using Guide >> Schedule (yellow), you can be sure they are right.

The WebIF, RS, and supporting software packages is a complex home-brew set of software which, although well developed and slick, would hardly be a surprise if some bugs were still present when converting the internal times stored in the HDR-FOX database for presentation to the user. Even the date might change if the time is around midnight. The best thing to do, if you notice a particular discrepancy, is to report the very specific details of each discrepancy (preferably with screen shots) so that the code experts can hunt down the bug. Just saying "it's not working" doesn't help very much. Note also that the problems may be boundary conditions which will disappear in a matter of hours when the effect of BST has propagated through, so may be very difficult to find in a few days time.
 
I was under the impression that the WebIf would be retrieving its schedule info directly from the PVR. So if the PVR has got it right, how can the WebIf get it wrong?
Webif gets the data directly from the PVR database so this looks like a problem with interpretation of those data. IIRC, prpr reported something similar at the last clock change.

Can you provide your RS Unique Identifier for this device? That can be found on the settings page within RS. I can then have a look at the database and see what's going on. There aren't many chances to look at this kind of problem : )
 
Having spent over 30 years diagnosing other people's computer problems, I am well aware of the inadequacy of a problem report of the form "it's not working" and thought I had avoided that failing. I am well aware that the software is a complex home-brew set of products, but am nevertheless immensely appreciative of, and impressed by, the efforts that have been made to produce such software (may I just say thanks to all you guys!). I did say that I wasn't surprised to see the software running into time-zone discrepancies, since in the past, I myself have had to struggle with the complexities of making software behave in such circumstances. Perhaps it was that that led me to attempt to extract what I perceived to be the salient problem symptoms for the benefit of the developers, rather than just supplying straight forward screen caps. I guess that was the wrong thing to do.

I was also aware that there may be a boundary condition in play. Which is why I rebooted the PVR and restarted the WebIF browser ... and wondered if there was some other aspect of the WebIF which I hadn't envisaged that the BST change might still have to works its way through. Maybe the WebIF caches its input from the HDR-FOX's own database? But that would seem a strange thing to do ...

The choice seems to be between waiting a few days for the BST change to iron itself and forgetting about it (and running into the same problem next year, as I did last year), or grabbing the opportunity now to try and pin down the problem. I'm happy to do either. But in the spirit of the latter, I attach the following screen caps:

Screen cap of WebIF Schedule Screen
Screen cap of database rsv.db (left-hand-side), sorted by slot
Screen cap of database rsv.db (left-hand-side), sorted by szsttime
Summer-Time-rsv-db-sorted-by-slot.jpg Summer-Time-rsv-db-sorted-by-szsttime.jpg Summer-Time-WebIF-Schedule.jpg
For the caps, I have added two more scheduled events, one 5-day manual event (slot 2) entered by the WebIF, and one 5-day manual event (slot 9) entered by manually adjusting a new event entered directly through the PVR, both entered AFTER the change to BST.

I note that the rsv.db start times for non-AR recordings appear to be interpreted by the HDR-FOX as "local times" with no conversion to BST taking place when it displays these times on its schedule screen, regardless of whether the recordings were programmed before or after the time zone change.

On the other hand, the WebIF appears to be adding 1 hour to those start times, FOR ONLY THOSE RECORDINGS which were programmed before the time zone change. I should also note, in case it makes a difference to what might have happened, that those particular schedules HAVE gone through a backup and restore cycle since the time zone change.

I have not attached a cap of the PVR's Schedule Screen, but have listed below how this matches the WebIF display.

The following events are all displayed by the WebIF as starting one hour after that displayed by the PVR, and were all programmed pre BST, though, technically, I guess, subsequently reprogrammed after the BST change by the restore process:

Slots 4,15 - Old (1/7) Weekly events
Slots 3,19,7 - Old (5/7) Weekday events

The following events are all displayed by the WebIF as starting at the same time as displayed by the PVR.

Slot 0 - Initially displayed by WebIF as 0530, but corrected itself to 0430 after backup/restore
Slot 1 - A Reminder
Slot 2 - New (5/7) Weekday event programmed thru WebIF
Slot 9 - New (5/7) Weekday event programmed thru PVR
Slots 6,11,10,5 - All AR events

It may be interesting to compare the rsv.db entries for slots 19,2,9, and 7 - these are adjacent on the sorted-by-szsttime screen cap. Slots 2 and 9 are the ones entered after the clock change. They all cite the correct "local" time and seem identical in structure apart from the hsvc field which looks to me like a collection of flags. I'm obviously not familiar with what these flags are, but could one of them be responsible for the WebIF's different interpretation of the szsttine field?
 
I'm not to know what your experience is, but nonetheless the original post seemed to me to be light on specific detail - ie how exactly to recreate the problem. af123 is still waiting for your RS identifier...
 
Webif gets the data directly from the PVR database so this looks like a problem with interpretation of those data. IIRC, prpr reported something similar at the last clock change.

Can you provide your RS Unique Identifier for this device? That can be found on the settings page within RS. I can then have a look at the database and see what's going on. There aren't many chances to look at this kind of problem : )

Whoops, didn't see your msg until after I'd posted my previous reply. If I've read the page correctly my RS Identifier is 4251932388 . I was thinking about deleting and recreating the manual events to make sure they worked correctly, but since it looks like the PVR has got it right at least, I'll refrain from doing that whilst you're scrutinising the database.
 
The database screenshots you've posted + the other information should give me what I need, thanks for that.
I'm away from home at the moment so will have to wait until tomorrow to investigate properly.

(hsvc is just an internal representation of the MUX and Service, not a set of flags). There are sometimes non-printable characters in the szsttime field which appear to be flags of some sort.
 
The database screenshots you've posted + the other information should give me what I need, thanks for that.
I'm away from home at the moment so will have to wait until tomorrow to investigate properly.
.
Thanks. Note, I will be adding more scheduled events to the system later today. I'm assuming that doing so won't perturb the existing discrepancies.
 
Thanks. Note, I will be adding more scheduled events to the system later today. I'm assuming that doing so won't perturb the existing discrepancies.
No, thanks - I have what I needed from your post and screenshots.

The web interface and RS use the nsttime field to show the first instance of any event, correcting for BST as appropriate. For anything set as a series recording, events after the first are read from the aulEventToRecordInfo column of the table.

It looks like szsttime should be used in preference, assuming it is not all zeros.
 
I've made some changes to RS which has moved a few events by an hour. It's now showing no conflicts for you.
Could you see if it looks more reasonable now? Also on the new conflicts page (which is accessible via the Conflicts button at the top of the screen).

Thanks.

I have some webif updates queued for upload when I get back home later.
 
Had a quick look, but have to dash out. Will look more closely this evening. First impressions are that it looks good, that the conflicts page (as currently shown) looks useful, not just for conflict resolution, but also for conflict avoidance, and that I notice that two recordings on at the same time (Wed 22:00-23:00) don't quite line up on the chart. I'll take a screen cap of that tonight if it's not as intended.
 
Ok, I've checked all the items on the RS report, and they now all seem to be as intended. I'm not sure if the conflict detection page as currently displayed is how you mean it to finish up, but if it is, it looks exceedingly useful. The only thing I've noticed is that the individual event bars seem misaligned slightly to the right by an amount which is greater the fewer events there are to the left of the event in question. I've attached a screen cap, and you'll notice that,

* the evening Stargate repeated event starts at 18:45, but the first occurrence of this event (on Monday) has no events to its left and looks if it starts at 19:00

* the two last events on Wednesday both start at 22:00 (and are both the same length), but the one labelled "Crimina" (which has just 2 events preceeding it) appears to start a little later than the one labelled "Grantch" (which has 8 events preceeding it).

Summer-Time-RS-Conflict-Detection-page.jpg
 
I made some more changes to RS last night to try and track down this alignment problem. Things have definitely improved now, with events sitting properly within the hour guides on the top bar (see my schedule below). Kirbett's schedule still shows alignment problems which I think are related to the short children's programmes and the number of pixels available in for each hour when most hours have some activity in them. I'll continue to look at this as I get time.

upload_2016-4-7_12-46-43.png
 
It may be the same issue, but I also see an alignment problem:

Screen Shot 2016-04-08 at 1.41.03 am.png

Notice that on Thurs, everything is left-shifted a little. This would seem to be caused by the filler-gap after the first entry being a little too narrow.

[and please don't blame me for the programme choice; it's the girls :)]
 
Thanks, that's a good one for me to work with. I notice that Friday is back in line but Thursday is still offset.
 
That one should look ok now.
It was due to the first recording on Thursday starting at 0005 - it couldn't show a skip box before that as with only 50 pixels per hour (for that schedule) 5 minutes is only 4 pixels which is taken up by the padding and border.
 
That one should look ok now.
It was due to the first recording on Thursday starting at 0005 - it couldn't show a skip box before that as with only 50 pixels per hour (for that schedule) 5 minutes is only 4 pixels which is taken up by the padding and border.

Yes, that's cured now, thanks.

I've now got another mis-alignment - not sure if you want this here, or in one of the other threads?

Screen Shot 2016-04-09 at 1.38.25 am.png

Note the event Porridge on the second tuner on Tue 12th. Although it starts at 10pm, like all the others, it is offset to the right a little.

Unique Identifier 9202731965
 
Should look better now. Let's move anything else back to the new RS conflict detection thread.
 
Back
Top