Posts: 415
Joined: Jul 2011
Reputation:
2
Has nobody else experienced this?
Posts: 34
Joined: Jun 2011
Reputation:
0
Same here. I'm using openelec 5.0.8 and every new recording will be dated 1970 until I restart VDR or relaod the recordings. Remember I had the same issues on my last system running ubuntu, so it's not related to openelec only.
Posts: 415
Joined: Jul 2011
Reputation:
2
Yep still happens with 5.95.2
Posts: 6,810
Joined: Jul 2010
Reputation:
198
The like to the problem report in post #1 mentions that only daily timers are affected. Can you confirm this? Are only certain kind of timers affected?
Posts: 34
Joined: Jun 2011
Reputation:
0
can't confirm this. it happenes both on daily timers (also not always) and "usual" timers. im starting to think that this is also an issue with vdr, since the affected recordings show no content data on the osd and live plugin. so it seems theres something wrong with the handling of those recordings inside of vdr and not just vnsi. though vnsi messes up with the date in addition.
Posts: 34
Joined: Jun 2011
Reputation:
0
not totally sure yet, but further testings showed that it might depend on the recording disk state. if its sleeping and has to wake up for the recording to start first, the problem with the wrong date (or missing content in vdr) occurs. if the disk is active everything is ok. so this would be a vdr related issue then.
@username145:
can you confirm this with your setup?
Posts: 6,810
Joined: Jul 2010
Reputation:
198
are you using outdated SystemV or systemd. With systemd you have much more control of the startup process.
Posts: 34
Joined: Jun 2011
Reputation:
0
im using openelec 5.0.8 which uses systemd i think
im pretty sure now its on the sleeping hard drive where the recordings are saved. it goes to standby (not the whole system, just the the hard disk!) after inactivity and wakes up when a timer starts recording. have 3 daily timers in a row. the disk wakes up for the 1st one and is still active for the 2 following. the date "bug" occurs always with the 1st timer but never with the other 2 afterwards.
Posts: 6,810
Joined: Jul 2010
Reputation:
198
thanks for this detailled report. I'll ping a OE developer.
Posts: 34
Joined: Jun 2011
Reputation:
0
I was wrong. It's a problem of vnsi since the problem does not occur when it's turned off or doesn't have any clients connected. I was able to figure out that it happens when vnsi wants to reload the list of recordings. As I said before, it only happens when the disk was at sleeping state though. VNSI reacts on Recordings.StateChanged and wants to update the recordings. Inside of the iteration, vnsi can't access the RecordingInfo of the recording that has just started. Somehow by trying to access that data, vdr is messing something up too and won't show the content information (can't even open the info file anymore) of the affected recording.
I dunno if that helps. I'll also try to look inside of the code again tonight to figure out where the problem is. Could it be, that vnsi is too fast in accessing the Recordingslist?
Posts: 34
Joined: Jun 2011
Reputation:
0
Found the solution to the problem even though not really knowing why it is:
cVNSIClient::processRECORDINGS_GetCount() calls Recordings.Load() and this is somehow messing something up in the special case I described before (disk at sleeping state when recording starts). After removing this call all the informations are right and immediately shown as it should be.