Recording ended too soon

[WKleeven]

Where do you get your epg-data from? Have you checked that there is not a "+02:00" or "-02:00" in the epg-.xml file?

I tried another epg-source I can easily look into. EPG data correct. With that epg-source same problem.

If the recording times a listed wrong in either the Recording screen or TV Guide, then it sounds like either your EPG source is supplying the wrong times, or you dont have your timezone set correctly, or you dont have it set to auto adjust for daylight savings.

Timezone is correct, EPG data is correct, daylight savings is also correct.
In tvguide and in recording screen things are okay. Only in the db3-file things are wrong and so are the actual recording times.
Furthermore, it seems that starting time might be correct, but ending time like the wrong time in the db3-file.

So, I tried GB-PVR 1.3.11 and there's everything normal. In tvguide, recordings as well as in db3-file.
The problem seems to be that NPVR writes the data wrong into the db3-file. At that since I installed windows 7 SP1.

[sub]

Timezone is correct, EPG data is correct, daylight savings is also correct.
In tvguide and in recording screen things are okay. Only in the db3-file things are wrong and so are the actual recording times.
Furthermore, it seems that starting time might be correct, but ending time like the wrong time in the db3-file.

If it's showing the right times in the recordings screen and tv guide, then everything is ok in the db3 file. The uses UTC for data in the database, and this is ultimately the source of the right times you're seeing in the screen, so sounds like there is nothing wrong with that.

So, I tried GB-PVR 1.3.11 and there's everything normal. In tvguide, recordings as well as in db3-file.
The problem seems to be that NPVR writes the data wrong into the db3-file. At that since I installed windows 7 SP1.

GBPVR stored local times in it's database. NPVR stores UTC instead.

This stuff hasnt changed in the last year, and no body else has been reporting problems with date/times being shown wrong, so doesn't sound like there is anything wrong with this stuff.

[mvallevand]

Only in the db3-file things are wrong and so are the actual recording times.

As BrettB wrote, the times in the database are in UTC not local time. If they display correctly, the database is ok. I still think sub needs to look at your NRecord logs to see all the trace errors.

Martin

[sub]

WKleeven, if you can zip and attach your db3 file, I'll check why you're getting this error message in your logs:

2011-10-09 02:11:53.490 [INFO][8] UpdateAllRecurringRecordings()
2011-10-09 02:11:53.490 [INFO][8] Deleting existing pending season recordings
2011-10-09 02:11:53.526 [INFO][8] UpdateRecurringRecording(62, 'Bouw een nieuw leven'):
<Rules><EPGTitle>Bouw een nieuw leven</EPGTitle><ChannelOID>7245</ChannelOID><ChannelName>RTL 4</ChannelName><StartTime>2009-05-16T13:30:00.0000000Z</StartTime><EndTime>2009-05-16T16:30:00.0000000Z</EndTime><PrePadding>5</PrePadding><PostPadding>15</PostPadding><Quality>1</Quality><Keep>0</Keep><Days>SATURDAY</Days><TimeslotStart>2009-05-16T12:00:00.0000000Z</TimeslotStart><TimeslotEnd>2009-05-16T15:00:00.0000000Z</TimeslotEnd></Rules>
2011-10-09 02:11:53.994 [ERROR][8] Unexpected error in UpdateRecurringRecording(): System.NullReferenceException: De objectverwijzing is niet op een exemplaar van een object ingesteld.
bij NShared.EPGManager.LoadListingsMatchingTitle(Channel channel, String title)
bij NShared.RecordingServiceProxy.UpdateRecurringRecording(RecurringRecording recurringRecording)
2011-10-09 02:11:53.994 [INFO][8] UpdateRecurringRecording(64, 'Derek Ogilvie: Family Circle'):
<Rules><EPGTitle>Derek Ogilvie: Family Circle</EPGTitle><ChannelOID>7245</ChannelOID><ChannelName>RTL 4</ChannelName><StartTime>2009-05-21T18:00:00.0000000Z</StartTime><EndTime>2009-05-21T21:00:00.0000000Z</EndTime><PrePadding>5</PrePadding><PostPadding>0</PostPadding><Quality>1</Quality><Keep>0</Keep><Days>THURSDAY</Days><TimeslotStart>2009-05-21T16:30:00.0000000Z</TimeslotStart><TimeslotEnd>2009-05-21T19:30:00.0000000Z</TimeslotEnd></Rules>
2011-10-09 02:11:54.025 [ERROR][8] Unexpected error in UpdateRecurringRecording(): System.NullReferenceException: De objectverwijzing is niet op een exemplaar van een object ingesteld.
bij NShared.EPGManager.LoadListingsMatchingTitle(Channel channel, String title)
bij NShared.RecordingServiceProxy.UpdateRecurringRecording(RecurringRecording recurringRecording)
2011-10-09 02:11:54.025 [INFO][8] UpdateRecurringRecording(65, 'Top Gear'):....

[WKleeven]

Here it is.

[sub]

This patch addresses error messages that were shown in that log when updating the EPG.

The errors was caused by recordings that pointed to a channel that now longer existed in the database. It'll no cause an exception. If a channel referred to in a recording was not found, then now it'll look for another channel with the same name, and still now found, it'll just log a message that the channel wasnt found, rather than having a null-pointer exception when it tries to work with the non-existant channel.

[WKleeven]

I am not sure what caused the incomplete recording this morning. But when trying to find a cause, I looked at the db3-file and didn't know about UTC-times in NPVR in it instead of local times (like in GB-PVR). BrettB talked about GMT+2, which made no sense to me. I think it's because it's GMT+1 and +1 for daylight savings time.
Then some errors showed up about recurring recordings, which also made no sense to me because I didn't have a problems with recurring recordings.
I understand the errors occurred when updating the epg data. I tried the bugfix in post #16. Then updated the epg. I see error in the logs, don't know if it's another kind of error. Attached the logs.

I saw something else:
When making a new recording, whilst the recording is going on you can see the item in "pending recordings" (which is normal), but also in "ready recordings" and "what's new".

[sub]

Then some errors showed up about recurring recordings, which also made no sense to me because I didn't have a problems with recurring recordings.
I understand the errors occurred when updating the epg data. I tried the bugfix in post #16. Then updated the epg. I see error in the logs, don't know if it's another kind of error. Attached the logs.

The logs generally look fine now. When it updated the and processed the recurring recordings, there was a couple of recurring recordings associated with channels that are no longer in the database, and no other channel with the same name. These didnt result, just a log message saying the channel wasnt found (so of course no episodes of that recurring recording will be scheduled).

The only other error in the logs was this:

Code:

2011-10-09 23:35:23.272    [ERROR][4]    Unexpected error parsing int setting: System.ArgumentOutOfRangeException: Toe te voegen waarde ligt buiten de reeks.
Parameternaam: value
   bij System.DateTime.Add(Double value, Int32 scale)
   bij NUtility.SettingsHelper.CheckForConfigUpdate()
   bij NUtility.SettingsHelper.GetSetting(String xpath, String defaultValue)
   bij NUtility.SettingsHelper.GetSetting(String xpath, Int32 defaultValue)

This error isnt critical, and can safely be ignored. It's done intentionally when you have multidec plugins enabled. Its done because the ffdecsa library leaves the floating point unit in an inconsistent state, so application forces this datetime add operation to .net it to reinitialise it.

I saw something else:
When making a new recording, whilst the recording is going on you can see the item in "pending recordings" (which is normal), but also in "ready recordings" and "what's new".

That's normal. That's the way the community wanted it.

[WKleeven]

Still don't know why the recording didn't complete, but for now case closed. Thanks for the help everybody.

[WKleeven]

Unbelievable, but true. Yesterday, almost exactly one year later than the problem I had that made me start this thread, I recorded the same broadcast (F1 Japan) and I got the same problem (digital recording, encrypted, SD)!

I understand now about UTC. In the db3-files start end endtime are in UTC and correct. I attached the logs, but there is not much info from yesterday anymore.
The filename suggests a recording from 13.00-16.00 which is correct (RTL GP Formule 1 - Japan (race)_20121007_13001600). In the db3-file you can see prepadding of 16 minutes and postpadding of 30 minutes. That's a total of 03:46:00.
But, in windows explorer you can see (see attachment) the length of the video is only 01:48:06 which is almost 2 hours short.

You know what it looks like? Start_time in db3-file (11.00, that's 13.00 local) is correct and in UTC, but end_time in db3-file (14.00) is in local time, not in UTC!

Wim