DST and manual recurring recordings : wrong times !

[sub]

The problem is that internally, NextPVR does everything in UTC time (or Zulu time).

Actually, that's not entirely correct. The times for manual recurring recordings are supposed to be local times, and UTC everywhere else (like the schedule recordings created for the recurring). It's possible this was broken when we moved from .NET 2.0 to .NET 4.0, when some of default date string handling change. I remember we found several other things broken with date/times, relating to reimporting recordings, and these were fixed at the time.

Most people do recurring recordings from the guide, rather than manual recordings, so it's not as widely tested.

[Handy.Man]

Maybe look at http://forums.nextpvr.com/showthread.php...post496586
However this spring, Schedules Direct was down on Sunday morning :eek:

[johnsonx42]

Actually, that's not entirely correct. The times for manual recurring recordings are supposed to be local times, and UTC everywhere else (like the schedule recordings created for the recurring). It's possible this was broken when we moved from .NET 2.0 to .NET 4.0, when some of default date string handling change. I remember we found several other things broken with date/times, relating to reimporting recordings, and these were fixed at the time.

Most people do recurring recordings from the guide, rather than manual recordings, so it's not as widely tested.

well it's entirely correct in the sense that's what it IS doing, I tested it here. The manual recording rules are written and processed in Zulu time, with predictable results when the time zone offset changes. But I'll take your word for it that it wasn't supposed to be doing that, and it does seem like we've visited this exact subject before.

[sub]

I've made a tweak for the next release which should fix the issue. I forced it to schedule 300 days of manual recordings for my recurring recording, and the times seem to be correct before and after daylight savings.

[sub]

If you guys set <ManualRecordingDays>300</ManualRecordingDays> in your config.xml, and update the EPG, then look at the pending recordings, do you see the times go wrong in a few months, when the daylight savings next happen?

You'll obviously want to put that back to like 10 days after this test.

[johnsonx42]

I don't need to set it to 300 days, since the DST change happens in 6... if I set a recurring manual record for 5:30-6:30pm on Sundays, it's set to record correctly today and hour early next Sunday. The rule is definitely being written in Zulu time, so I don't know how it would work any differently.

wait... maybe I'm looking at the wrong thing, hold on...

[johnsonx42]

yes, the rule in the database is written in Zulu time:

Code:

<Rules>
  <ChannelOID>6960</ChannelOID>
  <ChannelName>CBS</ChannelName>
  <StartTime>2016-10-31T00:30:00.0000000Z</StartTime>
  <EndTime>2016-10-31T01:30:00.0000000Z</EndTime>
  <PrePadding>0</PrePadding>
  <PostPadding>0</PostPadding>
  <Quality>0</Quality>
  <Keep>0</Keep>
  <Days>SUNDAY</Days>
</Rules>

so how could it not be wrong when the UTC offset changes?

[sub]

I'll give you a patch to check (see pre-release).

[RolandP]

I'm getting mad... I have two computers with nextpvr, let's say a main one and a backup one.
Today, on the main one, pending recordings created by a recurring recordings are correct ! Same times in the two panels !
On the backup one, it's still one hour sooner than expected in the pending recordings panel.
???
The only difference between the two computers I can see, is that during my tests I rebooted the main one.

[RolandP]

I'm getting really mad... I cancel all the recurring on the backup machine, I recreate all and now, it's ok on that computer too !
I did that yet the day of the DST change, and it wasn't working !
No idea of what's happening, really.