recorded programme durations gone wrong

[johala_reewi]

Recently I have noticed that the reported duration of recorded programmes is going wrong. Tivo either shows the duration as 0:00 or 0:05 or it has the correct duration. The full programme (plus any endpadding) is always there. Looking in MFS browser, it seems like the wrong stoptime has been recorded. For example:

StartDate = 13990
StartTime = 41698
EndPadding = 1200
ActualShowing = 1731589/13 1731589/15
Score = 5943
Part = 1731589/12 1731589/14 1731589/16
StopDate = 13990
StopTime = 41701

Which gives duration 3 secs!!
And:

StartDate = 13990
StartTime = 9598
EndPadding = 1200
ActualShowing = 1731556/13 1731556/14 1731556/17 1731556/19
Score = 5976
Part = 1731556/12 1731556/15 1731556/16 1731556/18
StopDate = 13990
StopTime = 9901

Which gives duration 303 secs (5 mins).

StartDate = 13988
StartTime = 4198
EndPadding = 1200
ActualShowing = 1727531/13 1727531/14 1727531/18
Score = 5967
Part = 1727531/12 1727531/15 1727531/16 1727531/17 1727531/19 1727531/20
StopDate = 13988
StopTime = 8700

which is 75 minutes (correct)

Any ideas?

[ColinYounger]

Are you running the solaris folder hack? I found some 'oddities' like this in my NPL when I removed it.

[johala_reewi]

Not running the folder hack. I have noticed that programmes with duration times of 0:00 and 0:05 also expire as soon they have recorded and ones with the correct duration expire after 2 days (normal).

[RichardJH]

Not running the folder hack

What about Mikerr's Sort Now Playing hack. I run that and have found that it gave me some of the same problems.

[solaise]

Does anyone have any more details of any possible sortnp/newfolders problems? - from recollection sortnp doesn't touch the times of recordings although I think older versions could mess up the duration of recordings that ran over midnight by getting the EndDate wrong - I think Mike fixed this in the latest version.

NewFolders uses the duration from the Showing object whenever it adjusts the time so if that was originally wrong I guess the duration could subsequently be messed up (which might be what Colin reports ). NewFolders traces every date time update as I wanted to trap any errors in this area.

Uninstalling NewFolders could also mess up the duration of recordings that span midnight.

Having read this post I have been through the NewFolders code and checked all the recordings I have without seeing any problems - which I know doesnt prove anything!;)

If there is a problem with expiration of shows then what are the values of ExpirationDate ExpirationExtended and Expiration Time? I am fairly certain sortnp never touches these (except when restoring deleted shows) and NewFolders only adjusts these values for Folders so as to turn on the green blob when a new show arrives. So neither seems to match what the OP reports.


<I for forgot to add this>
I noticed that the StartTime of a Recording is often a few seconds in advance of the StartTime of the Showing so the example given of a duration of 3 secs does fit with the EndTime being set to to the StartTime from the Showing.

[ColinYounger]

Solaise - first, sorry for getting your name wrong earlier. I was in a hurry.

Secondly, I haven't reported anything to you directly as I couldn't (also didn't want to) reproduce anything, and the folders concept was too much for SWMBO. :o

What I did see was a problem making a series into a folder. Some episodes were put into the folder while others stayed in the NPL - I guess there was a difference in series ID or something.

This caused confusion and consternation on the main TiVo (where I get lots of hassle if I 'play') and I removed NewFolders. That then left some rogue entries calling themselves 'folders' when they're actually episodes, some entries with the wrong duration and many with the wrong dates (even though I ran the restore details option). I've just put it down to experience right now as I haven't the time to experiment further.

But enough of me - I didn't mean to hijack the thread. Sorry johala_reewi!

[solaise]

Err yes - trying to get back on thread!

I can only think of three things that could cause what Johala is seeing

1. The recording was originally ok but a hack then went and changed the times. The most likely reason for a hack doing this is because it is trying to change the display order like the folders/sort hacks. But I cannot see any reason for these to alter the Expiration Dates as well.

2. Something changed the time on the Tivo so that when it came to set the End Time it calculated a different time - seems very very unlikely!

3. The Tivo created the recording like that. I have never seen anything like that - were there any errors in tvlog tverr? Could it have thought that it lost the signal - e.g on the initial channel change? I dont know what it would do in those circumstances. That kind of fits with the 3 seconds duration but losing the signal repeatedly after 5 mins seems less plausible...

(Oh and thanks Colin - thats useful info)

[johala_reewi]

It is nothing to do with the sorted/now playing because I haven't tried that. It might be a hack issue (I have a number of those) and might be something that happened during development of xtivoweb. It does seem to be number 3 from solaise, tivo created it like that. The latest crop of recordings show:

Recording 1729568/10 {
Version = 48
BitRate = 0
ExpirationDate = 13990
ExpirationTime = 79201
ProgramSource = 1511808/-1
RecordQuality = 75
SelectionType = 9
Showing = 1729568/11
StartPadding = 300
StartDate = 13990
StartTime = 78898
EndPadding = 1200
ActualShowing = 1729568/14 1729568/15 1729568/18
Score = 5932
Part = 1729568/12 1729568/16 1729568/17 1729568/19 1729568/20
StopDate = 13990
StopTime = 79201
State = 4
StreamFileSize = 2162688
IndexUsed = 1729568/11

Duratino 5 mins and the expire date/time is the same as the stop date/time

Recording 1730438/10 {
Version = 31
BitRate = 0
ExpirationDate = 13990
ExpirationTime = 70201
ProgramSource = 1455368/-1
RecordQuality = 75
SelectionType = 9
Showing = 1730438/11
StartDate = 13990
StartTime = 70198
EndPadding = 1200
ActualShowing = 1730438/13 1730438/15
Score = 5947
Part = 1730438/12 1730438/14 1730438/16
StopDate = 13990
StopTime = 70201
State = 4
StreamFileSize = 1531904
IndexUsed = 1730438/11

Duration 0 and again expire date/time same as stop date/time

Looking ahead in todo...

Recording 1731590/10 {
Version = 2
BitRate = 0
ExpirationDate = 13991
ExpirationTime = 39901
ProgramSource = 780389/-1
RecordQuality = 75
Score = 5943
SelectionType = 9
Showing = 1731590/11
State = 6
DeletionDate = 13992
DeletionTime = 41700
IndexUsed = 1731590/11

Showing 1731591/11 {
Bits = 512
Date = 13991
Time = 41700
Duration = 1800
Program = 1730830/-1
Reason = 2
Station = 5963/-1
IndexUsedBy = 1731591/10

The recording expiry time is the same day as the showing ??

Here is one that is usually OK

Recording 1733341/10 {
Version = 2
BitRate = 0
ExpirationDate = 13993
ExpirationTime = 54000
ProgramSource = 1645474/-1
RecordQuality = 75
Score = 5992
SelectionType = 9
Showing = 1733341/11
State = 6
DeletionDate = 13997
DeletionTime = 54000
IndexUsed = 1733341/11

Showing 1733341/11 {
Bits = 514
Date = 13991
Time = 54000
Duration = 3600
PartCount = 2
PartIndex = 2
Program = 1731998/-1
Reason = 2
Station = 5819/-1
IndexUsedBy = 1733341/10

The expiry date is two days after the showing date (correct).

[TCM2007]

Depends on the SP settings and the state of your hard disk. A "Keep only one" recording will expire two days (I think) before the next showing. With regularly shown shows, it can have expired as soon as it's recorded.