[VU+ Duo] Recordings Duplicated

[psitech]

I have noticed that when I record I quite often get the two recordings at the same time of the same event. Generally one stops after a time and is incomplete. This is not just annoying but I think it may stop another recording happening if there is an overlap of programs set to record. This happens on both single instances and repeats. I don't use auto-timer. Today it happened twice, one for a channel 4 film and another for one on BBC2.

Any ides what ideas on what is going on and how can I stop it?

 

[Warpedandy]

i have the same problem annoying me to.

 

[psitech]

Further investigation of the duplicates from today. The recordings were broken part way through. Playing the recording, at the end the stream stutters and halts, looses some then restarts. The second recording starts after the other one stops and continues to the end. So looks like this, for me anyway, is caused by a recording failure. I will check the hdd later in case it is bad blocks. Can't do it now, system is being used by family.

 

[Stanman]

Also if the recordings were unattended, check in case it crashed / some one switched the box on off.

 

[judge]

As Stanman suggests, are you sure the box didn't reboot for any reason during recordings?

 

[psitech]

View attachment Enigma2-31-03-2012_23-09-51.logView attachment Enigma2-01-01-1970_01-00-31.log

There was no crash log.
Took drive out this morning and gave it a full low level test - perfect drive - zero bad sectors.
I had a brand new larger drive waiting to go in so I have taken the opportunity to do this.

The TV was switched off when recordings started so didn't see anything happen. I do have the debug logs covering the period. There seems to be something that happened. I will attach them. Maybe someone can analyse them and determine what the problem is. The first failed recording was set for 1:20pm, the second failed recording was set for 2:00pm on Sunday 1st April.

The log file Enigma2-31-03-2012_23-09-51.log is the start one, the relevant time is near the end.
The log file Enigma2-01-01-1970_01-00-31.log is the continuation. Something odd has happened, the log file name is not the same as the others. All other logs before and after this one all have the correct date in the file name. It does look like there was a restart event but I don't know what caused it.

 

[Hamram]

Maybe your TV turns off the STB as well..? HDMI-settings...

 

[psitech]

I don't think it does turn off the STB. It was turned off 20 minutes before the recording started. My wife said that when she turned on the TV later it said something about insufficient tuners, so she changed the TV over to FreeView so she didn't use the Satellite box.

I think that the changeover of logs happened about the time recordings went wrong.

 

[Stanman]

Maybe your TV turns off the STB as well..? HDMI-settings...

SHouldn't do it outs it into standby so recordings will still work fine.

 

[Bat]

Hi,
Go into logs manager (in system/setup) and turn on Debug logs.
My money is on your box is crashing, but without debug logs switched on it deletes the log when it reboots!
Cheers,
Gavin

 

[psitech]

Debug logs are on. I posted these onto the forum on 2nd April. On that posting I did say that there looked like a restart event happened, however no crash log was produced for that. I have had crash logs produced before which I have also posted onto the forum under a different thread. I have had no feedback whatsoever on any of these logs.

Prior to the problem occurring there were no real errors shown. There was a batch of errors of the kind:
[EPGC] event b010 not found in epgcache

Then immediately before this log terminated there was:
main thread is non-idle! display spinner!

It is possible that there could have been a period where no log entries were written in between the last entry in this log and the first entry in the new log that was started with the restart of the system. The name of the log file is a bit of a giveaway as it has a 1970 date stamp in the name. Looks like it had lost track of time and was using the base date used for all Unix type systems.

The next log started with what looks like a restart event of loading. After this then it restarted the recordings.

At the end of the first recordings just prior to this restart there was an extended period of stuttering and stops and starts in the recorded stream. I can't compare the amount of time lost in the recordings between the last good bit and the start of the second recording as I do not have a clean copy of both of the films. However, I might be able to do it for one of them given time, as I used iPlayerDownloader to get one of the missing ones. The last date in old log was "Sun Apr 1 14:18:44 2012". First date found in new log was "Sun Apr 1 14:23:54 2012". That is about a 5 minute gap.

More info will be posted as I discover it. What I don't know is what is the root cause and that is what I really want to know.

What is clear is, that wherever I have found what appears to be multiple recordings of the same event, then these are continuation recordings with corruption at the ends of the parts where there is a new one following. So these are not strictly duplicated but are in fact multi-part recordings. They do however all have the same details in the listings for any given set with the same date information, this is why I initially incorrectly thought that there were multiple recordings.

It is however most likely to be a bug as no system should be designed to fail.

 

[judge]

What EPG sources have you enabled & do you have a swap file set-up?

 

[psitech]

No swap file set up. Was advised that this can sometimes be more trouble than its worth.

EPG was set up as per posting in the forum. So it has what was advised. i.e.

9. Select Update rytec providers and press ok.
10. Select Update XEPGDB providers and press ok.
12. Select the EPG source that you want to use for EPG data. Do not select more than what you actually use and need as selecting too many will cause memory issues. For the purpose of this guide we will select Open TV Providers > highlight open TV (astra 28.2), press OK to enable this provider and GREEN tick will appear.

 

[judge]

Can you set up a swap file, I know it's not always advised, but might help us with this issue.

 

[psitech]

largest swap file now set up on hdd.

 

[khan888]

psitech how did you get on? i'm having the exact same problem!

 

[psitech]

I have had no fragmented recordings since I added the swap file. However, I did stop time shift at the same time so I can't be sure which solved it. Sorry for the delay in posting, I have just returned from a holiday.

 

[AndSve]

Enigma2-31-03-2012_23-09-51.logEnigma2-01-01-1970_01-00-31.log
::
The log file Enigma2-31-03-2012_23-09-51.log is the start one, the relevant time is near the end.
The log file Enigma2-01-01-1970_01-00-31.log is the continuation. Something odd has happened, the log file name is not the same as the others. All other logs before and after this one all have the correct date in the file name. It does look like there was a restart event but I don't know what caused it.

Enigma debug logs named Enigma2-01-01-1970...

A debug log named Enigma2-01-01-1970... is created whenever the box is powered off or power is lost.
The reason is that the onboard RTC (realtime clock) has no backup battery.

Proper time is retrieved from satellite signal, and on first start after power loss, Linux time i zero.

If debug log is activated, Enigma2 is started (/usr/bin/enigma2.sh), piping its output to a log-file udsing current time in the name.
Enigma2 adjusts the clock when a satellite signal is available

During the startup there is also an update to clock outside Enigma2 using ntpdate, but this update process isn't finished before Enigma2 is started so the debug log is named 1970-something.

The clock is not reset during Enigma2 restart, box reboot or deep standby (system shutdown), as the RTC is still powered and working.
In deep standby, it is the RTC that initiates the system start on time.