Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Timer for getatsc?
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Timer for getatsc?
PostPosted: Wed Feb 11, 2004 8:18 am Reply with quote
Nexus6
 
Joined: 11 Feb 2004
Posts: 1




I'm not interested in installing Myth right now, but I'd like to continue recording HD broadcasts. Is there a way to schedule an end for getatsc? Or perhaps integrate a timer field into the program, so that you could specify that you wanted it to run for 60 or 120 min? I would like to set up some cron jobs for the few shows I watch, but as far as I can tell there is not way to script an end to the recording.
View user's profile Send private message
PostPosted: Wed Feb 11, 2004 1:27 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I'm just using the "at" command to start getatsc at the beginning and another "at" command to execute "killall getatsc" when the show is over. It's not pretty but it works.
View user's profile Send private message
PostPosted: Fri Feb 13, 2004 7:16 pm Reply with quote
wallyllama
 
Joined: 31 Dec 2003
Posts: 18




Search this forum for tssave. some one used the guts of getasc to make a tool that you can specify a duration. The other change is it saves 1 minute long files. If you don't like that I'm sure you could look at the code and change the lenght.
View user's profile Send private message
PostPosted: Sat Feb 14, 2004 6:29 pm Reply with quote
Ulmo
 
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA




wallyllama wrote:
Search this forum for tssave. some one used the guts of getasc to make a tool that you can specify a duration. The other change is it saves 1 minute long files. If you don't like that I'm sure you could look at the code and change the lenght.


Unfortunately, that doesn't work, since the length is variable and imprecise.

Something better than killall for multicard systems is fuser -k, e.g.:

Code:
at 17:00
fuser -k /dev/video32


That kills all processes connected to device /dev/video32.

Another way to do it which could be worse (because it wouldn't allow finish writing output) is to know the name of the output file:

Code:
at 17:00
fuser -k /videostore/filename_1600.ts


fuser can also be used to find out whether a process is still using it:
Code:
at 17:00
while fuser /dev/video32; do sleep 1; done
getatsc ....
Since there should be a lock delay, I could imagine something more like:
Code:
at 17:00
trynum=0
while fuser /dev/video32;do
 sleep 1
 if [ $trynum -gt 20 ]; then
  fuser -k /dev/video32
  break;
 else
  trynum=`expr $trynum + 1`
 fi
done
getatsc ....
Better, if you know you have bash:
Code:
#!/bin/bash
let trynum=0
while fuser /dev/video32;do
 sleep 1
 if let 'trynum>20'; then
  fuser -k /dev/video32
  break;
 else
  let '++trynum'
 fi
done
getatsc ....


Koreth's program is great because it double buffers without blocking; I suggest you use it regardless of whether you use its length feature. An alternative is using bfr (I use something like bfr -b32m, like:
Code:
dd if=/dev/video32 bs=32k |
 bfr -b32m |
 dd of=/v/output.ts bs=8k
; I think getatsc works better than "dd if=....").

You could program getatsc and/or koreth's program to check the time, too (getatsc would be FAR better); you would specify an ending time, and it would just do a time or nanosecond time or whatever call, and you would compare the time to the time on the command line, and when it passes, it would simply stop recording. I really like this solution, and it would be easy to do. You could either calculate exact timeout for the end of the hour via select, and/or just check whenever you get a read.

When time has finished, be sure to close input, then finish writing output buffers; you don't want to loose the last part of your program (and if you're using a lot of buffering, like I do, it could be well into the most important scenes). That way, while disk output and buffer program are still busy writing file, the device has been closed, and anothe device can start using it immediately (changing channel, reading device, etc.) without the two processes interfering (except some slight resource contention for some memory buffer space, and stuff like that, but I know my system can more than handle that amount of requirement, by many times!) This would be a better solution, since it would prevent you killing the buffer process from writing even though it's done reading. Read man page for "bfr" to see if that is acceptable for now.

I could code this in an evening, but I have a moratorium on it while I find work.


Another solution is making a process that sits on /dev/video32 and does everything necessary. You would have a second process that does quality control, i.e., it checks the output of the first process and all the commands it was given, and if it is working, it lets it continue, but if it did something wrong, it remedies the situation using incrementally more interrupting and sure methods (soft re-request, hard re-request, restart of process, killing using TERM then HUP then KILL, etc.) Anyway, the main process that sits on /dev/video32 would do all IOCTLs and reading. You would give it a time for next action and what that action would be. For instance, "16:59.3948294: change channel to X". Then, it would set a timer for 16:59.3948294, and at that time, it would do that. A special time of "0" could mean now, "1" could mean right after the previous command, etc. For instance, "1: record". So, it would change channel, then start recording.

Anyway, it would be a simple program that does what it needs to. Other processes would use shared memory buffers to get data from it for TS and other processing, and writing to disk. Command line programs to schedule events would be made, some of which would interface with XMLTV, etc., to take the place of Myth. It could all center around simple device access programs that actually get some buffer and companion QC programs that make certain everything is actually running. Each program would be easy to maintain; no large C++ mess, and no requirement to abide by some bad programmer's systems.
View user's profile Send private message Send e-mail
PostPosted: Mon Feb 16, 2004 5:16 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




If killall is causing getatsc to lose the last part of a program. I haven't noticed it. fuser -k would be better since sometimes esd leaves /dev/dtv open for some reason.
View user's profile Send private message
PostPosted: Wed Feb 25, 2004 10:10 am Reply with quote
koreth
 
Joined: 04 Nov 2003
Posts: 8




I didn't realize anyone was having trouble with tssave not working properly. (There are no replies to that effect in the tssave thread.) Can you elaborate, please? I have made well over 100 recordings on several different channels using tssave from cron jobs and have never once noticed it messing up a recording length. If there are circumstances where it's spinning out of control, I'd like to fix it.

In particular I'm quite confused by this quote:

Quote:
You could program getatsc and/or koreth's program to check the time, too (getatsc would be FAR better);


given that the tssave main loop does call time() after each bufferful of data and terminates when it hits the start time plus the desired recording length:

Code:

...
        time(&end_time);
        end_time += seconds - 1;

        while (time(NULL) < end_time &&
               (bytesread = full_read(input_fd, buffer + offset, bytes_to_read)) > 0)
        {
...


That should result in a very precise end time. Okay, maybe off by up to 1 second depending on how long it took to start up, but that level of uncertainty is going to be there no matter what if your system is heavily loaded.

But I'm perfectly willing to believe there's a bug in there somewhere. Details, please!
View user's profile Send private message
PostPosted: Fri Feb 27, 2004 7:35 pm Reply with quote
Ulmo
 
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA




See original tssave thread.
View user's profile Send private message Send e-mail
timed recording
PostPosted: Sat Feb 28, 2004 3:49 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




I don't suppose you would be interested in something that looks like this, would you?

It's nearly done, but there are still a few odd glitches to iron out. It looks better on the console; lots of bright colors to tell you what's going on.

Records to the nearest minute (ntpd helps btw)

if you look below at the totals for each show and the multi-weekly shows you can see I would need multitudes of gigabytes for one week unattended without any self-cleaning.

I have a partial kludge solutiion in overwriting the same file, as the default mode, so then it's one .ts generated for each timer. Misses the puff-dailies but catches the prime time..

Another solution is to append -mmdd to each, or just the name of the weekday. I have all 3 methods, chosen
by last character in timer name. $=day #=mmdd

I've never seen a tivo, but if I were to imagine one, it would look something like this, on an 80x25 16 color console..

So that's what I wrote.

-ink



pchdtvr 0.8 by inkling@nop.org Sat Feb 28 04:02:55 2004
Pre-EQ: SDTV<=FAIR=>HDTV SNR EQ |NONE|JUNK|SKIP|ECHO|POOR|FAIR|GOOD|BEST|
k Ch Call Net MHz 1/2Wi m post pre | . : . | .____:____.____|
1 09 KUHT PBS 187 31.53 $ NO LOCK
2 19 KTXH UPN 501 11.78 ' 87 48 #############################
3 27 KRIV FOX 549 10.75 * 65 15 ---------------------
4 38 KHWB WBN 615 09.59 $ NO LOCK
5 31 KHOU CBS 573 10.30 * 83 35 ###########################
6 32 KTRK ABC 579 10.19 * 71 0 -----------------------
7 35 KPRC NBC 597 09.88 * 2 0 .

T# Status Ch Day Date Time Len Reque Date Time SMTWTFS Name
0 REQUED 9 Tue Mar 2 19:00 60 Tue Mar 9 19:00 0010000 Nova
1 REQUED 9 Mon Mar 1 17:00 30 Tue Mar 2 17:00 0111110 BBC
2 REQUED 9 Mon Mar 1 18:30 30 Tue Mar 2 18:30 0111110 NBR
3 REQUED 19 Mon Mar 1 14:00 30 Tue Mar 2 14:00 0111110 Sabrina
4 REQUED 19 Mon Mar 1 16:30 30 Tue Mar 2 16:30 0111110 Jamie
5 REQUED 19 Wed Mar 3 19:00 60 Wed Mar 10 19:00 0001000 Enterprise
6 REQUED 19 Tue Mar 2 00:00 60 Wed Mar 3 00:00 0011110 Voyager
7 REQUED 19 Fri Mar 5 19:00 120 Fri Mar 12 19:00 0000010 UPN$
8 REQUED 27 Sun Feb 29 23:00 60 Sun Mar 7 23:00 1000000 Stargate
9 REQUED 31 Mon Mar 1 21:00 60 Mon Mar 8 21:00 0100000 CSI:Miami
10 REQUED 31 Thu Mar 4 20:00 60 Thu Mar 11 20:00 0000100 CSI:Vegas
View user's profile Send private message
pchdtvr
PostPosted: Fri Mar 26, 2004 2:31 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Hi all,

My multi-timer recorder application is mostly done now.
You'll need lots of gigabytes to record a large schedule,
or pick save filenames that will overwrite themselves.

It's called hdvr for now, but have gotten the go-ahead
to call it pchdtvr for the next release.

I'm warning you right now this is some messy code,
because it's still a work in progress, but it seems to work
well with only a few quirks now.

One remaining quirk is pre EQ SNR will sometimes
show 0 yet post EQ SNR is 95+, no error LED.

Range for both SNR is 0-127, got rid of the offsets.
This means post EQ good reception is 95-127 now,
instead of the 70 or so it was before. Pre EQ values
are still occasionally indeterminate, so Pre-EQ value
and the color of the signal strength bar are not always
good indicators of the quality of the reception.

Post EQ sets the appearance of signal strength bar,
much as dtvsignal does, but with slight tweaks.

I had one antenna tuning recently when pre-EQ was 90+.
Haven't seen that one again, but maybe with cantenna.

source, screenshot sample, config sample, readme.1st

http://www.teknutz.com/ink/hdvr.tgz

Enjoy!
View user's profile Send private message
Timer for getatsc?
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 1  

  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin