Re: [vdr] lost comment in runvdr script
Matthias Becker wrote: Hi, when reorganizing my runvdr I found some lost comment in the file that is delivered with vdr 1.4.2. There is still some comment about the variable VDRUSR. It says: # Set the environment variable VDRUSR to the user id you # want VDR to run with. If VDRUSR is not set, VDR will run # as user 'vdr'. I'm afraid I can't find this in the 'runvdr' file that comes with VDR 1.4.2. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Recording stops and starts again
I seem to remember that there was a patch to prevent stopping and starting recording if audio-pid changes. Was there ? *** recording starts here *** Sep 2 20:47:30 vdr vdr: [2977] setting audio track to 1 (0) Sep 2 20:48:00 vdr vdr: [2891] switching device 3 to channel 2 Sep 2 20:48:00 vdr vdr: [2891] timer 1 (2 2048-2157 'Siska') start Sep 2 20:48:00 vdr vdr: [2891] Title: 'Siska' Subtitle: 'Viimeinen tehtävä. Siska ryhtyy tutkimaan yksityisetsivä Zellerin murhaa. Oliko Zeller saanut tietoonsa joitakin niin arkaluontoisia asioita, että hänet haluttiin vaientaa lopullisesti? Stereo.' Sep 2 20:48:00 vdr vdr: [2891] record /video/Siska/2006-09-02.20.48.99.99.rec Sep 2 20:48:00 vdr vdr: [2891] creating directory /video/Siska Sep 2 20:48:00 vdr vdr: [2891] creating directory /video/Siska/2006-09-02.20.48.99.99.rec Sep 2 20:48:02 vdr vdr: [2891] recording to '/video/Siska/2006-09-02.20.48.99.99.rec/001.vdr' Sep 2 20:48:02 vdr vdr: [2996] file writer thread started (pid=2891, tid=2996) Sep 2 20:48:02 vdr vdr: [2997] recording thread started (pid=2891, tid=2997) Sep 2 20:48:02 vdr vdr: [2998] receiver on device 3 thread started (pid=2891, tid=2998) Sep 2 20:48:02 vdr vdr: [2999] TS buffer on device 3 thread started (pid=2891, tid=2999) *** Program really starts and audio pids are set up*** Sep 2 20:50:12 vdr vdr: [2900] channel 2 (YLE TV2) event La 02.09.2006 20:50-21:47 'Siska' status 4 Sep 2 20:50:17 vdr vdr: [2900] buffer stats: 0 (0%) used Sep 2 20:50:18 vdr vdr: [2903] changing pids of channel 2 from 513+129:660=fin,661=sve:2321 to 513+129:660=deu:2321 Sep 2 20:50:18 vdr vdr: [2891] stopping recording due to modification of channel 2 Sep 2 20:50:18 vdr vdr: [2997] recording thread ended (pid=2891, tid=2997) Sep 2 20:50:18 vdr vdr: [2996] file writer thread ended (pid=2891, tid=2996) Sep 2 20:50:18 vdr vdr: [2891] buffer stats: 0 (0%) used Sep 2 20:50:18 vdr vdr: [2999] TS buffer on device 3 thread ended (pid=2891, tid=2999) Sep 2 20:50:18 vdr vdr: [2998] buffer stats: 78960 (3%) used Sep 2 20:50:18 vdr vdr: [2998] receiver on device 3 thread ended (pid=2891, tid=2998) Sep 2 20:50:18 vdr vdr: [2891] cTS2PES got 2 TS errors, 3 TS continuity errors Sep 2 20:50:18 vdr vdr: [2891] cTS2PES got 0 TS errors, 3 TS continuity errors Sep 2 20:50:18 vdr vdr: [2891] cTS2PES got 1 TS errors, 3 TS continuity errors Sep 2 20:50:18 vdr vdr: [2891] cTS2PES got 2 TS errors, 1 TS continuity errors Sep 2 20:50:18 vdr vdr: [2891] buffer stats: 105468 (2%) used Sep 2 20:50:18 vdr vdr: [2891] timer 1 (2 2048-2157 'Siska') stop Sep 2 20:50:18 vdr vdr: [2891] retuning due to modification of channel 2 Sep 2 20:50:18 vdr vdr: [2891] switching to channel 2 Sep 2 20:50:18 vdr vdr: [2977] transfer thread ended (pid=2891, tid=2977) Sep 2 20:50:18 vdr vdr: [2891] buffer stats: 68432 (3%) used Sep 2 20:50:18 vdr vdr: [3005] transfer thread started (pid=2891, tid=3005) Sep 2 20:50:18 vdr vdr: [2891] buffer stats: 0 (0%) used Sep 2 20:50:18 vdr vdr: [2891] switching device 3 to channel 2 Sep 2 20:50:18 vdr vdr: [2891] timer 1 (2 2048-2157 'Siska') start Sep 2 20:50:18 vdr vdr: [2891] Title: 'Siska' Subtitle: 'Viimeinen tehtävä. Siska ryhtyy tutkimaan yksityisetsivä Zellerin murhaa. Oliko Zeller saanut tietoonsa joitakin niin arkaluontoisia asioita, että hänet haluttiin vaientaa lopullisesti? Stereo.' Sep 2 20:50:18 vdr vdr: [2891] record /video/Siska/2006-09-02.20.48.99.99.rec Sep 2 20:50:18 vdr vdr: [2891] recording to '/video/Siska/2006-09-02.20.48.99.99.rec/002.vdr' Sep 2 20:50:18 vdr vdr: [3007] file writer thread started (pid=2891, tid=3007) Sep 2 20:50:18 vdr vdr: [3008] recording thread started (pid=2891, tid=3008) Sep 2 20:50:18 vdr vdr: [3009] receiver on device 3 thread started (pid=2891, tid=3009) Sep 2 20:50:18 vdr vdr: [3010] TS buffer on device 3 thread started (pid=2891, tid=3010) Sep 2 20:50:20 vdr vdr: [3005] setting audio track to 1 (0) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] When will first 1.5 version of VDR see the daylight?
Klaus Schmidinger wrote: Pasi Juppo wrote: Hi, Not that I have any urgent need for v1.5-series VDR but just interested in when first version is planned to released for public testing. Well, so far I've been busy doing maintenance patches for the 1.4-series, but I hope this will finally settle soon. I have seldom run into crash with 1.4.1 + maintenance patch. However, I have not been able to reproduce or get any log out of crash. v1.4.x is quite stable in my opinion. For everyday PVR usage it has not crashed once. Some plugins still causes some problems (mainly TV-OnScreen that crashes if there is a specific situation with empty column and user hits enter. Normal empty column problem works well. Unfortunately I cannot be more specific without further testing). The first thing I want to address in version 1.5 is the problem with systems that contain more than one CAM that implements a particular encryption method, but only one (or not all) of them actually has a smart card to decrypt a given channel. This is not an easy task, because the DVB standard is pretty messy in that area, and the few useful things it defines aren't even implemented (correctly) in various CAMs. So I guess I'll need to actually try to receive a channel on each of the devices/CAMs that claim to be able to decrypt it, and see whether there is an actual decrypted TS delivered from it. Of course this makes the whole process of selecting devices for recording or live view more complex... The other thing that goes into that direction is support for CAMs that can decrypt more than one channel at the same time. Once these two problems are solved, I'll release version 1.5.0 ;-) Thanks for the info! These features are not important for me so I'll be using v1.4.x a bit more longer :-) Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recording stops and starts again
Lauri Tischler wrote: I seem to remember that there was a patch to prevent stopping and starting recording if audio-pid changes. Was there ? ... *** Program really starts and audio pids are set up*** Sep 2 20:50:12 vdr vdr: [2900] channel 2 (YLE TV2) event La 02.09.2006 20:50-21:47 'Siska' status 4 The program starts at 20:50:12... Sep 2 20:50:18 vdr vdr: [2903] changing pids of channel 2 from 513+129:660=fin,661=sve:2321 to 513+129:660=deu:2321 ...but the audio pids are set up at 20:50:18, which is 6 (six!) seconds after the show has begun. I'd say you should contact your broadcaster and complain about this. The audio pids should be set up *before* the show starts. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput compilation error
I get the following error compiling xineliboutput: (xine-lib 1.1.2 (gentoo packaged), vdr 1.4.0 gcc -O2 -I/usr/include -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='xineliboutput' -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DXINELIBOUTPUT_VERSION='1.0.0pre3' -DYAEGP_PATCH -Wall -I/usr/src/v4l/v4l-dvb/linux/include -I../../../include xine_input_vdr.c xine_input_vdr.c:3181: error: `XINE_EVENT_VDR_INFO' undeclared here (not in a function) xine_input_vdr.c:3181: error: initializer element is not constant xine_input_vdr.c:3181: error: (near initialization for `vdr_keymap[55].event') xine_input_vdr.c:3181: error: initializer element is not constant xine_input_vdr.c:3181: error: (near initialization for `vdr_keymap[55]') xine_input_vdr.c:3183: error: initializer element is not constant xine_input_vdr.c:3183: error: (near initialization for `vdr_keymap[56]') xine_input_vdr.c: In function `track_audio_stream_change': xine_input_vdr.c:3877: error: `BUF_CONTROL_RESET_TRACK_MAP' undeclared (first use in this function) xine_input_vdr.c:3877: error: (Each undeclared identifier is reported only once xine_input_vdr.c:3877: error: for each function it appears in.) make[1]: *** [xine_input_vdr.o] Error 1 make[1]: Leaving directory `/usr/local/src/VDR/vdr-1.4.0/PLUGINS/src/xineliboutput-1.0.0pre3' ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: other rtp clients ?
[EMAIL PROTECTED] wrote: I'm the happy user of xineliboutput 1.0.0pre3. I'd like to know if it's possible for other rtp clients to play the multicast stream. (while xine+xineliboutput is playing it) In fact i'd like to be able to use vlc to transcode/re-stream it. I've tried, and was successful with udp://@224.0.1.9:37890 This is a multicast transmission, so the IP network will take care of connecting the client to the server. No need to specify any local IP address. You may need to initialize the connection with one of the remote clients first. Also, see option Remote Clients- Transmit always on - which seems to be buggy though. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
