Sorry for the delay in getting back to you. Been busy and fuzzy-headed. My job is now daytime hours 10am-5.45pm (no more $%$(% $£*£&%ing NIGHTS!!!!!!!!!!
) and it has been a bit of a shock coming home about the time I used to get up!
You have my email (don't you?). If you think I can help, nudge me! The latest episode of Kokoro Connect
1) Is it possible to change (or, ideally, eliminate) the 4 hour limit? I did not see it in the settings file(s) that the program manipulates. Note
that Rick has access to the source code (for vrecorder); perhaps he could check this for me.
I don't recall seeing it. To be honest, it looks as if vrecorder
simply passes all the info to the codec.
The command line parsing is here: https://svn2.neurostechnology.com/linux-r3-main-app/trunk/vrecorder/src/ui/nvrecorderapp.cpp
And the interesting inside-guts-and-gore stuff is here: https://svn2.neurostechnology.com/linux-r3-main-app/trunk/vrecorder/src/ui/nvrecorder.cpp
[especially function "NVRecorder::handleServerSelfStop
", it looks like there are some hardcoded limits]
My pet hates that (probably!?) can't be fixed:
- Given we are writing AAC audio and H.263 frames; an option to use AVI (for this is possibly close enough to pass as DivX-like) would have been nice. I'm okay with the computers/phones as they'll play back .mp4 without problem, but a lot of older hardware based things only recognise AVI.
- My recordings are anamorphic. This means it is a 4:3 ratio picture containing a 16:9 frame. This is not unusual; older (non HD) satellite recorders output this when you use the "16:9Full" option (as opposed to "16:9Letterboxed"). Widescreen DVDs are this (and accordingly can be switched to "full" mode). All it needs is for the playback device to resize the video to the correct dimensions on playback. But for this to work automatically, you need the video file to identify itself as 16:9 accordingly. [well, it would at least fiddle the PAR in the mp4 header to reflect 16:9 attributes (actual values depend upon frame size)]. I wonder if I could hack vrecorder to do this at the end of a record? It'd be less hassle than pressing 'A' half a dozen times in SMPlayer for everything I want to watch!
I think the best solution would be if it were under user control
I wish there was a telnet-friendly version. How cool would it be if you forgot to record Meh
so you excuse yourself to go to the toilet, fire up your Android phone, telnet to your OSD, and say "okay, record at this quality for the next 59 minutes".
vrecorder, and then use the "mount --bind" trick to "replace" the existing (read-only) one on the flash media.
Or for those of us with OSDng...
2) (Out of curiosity) Are there any other cmd line parameters to vrecorder, other than the tag lookup into .vrecsettings?
Looks like "temp" and "scheduler" are the options. [first link above, first function]
I hope this can be easily parsed out by looking at the source code, but of course, it'd be really nice if there was actual proper documentation.
A Real Nerd[tm] would say "the source is the documentation
It is as if the scheduler only has a 1 year "look ahead" window - it simply can't fathom anything farther away than that.
Does the scheduler really even use the year? This might explain the symptoms you are experiencing? I don't know about you, but I find this code to be a bit of a mess. Not in how it is written, but more in that parts of it are scattered around the place and it is something of a game of "hunt the function" to follow it. https://svn2.neurostechnology.com/linux-r3-main-app/trunk/scheduler/src/scheduleritem.cpp
I tell ya, if I was unemployed (and thus had a lot of time and no money to do anything), I'd consider rewriting the UI from the ground up. Of course, I'd probably make just as big a mess, only it'd be my
mess, ho ho. One thing I'd get rid of for a start is the MySQL stuff for the scheduler. A formatted data file would work - we're only recording (fairly small numbers of) user-specified recordings, this can be handled in a bunch of parse/sched functions. Anything else is just overengineered.
I would also look at exactly how much of the windowing system is necessary. That Arizona overruns the built-in 16Mb Flash is - frankly - obscene.
Take a look at https://www.riscosopen.org/content/downloads/other-zipfiles
and you'll see the ROM image for the Beagleboard is around 2Mb, and the RaspberryPi build is also 2Mb. These are compressed, it's 4Mb raw. Add to that around 10Mb of resources (a lot of which could probably be dropped as much of that is example software). You would easily get an entire full installation of RISC OS into 16Mb. So why does a stripped-down Linux aimed specifically for putting into the OSD overflow? Is all that crap really
necessary?Hey - Neuros - the Beagle has a digital camera input. Don't suppose a tvp5150 would work here, eh?
Anyone have any idea what this is about? What would happen if I changed it?
I may be wrong, but I think this flags when you use the advanced recording setup, instead of the "Record for TV", "Record for PSP" sort of stuff; to indicate to the recorder app that it should look at all the supplied parameters instead of making assumptions.
Take a peek at: https://svn2.neurostechnology.com/linux-r3-main-app/trunk/neuros-qt4-libs/neux/settings/nvrecorddata.h
Well.....maybe it can
do AVIs after all? Let me know if you decide to try that! I also think it would be kinda nifty to expose the quality option (economy/fine/superfine) as it doesn't seem as if the default settings control does that (I guess it picks depending on chosen bitrate or something?).
The main reason why I don't like the 4 hour limit is that it is unnecessary on modern filesystems. It is a FAT filesystem based limitation that is out-of-date now. I do all my recording to cifs-mounted NTFS filesystems.
Um... Some thoughts:
1. The FAT limitation is, IIRC, 4Gb minus a byte. This is not
the same as four hours (depends on your bitrate!). Does it cut out at four hours exactly? With other quality options? Maybe your table of iframe pointers (that's what the finalise-TOC thing is, isn't it?) fills up. A quick look at a video file, it looks like it writes an iframe roughly every 15 frames. For me, there's 25fps so... 60 (secs) x 60 (mins) = 3600 secs/hour. x25 = 90000 frames/hour. /15 = approx 6000 iframes/hour. Maybe there's a limit to this?
might record to NTFS. Does everybody else?
That said, I need to know if you meant 4Gb or 4 hours.
Further, the "turn around" takes time.
Indeed. That's why long things I want to record are usually done manually. The Eurovision Song Contest
, for instance, is usually recorded at a nicer bitrate (say 1500/2000kbit) for the songs. That's about the first half. When it comes to the voting, interval rubbish, etc, then I can knock the quality back to 1200kbit for the remainder of the programme. Not ideal, all in one file would be best, but it is a workable compromise as I can choose to abort during some of the blather stuck in for crappy new-Europe countries that can't handle a ~3hour live event without sticking adverts in...
When I stopped running these extra processes, it pretty much (but not completely) stopped crashing during the "turn around".
Indeed. The OSD is a little fragile in memory stakes. I note that the allocation to Linux is 34Mb. Do the codecs/DSP/etc really need to claim 30Mb of workspace? It is such a shame that part is closed, nobody can look to seeing how much space is given
vs how much space is used
Well, it's been... good grief, a month, since your post. How have you got on?