A possible bug in vrecorder?

[heyrick]

Hi,

Last night I recorded a film called "Zatoichi". Lovely dance sequence at the end. Utterly no relevance to the plot, but it looked like everybody had loads of fun making the film. Anyway, Channel4 decided not to mention in the schedule some junk stuffed in between the end of the film and the next programme. As it was about 15 minutes of stuff, I tried pressing [Stop] to see if I could drop out of a recording.

It didn't work. Oh well, I'll let it finish. Cut it out later.

About an hour later I am ready. But, WTF? The red light is still on. I plug in the USB capture-box and the screen is blank. Ummm...? So I telnet into the OSD and it is working really slowly. It feels like a recording is still on-going, but after doing "df" a few times, the size of the recorded file (about 1.5Gb) isn't increasing.

I try killing the vrecorder tasks. They look like "vrecorder -schedule blahblah" in the "ps" output.

They go, to be replaced with a task:
"[vrecorder]"
in the square brackets. I've seen this for the Ingenient stuff, so I guess square brackets mean low-level important stuff?

Kill won't touch it.
Kill -9 won't touch it.
reboot doesn't.
reboot now doesn't.
reboot followed by numerous expletives doesn't, either, though it gave me a small giggle to see it listed in the process list.

I had to power cycle, this thing obviously froze at the point of trying to finalise the file.

Which meant:
1. The file was 1.5Gb of crap, I can't believe the MP4 format doesn't have a standard header to allow software to try to piece together the file frame-by-frame if necessary.
2. The FAT was corrupt too, the file and its reported size were different.

This is the first time I have had my OSD freeze up and mess up a recording (and it's been like ten months of regular use). I've had one USB stick fail recordings after the first minute upon first insertion, but this seemed specific to that USB stick. Otherwise, trouble free and reliable.

It is also the first time, I can remember, I have attempted to 'stop' a scheduled recording. I wonder if the IR commands are supposed to be ignored, but it set some flag or state that messed up the auto-stop? As you can imagine, I don't plan to delve too deeply into this, however I set up another similar recording today and the OSD is green-lighting me, after recording nearly two hours of Channel 5 (ugh).

Has anybody else experienced the stuck-on-red-light with blank display on closing a scheduled recording? Did you press anything on the remote?


Best wishes,

Rick.

PS: If you're wondering why I set the recording, it finished like 5am French time, I hadn't actually planned to stay up and watch it. Typically, the one thing I wanted to keep (I even bumped up to 1500kbit for this film!) is the one thing that isn't repeated a dozen times. No worries, though, for I ordered a copy today from Amazon's Used&New. Cost me €1,76 for the DVD, and €2,76 in postage. <giggle>
Oh, and 'cos my memory is like a Swiss mountain cheese (white, smelly, and full of holes), I better drop this in here as a "note to self" - http://www.allsubs.org//search-subtitle/zatoichi++2003+en/20

[pfft2001]

I've had all of these things happen to me.

It is not that rare for the box to get hosed up while recording and need to be power cycled.  For example, I sometimes see this happening when I do my weekend Scheduler fix-and-resync.  Sometimes, the resync doesn't completely "take" and the result is that the scheduler event fires anyway and when it does, it usually hoses the box.

FWIW, I don't think it is possible to "pause" recording.  My experience is that pressing Stop while it is recording causes the recording to Stop.  This is useful, for example, if you don't know how long the thing you recording is, so you set the record time to something very long, then when the show ends, you hit the Stop key.

Incidentally, when it shows up the process list in brackets (like [vrecorder]) I think that means the process is either a zombie process (Google it - this basically means a process that is already dead, so you can't kill it) or is in a "device wait" (which means it can't be killed by any action short of power cycling).  As you would expect, these are "standard Linux" things.

Finally, yes, I agree with you that it is annoying that the MP4 file format is a "either it works or you end up with nothing" format.  It seems it ought to be possible for it to be otherwise.

[greyback]

Yep, I've had this too.

I've no idea where the problem could be though, perhaps the DSP hangs, and I've no idea how to reset it. Also it is terrible that the file is useless if not finalised, or even that a non-finalised file can be repaired/recovered.
-G

[heyrick]

Posted here as it is a possible other bug in vrecorder, or maybe not? [OSDng (/Arizona?)]


Okay. I had an SD card installed, but I removed it to watch some stuff recorded in the week. When I came to record something right now, I saw the OSD hung on "starting application".
Why?

Because on Friday night the OSD would have tried to start a scheduled recording, The Mentalist. I am not bothering to record as Channel Five went from the first third of season three to somewhere in the middle of the first season. Go figure.

Anyway, I suspect that the recorder failed to start because there was no media available. I know a check is made when a recording is scheduled, but perhaps it ought to be verified again when actually starting the recording. In addition, if we're going to work on the schedule system (I know g. would like something cleaner), I think it would be a good idea for the scheduler to know the state of the recording and if it has aborted early or completely failed, so it can flag failed recordings.

G. - an idea for your experiments re. QtQuick - it might be an idea to see if there is a way to detect if a task has stalled, so it can be dealt with automatically if it has.


Best wishes,

Rick.

[greyback]

Anyway, I suspect that the recorder failed to start because there was no media available. I know a check is made when a recording is scheduled, but perhaps it ought to be verified again when actually starting the recording.

I was of the opinion that the check is indeed performed before recording. I'd say in the code, it tries to open the file specified, which will return false, and that error is caught.

In addition, if we're going to work on the schedule system (I know g. would like something cleaner), I think it would be a good idea for the scheduler to know the state of the recording and if it has aborted early or completely failed, so it can flag failed recordings.

I recall the existing scheduler could list recordings in red with a line through them, to indicate they failed for some reason. I think it can already do this.

I suspect something else went wrong. That SD card old? Maybe it's had too many writes and is starting to fail?
-G

[heyrick]

Just to clarify... There was NO media present (the SD card was in my netbook computer).

[pfft2001]

Just to clarify... There was NO media present (the SD card was in my netbook computer).

Correct.  And to clarify, I get the same thing if I have a scheduled recording setup to record to the network (which is the only type of recording I do) and the network is down or unavailable or whatever when the scheduled task fires.  The whole scheduler system locks up until I get in and fix things manually and (the most important thing) do a "re-sync" operation (yes, the good old re-sync problem rearing its head once again).