Does anyone else experience this bug with VNSI?
https://github.com/pipelka/xbmc-addon-xvdr/issues/112
A bunch of searchtimer recordings show a date of Jan 1 1970 in Kodi, but with the proper date next to it (presumably because the recording folder name or info file or something contains the proper date). Only happens to some recordings, other recordings of the same show are fine. Running rPi 2 OpenELEC latest. The device is on 24/7 and network connection is solid.
Has nobody else experienced this?
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.
Yep still happens with 5.95.2
(2015-08-05, 14:14)username145 Wrote: [ -> ]Yep still happens with 5.95.2
vnsi or xvdr?
(2015-08-05, 16:25)FernetMenta Wrote: [ -> ] (2015-08-05, 14:14)username145 Wrote: [ -> ]Yep still happens with 5.95.2
vnsi or xvdr?
im using vnsi
i noticed it affects not every recording. seems kinda randomly to me. yesterday i made some test recs and the dates were all shown right. now a timer has just started and its 1970 again.
edit: live plugin and vdr osd shows the right date and time but without content from the epg...weird
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?
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.
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?
are you using outdated SystemV or systemd. With systemd you have much more control of the startup process.
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.
thanks for this detailled report. I'll ping a OE developer.
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?
(2015-08-08, 16:35)coffeecup Wrote: [ -> ]Could it be, that vnsi is too fast in accessing the Recordingslist?
Absolutely. Since I took over maintenance for vnsi I might have touched every line of code but recordingscache.
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.