Re: [vdr] trouble with asprintf
Wolfgang Rohdewald wrote: char *s; asprintf(s,%ld-%.9s,random(),artist.original()); segfaults only if illegal utf8 chars appear in artist.original() asprintf returns -1, so s is nothing that could be freed, and this gives a nice backtrace: So its basically just free'ing an uninitialized pointer. Well, that leads to the question whether s is unchanged in case of a -1 error return, and whether this would work: char *s = NULL; asprintf(s,%ld-%.9s,random(),artist.original()); Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
On Monday 11 February 2008, Luca Olivetti wrote: En/na Kartsa ha escrit: I can read germany but I do not understand it :). But understood that I could use that script to test acpi. Well this did not work. I did check that the time was actually written in /proc/acpi/alarm. Still not waking up. IIRC, acpi wakeup wouldn't work here if I didn't enable a wake up time before in the bios setup. Same thing here. I don't remember what it was called in my VDR box's BIOS, but something non-obvious anyway :P OTOH it does work now, but it doesn't take the date into account, so if there's no timer in the next 24 hours I schedule a wake-up at 21:00. IIRC cat /proc/acpi/alarm always displays bogus dates for me, but wakeup does work as expected anyway. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On Feb 11, 2008 9:09 PM, Reinhard Nissl [EMAIL PROTECTED] wrote:
In case the decoder doesn't provide the image aspect ratio (and
it looks like that as you had to provide the image size too),
you'll have to extract it from the H.264 data yourself (as you
did already for the image size).
OK - thanks for your help and patience Reinhard.
We are on the right track here. If I hardcode the this-ratio to be
1.8181 all looks good for my channels. However it is a hack and I have
come this far, so I might as well get the rest correct!
I used xinelibout for my H264 parser but Petri Hintukainen skips
parsing of the VUI! I am looking in your h264parser.c in VDR and you
also seem to comment this stuff out!
So, here is my code: -
if (br_get_bit(br)) { /* VUI parameters */
if (br_get_bit(br)) { /* Aspect Info */
uint32_t aspect_ratio_idc = br_get_u8(br);
printf(H.264 SPS: - Aspect Ratio IDC %d\n, aspect_ratio_idc);
const uint32_t Extended_SAR = 255;
if (aspect_ratio_idc == Extended_SAR) {
uint32_t sar_width = br_get_u16(br);
uint32_t sar_height = br_get_u16(br);
printf(H.264 SPS: - SAR_Size = %dx%d\n,
sar_width, sar_height);
}
}
}
I am getting an Aspect Ratio IDC of 11 so the sar width and height
calcs are not called. What do I need to do here to get the aspect
(~1.818181)?
Thanks again!
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On 12 Feb 2008, at 08:27, Morfsta wrote: now seems to decode all the h264 channels I have access to pretty well with ~40% idle. Which CPU are you using? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
En/na Kartsa ha escrit: I can read germany but I do not understand it :). But understood that I could use that script to test acpi. Well this did not work. I did check that the time was actually written in /proc/acpi/alarm. Still not waking up. IIRC, acpi wakeup wouldn't work here if I didn't enable a wake up time before in the bios setup. OTOH it does work now, but it doesn't take the date into account, so if there's no timer in the next 24 hours I schedule a wake-up at 21:00. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Udo Richter) 05.02.08 22:51 Theunis Potgieter wrote: udev rules Any good rules that could be used as a starting point? I thought of doing this with udev, but there are some obstacles for that: First, a DVB device has several device files, not just one. vdr:~# ll /dev/dvb/adapter0/ insgesamt 0 crw-rw 1 root video 212, 1 2008-02-11 20:19 audio0 crw-rw 1 root video 212, 6 2008-02-11 20:19 ca0 crw-rw 1 root video 212, 4 2008-02-11 20:19 demux0 crw-rw 1 root video 212, 5 2008-02-11 20:19 dvr0 crw-rw 1 root video 212, 3 2008-02-11 20:19 frontend0 crw-rw 1 root video 212, 7 2008-02-11 20:19 net0 crw-rw 1 root video 212, 8 2008-02-11 20:19 osd0 crw-rw 1 root video 212, 0 2008-02-11 20:19 video0 vdr:~# vdr:~# ll /dev/dvb/adapter1/ insgesamt 0 crw-rw 1 root video 212, 65 2008-02-11 20:19 audio0 crw-rw 1 root video 212, 70 2008-02-11 20:19 ca0 crw-rw 1 root video 212, 68 2008-02-11 20:19 demux0 crw-rw 1 root video 212, 69 2008-02-11 20:19 dvr0 crw-rw 1 root video 212, 67 2008-02-11 20:19 frontend0 crw-rw 1 root video 212, 71 2008-02-11 20:19 net0 crw-rw 1 root video 212, 72 2008-02-11 20:19 osd0 crw-rw 1 root video 212, 64 2008-02-11 20:19 video0 vdr:~# ll /dev/dvb/adapter3/ insgesamt 0 crw-rw 1 root video 212, 196 2008-02-11 20:42 demux0 crw-rw 1 root video 212, 197 2008-02-11 20:42 dvr0 crw-rw 1 root video 212, 195 2008-02-11 20:42 frontend0 crw-rw 1 root video 212, 199 2008-02-11 20:42 net0 And second, the usual trick to add a custom name as symlink doesn't work since VDR only accepts /dev/dvb/adapterX/, so /dev/dvb/myprimarycard/ is out. In setup.conf there is a variable: vdr:~# grep Prim /var/lib/vdr/setup.conf PrimaryDVB = 1 PrimaryLimit = 0 (PrimaryLimit seems to have no sense anymore?) What's the problem of a string there: PrimaryDVB = /dev/dvb/myprimarycard/ Currently there is stored where the last time the first FF card was found, what is not allways working good vdr:~# dmesg | grep frontend DVB: registering frontend 0 (Zarlink MT352 DVB-T)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (ST STV0299 DVB-S)... will lead to PrimaryDVB = 2 After fidling arround i could manage (somettimes) to get: vdr:~# dmesg | grep frontend DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (Zarlink MT352 DVB-T)... Wow! but the box does not work anymore...no video, no audio, no OSD. PrimaryDVB = 2 now points to frontend 1 where no TV/Sound hardware is connected. So this automatic does not really work, and makes configuration more complicate. (If *i* said: use PrimaryDVB = 2, the box must do. If this is wrong, VDR could/should issue a warning, but not change the recommended PrimaryDVB. It would be easier if there could be a symlink be used instead/addition to the single digit. Remember the history: This PrimaryDVB = 2 stems from a time, when there were only badly working FF cards (with severe(!)hardware bugs). No budgets, no DVB-T to be mixed because not supported or not existing! A card found at slot1 stays at the index... But today? With udev? Why not use both? (to be compatible) If 1 or 2 Digits than old else take as device path. Rainer---= Vertraulich // // =--ocholl, Kiel, Germany ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Udo Richter wrote: Wolfgang Rohdewald wrote: char *s; asprintf(s,%ld-%.9s,random(),artist.original()); segfaults only if illegal utf8 chars appear in artist.original() asprintf returns -1, so s is nothing that could be freed, and this gives a nice backtrace: So its basically just free'ing an uninitialized pointer. Well, that leads to the question whether s is unchanged in case of a -1 error return, and whether this would work: char *s = NULL; asprintf(s,%ld-%.9s,random(),artist.original()); The manpage explicitly says that the content of s is undefined in case of error. So even if it works you can't really count on it. You can't get around checking the return value. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
Rainer Zocholl kirjoitti:
[EMAIL PROTECTED](Kartsa) 10.02.08 10:37
What different wakeupmethods are there? I've built a few vdr boxes and
I've been forced to use different motherboards and they do not all
work the same. I've used nvram-wakeup on some and acpi on others when
nvram-wakeup has not worked. Now I have Biostar 945GZ 775 SE with
which I'm having trouble in starting on timers.
What problems? Be spezific.
At the time writing I was not really asking help, just qurious what
methods people use. This is why I did not put any detailed info. Maybe I
should not have mentioned about problems I at that time.
Now I see that I should have added more info because I'm not yet happy
with my settings. I would have used acpi and it was my first attempt but
the board did not wake up.
from vdr-shutdown.sh
---
file=/var/lib/vdr/acpi-wakeup
rm -f $file
if [ ${1:-0} -gt 0 -a -e /proc/acpi/alarm ] ; then
date -d 1970-01-01 UTC $1 sec -$delay min +%Y-%m-%d %H:%M:%S $file
fi
exec sudo /sbin/shutdown -h now
and from halt.local (this is what is instructed in vdr README.package)
#!/bin/bash
wakeupfile=/var/lib/vdr/acpi-wakeup
trap rm -f $wakeupfile EXIT
if [ -s $wakeupfile -a -w /proc/acpi/alarm ] ; then
echo -n Setting ACPI wakeup for next VDR timer: ; cat $wakeupfile
cat $wakeupfile /proc/acpi/alarm
fi
---
But it does not wake up. And this is not a very old mb. So I assume I am
doing something wrong or not doing something I should.
I got it to boot up using nvram-wakeup with reboot option (after guess
helper). But as said nvram should be obsolete and replaced by acpi.
On another mb (4CoreDual-Sata23) I used
---
newtime=$(($1 - delay*60 )) # delay minutes earlier
echo $newtime /sys/class/rtc/rtc0/wakealarm
---
which did the trick.
On biostar there were no /sys/class/rtc
So I tried from http://www.vdr-wiki.de/wiki/index.php/ACPI_Wakeup (as
someone mentioned in this thread)
--
#!/bin/bash
# Startet dem Rechner nach 3 min ueber acpi neu.
min=`date +%M`
nextmin=`expr $min + 3`
nextboot=`date +%Y-%m-%d %H:$nextmin:00`
echo $nextboot /proc/acpi/alarm
echo Aktuelle Zeit: `date +%Y-%m-%d %H:%M:%S`
echo Starte Rechner neu um: `cat /proc/acpi/alarm`
echo Fahre Rechner nun runter.
busybox poweroff
#/usr/bin/poweroff.pl
#poweroff
---
I can read germany but I do not understand it :). But understood that I
could use that script to test acpi. Well this did not work. I did check
that the time was actually written in /proc/acpi/alarm. Still not waking up.
So where do I go here? Do I use nvram-wakeup which IMHO is not good
because of the reboot.
\\Kartsa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] demuxing subtitles with projectx
Petri Helin [EMAIL PROTECTED] wrote:
Thanks for informing about the update. Seems to work now with recordings
with dvb-subtitles from the Finnish broadcaster, YLE, too.
Regarding the renaming of the audio files, I made a few changes in the
Project-X in order to fix that:
--- parser/StreamProcessAudio.java.old 2008-02-11 15:09:21.0 +0200
+++ parser/StreamProcessAudio.java 2008-02-11 15:08:29.0 +0200
@@ -1861,8 +1861,8 @@
{
for (int i = 1; i 4; i++)
{
- str[0][i] += new_str_1;
- str[1][i] += new_str_2;
+ str[0][i] = new_str_1;
+ str[1][i] = new_str_2;
}
}
Don't know whether it is the right way but with a quick test it seems to
work at least.
hm, with a recording from zdf with 2 mpa streams i become this:
-rw-rw-r-- 1 vdr vdr 3638016 11. Feb 21:13 vdrsync-02.mpa
prw-rw-r-- 1 vdr vdr 0 11. Feb 21:12 vdrsync0.mpa
prw-rw-r-- 1 vdr vdr 0 11. Feb 21:12 vdrsync1.mpa
-rw-rw-r-- 1 vdr vdr 1819008 11. Feb 21:13 vdrsync.mpa
vdrsync0.mpa and vdrsync1.mpa only 0 byte, and burn waits for anything.
with 1 audio stream:
prw-rw-r-- 1 vdr vdr 0 11. Feb 21:24 vdrsync1.mpa
-rw-rw-r-- 1 vdr vdr 3638016 11. Feb 21:24 vdrsync.mpa
and the dvd will be created.
Stefan
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On Feb 11, 2008 8:09 PM, Reinhard Nissl [EMAIL PROTECTED] wrote:
Anyway, does the decoder tell you the aspect ratio anywhere?
The aspect ratio must be passed to get_frame(). When the frame
has the correct aspect ratio set, xine-lib will take care to
setup the video scaler to stretch for example the image to 136 %
horizontally.
The coreavc patch for xine has this code in it: -
+if(!img) {
+img = this-stream-video_out-get_frame (this-stream-video_out,
+ this-bih-biWidth,
+ this-bih-biHeight,
+ this-ratio,
+ IMGFMT_YUY2,
+ field);
+}
with this-ratio = (double)this-bih-biWidth/(double)this-bih-biHeight;
This is all within xine's src/libw32dll/w32codec.c which is a
different area to which I was modifying before
(src/demuxers/demux_mpeg_pes.c) where the codec is initialised.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi,
Morfsta schrieb:
The coreavc patch for xine has this code in it: -
+if(!img) {
+img = this-stream-video_out-get_frame (this-stream-video_out,
+ this-bih-biWidth,
+ this-bih-biHeight,
+ this-ratio,
+ IMGFMT_YUY2,
+ field);
+}
with this-ratio =
(double)this-bih-biWidth/(double)this-bih-biHeight;
Looks not bad, but ratio is wrong. For your sample 1440 x 1080 it
will yield 1. and not 1.8181 (or 1.7778). Therefore you get
those black bars left and right to the image.
In case the decoder doesn't provide the image aspect ratio (and
it looks like that as you had to provide the image size too),
you'll have to extract it from the H.264 data yourself (as you
did already for the image size).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: Just a guess: maybe the above bih.biXPelsPerMeter and bih.biYPelsPerMeter can be used to set the pixel aspect ratio which will then in turn yield the frame aspect ratio when applied to the coded frame size. So pixel aspect for the above sample should yield: pa = 1.81818 * 1080 / 1440 = 1.363635 and most likely: bih.biXPelsPerMeter=13636 I tried that, what would the bih.biYPelsPerMeter be in this instance? 1? Even then it doesn't seem to make any difference. That's why I wrote guess. Anyway, does the decoder tell you the aspect ratio anywhere? The aspect ratio must be passed to get_frame(). When the frame has the correct aspect ratio set, xine-lib will take care to setup the video scaler to stretch for example the image to 136 % horizontally. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
I demand that Ludwig Nussel may or may not have written... Darren Salt wrote: I demand that Ludwig Nussel may or may not have written... [snip] asprintf needs to check for multibyte characters to not cut them in the middle and produce invalid output. No - it's encoding-neutral. [...] Try the following with 'LANG=C' and 'LANG=de_DE.UTF-8'. You will notice that in the latter case it will not cut the umlaut. [snip code - hmm, dodgy use of printf] Interesting. It omits it entirely. But the rest of my point still stands - it still counts bytes. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. This message was brought to you using only 100% recycled electrons. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR - xine - CoreAVC
OK, I spent a bit of time looking at this today as there doesn't seem to be much movement on FFMPEG and H264 at the moment. I have managed to get xine to now detect the H264 video size prior to starting up the CoreAVC decoder and set the size within the initialisation function: - memset(bih, 0x00, sizeof(bih)); bih.biWidth = sps.width; bih.biHeight = sps.height; bih.biPlanes = 1; bih.biBitCount = 24; bih.biCompression = 0x34363248; //31435641; //AVC1 bih.biSizeImage = 0; bih.biXPelsPerMeter=1; bih.biYPelsPerMeter=1; bih.biClrUsed=0; bih.biClrImportant=0; bih.biSize = sizeof(bih); buf-content = malloc(sizeof(bih)); It detects BBC HD as the right video size, i.e. 1440 x 1080 - however this now results in a squased image on the display with black bars down the left and right sides. Any idea how you tell CoreAVC what the video size is and to scale it to the size that xine is using? It detects other video sizes such as 1920x1088 and displays them all correctly on the screen so I know that we are now very close! Once I get this bit right, I'll release a patch to xine's demux_mpeg_pes.c that will properly detect the source video size prior to starting CoreAVC. Thanks for any help. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Darren Salt wrote:
I demand that Ludwig Nussel may or may not have written...
[snip]
asprintf needs to check for multibyte characters to not cut them in
the middle and produce invalid output.
No - it's encoding-neutral. What you want is your own version which does that
Try the following with 'LANG=C' and 'LANG=de_DE.UTF-8'. You will
notice that in the latter case it will not cut the umlaut.
#define _GNU_SOURCE
#include stdio.h
#include string.h
#include stdlib.h
#include locale.h
int main(void)
{
char* buffer;
char artist[] = Haegar;
int ret;
setlocale(LC_ALL, );
artist[1]=0xc3;
artist[2]=0xa4;
ret = asprintf(buffer,%.2s\n,artist);
printf(%d bytes\n, ret);
printf(buffer);
free(buffer);
return 0;
}
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
On Montag, 11. Februar 2008, Udo Richter wrote: Well, that leads to the question whether s is unchanged in case of a -1 error return, and whether this would work: I can confirm that. The man page however says the value will be undefined. My current understanding is: 1. dont forget to call setlocale! Normally setlocale(LC_ALL,) 2. if locale is UTF-8, asprintf returns -1 if the string contains illegal UTF-8 characters anywhere 3. this and out of memory are the only reasons I know for result -1. The man page to asprintf says there could be other errors than out of memory but mentions none. 4. If result -1, the buffer pointer stays unchanged, see man page 5. if locale is UTF-8 and a maximum length is defined as in %.9s, and if %.9s would cut a multibyte char, only 8 chars will be used. See example from Ludwig Nussel. What I don't know where in the man pages this is explained - I did not find anything about it. Neither man asprintf or man printf -- Wolfgang ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: Well, the spec tells you that aspect_ratio_idc 11 means a sample (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080 pixels so the frame aspect ratio yields: far = 1.3636 * 1440 / 1080 = 1.8181 Could you give me a link to where you found that please? I've posted the URL to the spec some weeks ago already. In that issue, have a look into Annex E.2.1, Table E-1, Page 313. Also, I just discovered another problem with this method. I was wondering why the performance on HD was so poor and it turns out that the picture was being de-interlaced twice, once by CoreAVC for the h264 picture and then by xine post plugin (tvtime). When I remove the post deinterlacing plugin the performance is much better and now seems to decode all the h264 channels I have access to pretty well with ~40% idle. However, when I go back to a MPEG2 channel of course the deinterlacing is now disabled and it looks terrible! Do you know if its possible to enable de-interlacing for only a certain picture type(s), or am I looking at this the wrong way? Simply set the progressive_frame flag. But use_progressive_frame_flag=0 overrides this information and will still deinterlace. To disable it completely for your decoder even in this case, do not set VO_INTERLACED_FLAG when getting the frame. Have a look into ff_video_decoder.c. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: I have managed to get xine to now detect the H264 video size prior to starting up the CoreAVC decoder and set the size within the initialisation function: - memset(bih, 0x00, sizeof(bih)); bih.biWidth = sps.width; bih.biHeight = sps.height; bih.biPlanes = 1; bih.biBitCount = 24; bih.biCompression = 0x34363248; //31435641; //AVC1 bih.biSizeImage = 0; bih.biXPelsPerMeter=1; bih.biYPelsPerMeter=1; bih.biClrUsed=0; bih.biClrImportant=0; bih.biSize = sizeof(bih); buf-content = malloc(sizeof(bih)); It detects BBC HD as the right video size, i.e. 1440 x 1080 - however this now results in a squased image on the display with black bars down the left and right sides. Any idea how you tell CoreAVC what the video size is and to scale it to the size that xine is using? It detects other video sizes such as 1920x1088 and displays them all correctly on the screen so I know that we are now very close! Looks like you/CoreAVC miss setting the aspect ratio of the frame. If you replay a BBC HD recording with xine (using FFmpeg) and open a VDR menu, you should see messages like that which tell you the frame aspect ratio after the @: vdr_video: osd: (0, 0)-(1440, 1080)@1,81818 ratio: 18182 Just a guess: maybe the above bih.biXPelsPerMeter and bih.biYPelsPerMeter can be used to set the pixel aspect ratio which will then in turn yield the frame aspect ratio when applied to the coded frame size. So pixel aspect for the above sample should yield: pa = 1.81818 * 1080 / 1440 = 1.363635 and most likely: bih.biXPelsPerMeter=13636 BTW: the above ratio of 1.81818 is different from 16:9 which is 1.8. I've no idea why BBC uses this strange ratio. And 1920x1088 doesn't yield 16:9 either, but 1.76471. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Old schedule / old timers
Rainer Zocholl wrote: Too, long time ago one time timers were not deleted automatically. That has the advantage that if i found that one time worth to be recorded again, it was easy by editing that old used one time timer. Manually deleting the superflous used timers was much easier than to wait for EPG to show that event in future. create a weekly timer and deactivate it after you used it, to reuse it change it if you need to record something you only know the title it's possible to user the autotimer function from vdradmin or epgsearch, this way one-time-timer will always be created if needed ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On Feb 11, 2008 11:03 PM, Reinhard Nissl [EMAIL PROTECTED] wrote: I've posted the URL to the spec some weeks ago already. In that issue, have a look into Annex E.2.1, Table E-1, Page 313. Sorry. I'll see what I can dig out to set that up properly. For now hardcoding works well as most H264 channels are 16:9. Simply set the progressive_frame flag. To disable it completely for your decoder even in this case, do not set VO_INTERLACED_FLAG when getting the frame. Yup, it was set right there and no need for it. Now CoreAVC runs with much better performance with xine. No more dropped frames... :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] demuxing subtitles with projectx
Il giorno dom, 10/02/2008 alle 18.32 +0100, Stefan Wagner ha scritto: ProjectX 0.90.4.b22 works with vdr 1.5.x recordings. Just tried the last cvs, it still fails to process subtitles, getting stuck in a loop with message suppic unknown cmd: 44 as the previous version I tested. i have only test with dvb-subtitles from german broadcast station zdf My recordings are from BBC Prime. its possible, the patch is only for zdf: http://forum.dvbtechnics.info/showthread.php?t=4920 (sorry in german) I read the log posted there, it fails with suppic unknown cmd: 208, while mine is 44; probably the patch implements only command 208... Regards, Davide davide125(at)tiscali.it ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Wolfgang Rohdewald wrote:
My problem code:
mgDb::Build_cddbid(const mgSQLString artist) const
{
char *s;
asprintf(s,%ld-%.9s,random(),artist.original());
segfaults only if illegal utf8 chars appear in artist.original()
asprintf returns -1, so s is nothing that could be freed,
and this gives a nice backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1319449712 (LWP 22989)]
0xb7bf57ea in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7bf57ea in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7986908 in mgDb::Build_cddbid (this=0x86ed8e8, [EMAIL PROTECTED]) at
mg_db.c:1023
As you can see it doesn't segfault on asprintf but on free().
If I change %.9s to %s, everything is fine.
I cannot easily simplify that, if I try like this, it works:
char artist[50];
strcpy(artist,Celine Dion);
artist[1]=0xe9;
asprintf(buffer,%ld-%.9s,random(),artist);
printf(buffer);
free(buffer);
if(asprintf(...) = 0)
{
printf(...);
free(...);
}
Or just use normal snprintf as the amount of charactes to print is
fixed anyways so you don't need a variable sized buffer.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] disable stk webcam
Hello, I am trying to configure a new vdr streaming client. As 1.5.14 needs the multiproto driver, I did download it from Mercurial. When I compile I get an error about stk-webcam I found that one of the solutions was to disable this webcam in make menuconfig. My problem is that I can't find any driver looking to have something to do with stk-webcams. Can anyone tell me where to find the driver I have to disable ? I am using kubuntu 7.04 wit a 2.6.20 kernel Thanks a lot, Serge ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Wolfgang Rohdewald wrote:
since asprintf leads to segfaults if feeded with incorrect UTF-8 characters,
It's not asprintf that segfaults but the call to free uninitialized
memory afterwards.
I wanted to write a wrapper function which would then check the return value
of asprintf. However I have a problem with the variable argument list and
the va_* macros. Using gdb shows that, in the following example, in
res=asprintf (strp, fmt, ap);
ap is interpreted not as a list of arguments but as an integer.
use vasprintf
int
msprintf(char **strp, const char *fmt, ...)
{
va_list ap;
int res;
va_start (ap, fmt);
res=asprintf (strp, fmt, ap);
va_end (ap);
}
Even if you use vasprintf to make the function actually work you
still need to check the return value of vasprintf otherwise this
wrapper would be kind of useless.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins). Here we are... Clean vdr-1.5.13 with 2 budget cards (DVB-T and DVB-C with CI) and xine-0.8.1 plugin. AK Feb 11 21:51:09 vdr vdr: [27875] VDR version 1.5.13 started Feb 11 21:51:09 vdr vdr: [27875] codeset is 'UTF-8' - known Feb 11 21:51:09 vdr vdr: [27875] found 22 locales in /usr/local/src/vdr-1.5.13/locale Feb 11 21:51:09 vdr vdr: [27875] loading plugin: /usr/local/vdr/PLUGINS/lib/libvdr-xine.so.1.5.13 Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/setup.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/sources.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/diseqc.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/channels.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/timers.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/commands.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/reccmds.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/svdrphosts.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/remote.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/keymacros.conf Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread started (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread ended (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread started (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread ended (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27875] reading EPG data from /usr/local/etc/vdr/epg.data Feb 11 21:51:09 vdr vdr: [27879] tuner on device 1 thread started (pid=27875, tid=27879) Feb 11 21:51:09 vdr vdr: [27880] section handler thread started (pid=27875, tid=27880) Feb 11 21:51:10 vdr vdr: [27882] tuner on device 2 thread started (pid=27875, tid=27882) Feb 11 21:51:10 vdr vdr: [27883] section handler thread started (pid=27875, tid=27883) Feb 11 21:51:10 vdr vdr: [27875] initializing plugin: xine (0.8.1): Software based playback using xine Feb 11 21:51:10 vdr vdr: [27884] XineRemote control thread started (pid=27875, tid=27884) Feb 11 21:51:10 vdr vdr: [27884] Entering cXineRemote thread Feb 11 21:51:10 vdr vdr: [27875] setting primary device to 3 Feb 11 21:51:10 vdr vdr: [27875] assuming manual start of VDR Feb 11 21:51:10 vdr vdr: [27875] SVDRP listening on port 2001 Feb 11 21:51:10 vdr vdr: [27875] starting plugin: xine Feb 11 21:51:10 vdr vdr: [27890] KBD remote control thread started (pid=27875, tid=27890) Feb 11 21:51:10 vdr vdr: [27875] remote control KBD - keys known Feb 11 21:51:12 vdr vdr: [27886] CAM 1: module ready Feb 11 21:51:13 vdr vdr: [27886] CAM 1: replies to QUERY - multi channel decryption possible Feb 11 21:51:13 vdr vdr: [27875] switching to channel 112 Feb 11 21:51:13 vdr vdr: [27891] transfer thread started (pid=27875, tid=27891) Feb 11 21:51:13 vdr vdr: [27892] receiver on device 2 thread started (pid=27875, tid=27892) Feb 11 21:51:13 vdr vdr: [27893] TS buffer on device 2 thread started (pid=27875, tid=27893) Feb 11 21:51:13 vdr vdr: [27875] setting watchdog timer to 60 seconds Feb 11 21:51:14 vdr vdr: [27891] setting audio track to 1 (0) Feb 11 21:51:15 vdr vdr: [27875] max. latency time 1 seconds Feb 11 21:51:33 vdr vdr: [27875] switching device 2 to channel 112 Feb 11 21:51:33 vdr vdr: [27875] timer 1 (112 2151-2201 'TITLE EPISODE') start Feb 11 21:51:33 vdr vdr: [27875] Title: 'Kohtumine Fockeritega (Meet The Focker, USA 2004)' Subtitle: '(null)' Feb 11 21:51:33 vdr vdr: [27875] record /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] creating directory /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] recording to '/video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec/001.vdr' Feb 11 21:51:33 vdr vdr: [27894] file writer thread started (pid=27875, tid=27894) Feb 11 21:51:33 vdr vdr: [27895] recording thread started (pid=27875, tid=27895) Feb 11 21:51:33 vdr vdr: [27875] info: Recording started Feb 11 21:51:39 vdr vdr: [27875] max. latency time 7 seconds Feb 11 21:52:03 vdr vdr: [27875] CAM 1: assigned to device 2 Feb 11 21:52:03 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:03 vdr vdr: [27891] transfer thread ended (pid=27875, tid=27891) Feb 11 21:52:03 vdr vdr: [27875] buffer stats: 184052 (8%) used Feb 11 21:52:03 vdr vdr: [27896] transfer thread started (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27896] transfer thread ended (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:07 vdr vdr:
Re: [vdr] demuxing subtitles with projectx
Davide Cavalca wrote: Il giorno dom, 10/02/2008 alle 18.32 +0100, Stefan Wagner ha scritto: ProjectX 0.90.4.b22 works with vdr 1.5.x recordings. Just tried the last cvs, it still fails to process subtitles, getting stuck in a loop with message suppic unknown cmd: 44 as the previous version I tested. i have only test with dvb-subtitles from german broadcast station zdf My recordings are from BBC Prime. its possible, the patch is only for zdf: http://forum.dvbtechnics.info/showthread.php?t=4920 (sorry in german) I read the log posted there, it fails with suppic unknown cmd: 208, while mine is 44; probably the patch implements only command 208... I noticed that Project-X is able to handle only subtitles within subID 0x20. I have a recording with subtitles with subIDs 0x20 and 0x21 and demuxing fails with command 248. If I restrict Project-X to subID 0x20, I am able to demux that recording too. Unfortunately this means that the second subtitle stream cannot be demuxed. Is this related to the TODO Klaus has marked for 0x21 in dvbsubtitle.c? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Udo Richter wrote: Wolfgang Rohdewald wrote: since asprintf leads to segfaults if feeded with incorrect UTF-8 characters, I wanted to write a wrapper function which would then check the return value of asprintf. I never understood what the problem is with utf8 and asprintf, since utf8 is mostly ASCIIZ backwards compatible, and asprintf probably doesn't even know the difference between utf8 and ascii. What special handling does asprintf with utf8? Is there some example that causes the trouble? asprintf needs to check for multibyte characters to not cut them in the middle and produce invalid output. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM. Sorry for delay, busy weekend... I enabled debug outputs in ci.c and made 2 attempts: -crypted channel recording (ok files) -FTA recording and try to switch to crypted channel (bad files) stdout and syslog files attached. vdr-1.5.14 used. Regards, AK Feb 11 11:20:17 vdr vdr: [23935] switching to channel 114 Feb 11 11:20:17 vdr vdr: [23958] transfer thread started (pid=23935, tid=23958) Feb 11 11:20:17 vdr vdr: [23959] receiver on device 2 thread started (pid=23935, tid=23959) Feb 11 11:20:17 vdr vdr: [23960] TS buffer on device 2 thread started (pid=23935, tid=23960) Feb 11 11:20:17 vdr vdr: [23935] setting watchdog timer to 60 seconds Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: operating in MPEG1/2 mode Feb 11 11:20:20 vdr vdr: [23935] max. latency time 1 seconds Feb 11 11:20:24 vdr vdr: [23935] CAM 1: assigned to device 2 Feb 11 11:20:24 vdr vdr: [23935] switching to channel 113 Feb 11 11:20:24 vdr vdr: [23958] transfer thread ended (pid=23935, tid=23958) Feb 11 11:20:24 vdr vdr: [23935] buffer stats: 175592 (8%) used Feb 11 11:20:24 vdr vdr: [23960] TS buffer on device 2 thread ended (pid=23935, tid=23960) Feb 11 11:20:24 vdr vdr: [23959] buffer stats: 59220 (2%) used Feb 11 11:20:24 vdr vdr: [23959] receiver on device 2 thread ended (pid=23935, tid=23959) Feb 11 11:20:24 vdr vdr: [23961] transfer thread started (pid=23935, tid=23961) Feb 11 11:20:25 vdr vdr: [23963] receiver on device 2 thread started (pid=23935, tid=23963) Feb 11 11:20:25 vdr vdr: [23964] TS buffer on device 2 thread started (pid=23935, tid=23964) Feb 11 11:20:25 vdr vdr: [23951] ttxtsubs: No teletext subtitles on channel. Feb 11 11:20:25 vdr vdr: [23961] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:25 vdr vdr: [23961] cVideoRepacker: operating in MPEG1/2 mode Feb 11 11:20:34 vdr vdr: [23935] switching device 2 to channel 113 Feb 11 11:20:34 vdr vdr: [23935] timer 1 (113 1120-1420 'TITLE EPISODE') start Feb 11 11:20:34 vdr vdr: [23935] Title: 'NHL On the Fly: Final; Ice Hockey Sports' Subtitle: '(null)' Feb 11 11:20:34 vdr vdr: [23935] record /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec Feb 11 11:20:34 vdr vdr: [23935] creating directory /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports Feb 11 11:20:34 vdr vdr: [23935] creating directory /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec Feb 11 11:20:35 vdr vdr: [23935] recording to '/video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec/001.vdr' Feb 11 11:20:35 vdr vdr: [23966] file writer thread started (pid=23935, tid=23966) Feb 11 11:20:35 vdr vdr: [23967] recording thread started (pid=23935, tid=23967) Feb 11 11:20:35 vdr vdr: [23935] info: Recording started =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.02.11 10:52:52 =~=~=~=~=~=~=~=~=~=~=~= [EMAIL PROTECTED]:/var/log# cd /var/log/runvdr - MakePrimaryDevice: 1 = SetVideoFormat: 0 SetVolumeDevice: 40 Slot 1: module ready Slot 1: creating connection 0/1 Slot 1: create connection 0/1 1: -- 00 01 82 01 01 1: -- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 1) 1: -- 00 01 A0 0A 01 92 07 00 00 03 00 41 00 01 Slot 1: == Ca Info Enq (1) 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 30 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 0B 01 90 02 00 01 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: == Ca Info (1) 0B00 Slot 1: == Ca Pmt (1) 3 3 1: -- 00 01 A0 10 01 90 02 00 01 9F 80 32 07 03 00 00 01 00 01 03 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 0D 01 90 02 00 01 9F 80 33 04 00 00 00 81 80 02 01 00 . . . . . . . . . . . 3 . . . . . . . . . Slot 1: == Ca Pmt Reply (1) 0 00 81 - ** TUNING TO FTA CHANNEL (ch 114) *** GetDevice 114 0 1 - 'Star!:17:M64:C:6900:2040:2041=eng:2042:0:1142:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E 018C4C64 i = 2 A B X 1 Z SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 SetVolumeDevice: 40 SetPlayMode: 1 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) [v] vdr-xine: Client connecting ... vdr-xine: Client connected! frame: (0, 0)-(720, 576), zoom: (1,00, 1,00) [vaAVM]buffered 19,5 frames (v:28,7, a:19,5) frame: (0, 0)-(704, 576), zoom: (1,00, 1,00) buffered 19,2 frames (v:29,0, a:19,2) frame: (0, 0)-(704, 576), zoom: (1,00,
Re: [vdr] trouble with asprintf
On Montag, 11. Februar 2008, Ludwig Nussel wrote:
As you can see it doesn't segfault on asprintf but on free().
I did see that. I did not say it segfaults but it does lead
to segfaults.
if(asprintf(...) = 0)
{
printf(...);
free(...);
}
I do not want to change dozens of places like that. Just have
one single point which can emit an error message so I can then
see what has to be done for each individual place. Most of the
asprintf calls will never get into trouble anyway. But if a user
reports a problem I prefer an error message over some vague description.
Or just use normal snprintf as the amount of charactes to print is
fixed anyways so you don't need a variable sized buffer.
this is just a minimal sample. The real code has variable length
strings.
On Montag, 11. Februar 2008, Ludwig Nussel wrote:
Even if you use vasprintf to make the function actually work you
still need to check the return value of vasprintf otherwise this
wrapper would be kind of useless.
of course. See above.
--
Wolfgang
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
On 02/11/08 10:39, Arthur Konovalov wrote: Klaus Schmidinger wrote: Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM. Sorry for delay, busy weekend... I enabled debug outputs in ci.c and made 2 attempts: -crypted channel recording (ok files) -FTA recording and try to switch to crypted channel (bad files) stdout and syslog files attached. vdr-1.5.14 used. Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: operating in MPEG1/2 mode There is no such output in plain vanilla VDR 1.5.14. Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
Kartsa schrieb:
Rainer Zocholl kirjoitti:
[EMAIL PROTECTED](Kartsa) 10.02.08 10:37
What different wakeupmethods are there? I've built a few vdr boxes and
I've been forced to use different motherboards and they do not all
work the same. I've used nvram-wakeup on some and acpi on others when
nvram-wakeup has not worked. Now I have Biostar 945GZ 775 SE with
which I'm having trouble in starting on timers.
What problems? Be spezific.
At the time writing I was not really asking help, just qurious what
methods people use. This is why I did not put any detailed info. Maybe I
should not have mentioned about problems I at that time.
Now I see that I should have added more info because I'm not yet happy
with my settings. I would have used acpi and it was my first attempt but
the board did not wake up.
from vdr-shutdown.sh
---
file=/var/lib/vdr/acpi-wakeup
rm -f $file
if [ ${1:-0} -gt 0 -a -e /proc/acpi/alarm ] ; then
date -d 1970-01-01 UTC $1 sec -$delay min +%Y-%m-%d %H:%M:%S $file
fi
exec sudo /sbin/shutdown -h now
and from halt.local (this is what is instructed in vdr README.package)
#!/bin/bash
wakeupfile=/var/lib/vdr/acpi-wakeup
trap rm -f $wakeupfile EXIT
if [ -s $wakeupfile -a -w /proc/acpi/alarm ] ; then
echo -n Setting ACPI wakeup for next VDR timer: ; cat $wakeupfile
cat $wakeupfile /proc/acpi/alarm
fi
---
But it does not wake up. And this is not a very old mb. So I assume I am
doing something wrong or not doing something I should.
I got it to boot up using nvram-wakeup with reboot option (after guess
helper). But as said nvram should be obsolete and replaced by acpi.
On another mb (4CoreDual-Sata23) I used
---
newtime=$(($1 - delay*60 )) # delay minutes earlier
echo $newtime /sys/class/rtc/rtc0/wakealarm
---
which did the trick.
On biostar there were no /sys/class/rtc
So I tried from http://www.vdr-wiki.de/wiki/index.php/ACPI_Wakeup (as
someone mentioned in this thread)
--
#!/bin/bash
# Startet dem Rechner nach 3 min ueber acpi neu.
min=`date +%M`
nextmin=`expr $min + 3`
nextboot=`date +%Y-%m-%d %H:$nextmin:00`
echo $nextboot /proc/acpi/alarm
echo Aktuelle Zeit: `date +%Y-%m-%d %H:%M:%S`
echo Starte Rechner neu um: `cat /proc/acpi/alarm`
echo Fahre Rechner nun runter.
busybox poweroff
#/usr/bin/poweroff.pl
#poweroff
---
I can read germany but I do not understand it :). But understood that I
could use that script to test acpi. Well this did not work. I did check
that the time was actually written in /proc/acpi/alarm. Still not waking up.
So where do I go here? Do I use nvram-wakeup which IMHO is not good
because of the reboot.
\\Kartsa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hallo,
yum MUST disable RTC-Wakeup in the BIOS of your motherboard. In my case I MUST
write the wakeuptime
twice:
example:
if [ ! -z $1 ]; then
newtime=$(($1 - 60 )) # 1 minutes earlier
logger VDR-Timer: $1
logger BIOS-Timer: $newtime
echo $(/bin/unix2iso8601 -u $newtime) /proc/acpi/alarm
echo $(/bin/unix2iso8601 -u $newtime) /proc/acpi/alarm
logger ACPI-Read: $(cat /proc/acpi/alarm)
else
logger VDR-Timer: keine Zeitübergabe
fi
dhe.
--
__\/__
. / ^ _ \ .
|\| (o)(o) |/|
#.OOOo--oo--oOOO.---#
# #
# [EMAIL PROTECTED] #
# #
#_Oooo._#
.oooO ( )
( )) /
\ ((_/
\_)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
