Creating an unfinalised video file

[heyrick]

Hi,

Is it possible, perhaps with a judicial kill -9, to abort the video recording and leave the file without its TOC or correct header? Would I want to kill vrecorder or attempt to kill one of the recording processes?

I would like to look at some short failed recordings, without going the route of power-cycling, which can have unexpected filesystem integrity consequences.


Best wishes,

Rick.

[ChadV]

Sounds like it should work just fine to me.

[heyrick]

Hi,

The other day, I had a timed recording I wanted to abort (fault in the satellite receiver, long story...). As the Stop button didn't, I tried to kill the vrecorder process. I picked the first one in the list (there were three). After a few moments, the screen went black and the vrecorder processes (all of them) ended. The menu reappeared, and then the OSD UI froze. The red indicator was still on.

I had to issue reboot to regain normality (damn, as I'd shoved in a 32Gb SD card and there wasn't much on telly this winter, I had an uptime running to some 60-odd days).

Any ideas as to what else might need to be killed, or maybe started, in order to regain control if a scheduled recording is to be aborted? Rebooting the thing just seems so... brutal.


Best wishes,

Rick.

PS: However, a result - I do now have an unfinalised video file. I'll have to play around pasting on a minimal file/codec description, see if I can get anything to recognise it as a video file...

[pfft2001]

FWIW, I always assume (and take it as a given) that whenever the OSD locks up during a recording (remote non-responsive and red light on [when it shouldn't be]), that I have to reboot.  I don't even think of it as being that much of a hardship anymore.

Also, I always do a power-cycle reboot - not just a software reboot.

BTW, and somewhat related, my OSD has developed a periodic problem where it stops executing scheduled recordings.  I think I've written/posted about this before.  When this happens - when it stops firing (*) - the only solution is to reboot.  And what I find, is that I have to reboot twice, following the following steps:

1) Power cycle reboot.
2) When it comes back up, it gets stuck at one of the "white text" screens - I think the one that says something about the "power of community".
3) At that point, I telnet in (note that the telnet daemon is up and running at that point) and issue the "reboot" command.
4) The box reboots and then the scheduled recordings start working again.
5) Until they stop working again (about a week).

I've seen this before and I think that what happens is that it gets worse and worse until eventually you have to do a Firmware refresh (aka, upgrade).  That then fixes it (until it happens again...)



(*) What's funny is that these are "Daily" recordings - and the date gets updated - i.e., advanced to tomorrow - even though the recording didn't happen.  I think it is a memory problem - that vrecorder is being launched but crashes due to lack of memory or something like that.

[greyback]

Don't forget that most of the recording work is done on the DSP.

I think killing vrecorder just stops it fetching data from the shared-buffer with the DSP. This probably makes the DSP hang, waiting for the buffer to be cleared. There is no easy way to reset the DSP afaik, since e're missing public APIs and docs for any form of DSP control.
-G

[greyback]

FWIW, I always assume (and take it as a given) that whenever the OSD locks up during a recording (remote non-responsive and red light on [when it shouldn't be]), that I have to reboot.  I don't even think of it as being that much of a hardship anymore.

Yep, I share this. Soft-reboot may not properly reset the DSP, thus causing the DSP initialisation (loading kernel modules) to hang on boot.

Why this happens I've no idea. I had quite reliable recording when using network shares, but SD cards were not so good. Possible if vrecorder cannot write out fast enough, it gets overwhelmed, and then DSP gets stuck. Or OOM kills it. Hard to know. Neuros spent a lot of engineering time working on it, to some improvement but not perfection.
-G

[heyrick]

Yep, I share this. Soft-reboot may not properly reset the DSP,

Hehe... I get the same thing with my Livebox. Once upon a time a reset used to invoke an actual reset signal which, you know, reset stuff. I find if my Livebox (1.2 mini) is acting up (namely, downloads crawl and wifi devices are randomly kicked off or assigned bogus addresses), a system restart does not fix it. Heaving my fat ass into the living room to yank the power cord... THAT fixes it. Of course, the thing takes, like, five minutes to reboot. <sigh>

Oh, and FWIW the Livebox reset button is some sort of software thing for there are (rare) times when the thing locks itself solid with all the LEDs lit, and you can press the reset button all day and nothing'll happen. Was it so hard to buffer the switch to pull on the !RST line? Evidently, yes...
 
<thinks> Does the OSD have a reset option anywhere? I'll have to find where I stashed the schematic.

I had quite reliable recording when using network shares,

My only experience with networking with the OSD was in trying to copy a recording to a NAS (a Windows share). It CRAWLED. I mean really, we're looking at something like five hours for a 1Gb file. With the OSD effectively single-tasking AND no status or "how much done" counter or anything (just that bloody copy-paste metaphor). As I needed to go to work, I aborted that, put the media into my eeePC and whipped it over to the same machine in around four minutes.

Ever since that... experience... I've not made any attempt whatsoever to use networking for anything other than telnet.

but SD cards were not so good.

Apart from the highish-bitrate long-recording faults, all two of them, I have found SDs to work okay. What class were the cards that failed? I suspect the el cheapo class 2 cards aren't fast enough. Mine are class 4 or class 6; which is a sort of indication of how quickly they can function (though about as open to liberal interpretation as any benchmark).

Possible if vrecorder cannot write out fast enough, it gets overwhelmed, and then DSP gets stuck.

Hmmm... I'm not exactly a lover of the Ingenient code; you'd have thought that given the OSD is being pushed fairly hard (i.e. it can't actually hack D1 video, so what it can do is probably using much of the available grunt) you'd have expected them to consider a way to cater for this other than the "oops, oh crap" response... But then it'd be but a few lines extra code to support brightness, contrast, sharpness, etc etc. <grumble><grumble>

Neuros spent a lot of engineering time working on it, to some improvement but not perfection.

I'm just kinda glad it supports SDHC. I'm running a class 10 (whoo!) 32Gb card and it's working fine. I think the saddest thing is that I bought it back at the beginning of December and it's only now starting to get full. Yes ladies and gentlemen, British Christmas season telly really was that dire...
[and the spare I bought is 2/3 full of stuff from this season's animé lineup - Chihayafuru, Another, Mirai Nikki, etc etc; it's just a damned damned shame about MegaUpload as the options these days actually manage to run slower than an old-fashioned dial-up modem!]

And no, the OSD can't hack even standard-res MKVs. Or MKVs at all.
But then, in a crowning moment of funny, my poor itty bitty eeePC (1.8GHz Atom) really struggles to do anything useful with H.264 at 720P, while my tiny phone (1GHz ARM) displays them on its 480x320 display without a stutter or hiccup. As MKVs, with overlaid subs. Using MoboPlayer's software decoding. But, hey, who said Intel graphics chipsets were ever any good?


Best wishes,

Rick.