vdr July 2010

vdr@linuxtv.org

36 participants
37 discussions

VDR & Multiple frontends
by Eddi 25 Jul '15

25 Jul '15

Hi, I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend. So I get: /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/net1 The bus of the two frontend is shared, isn't possible to get access to both frontend simultaneously, so I get an -EBUSY error by trying accessing frontend1 if frontend0 is in use. VDR doesn't support yet the second frontend, and it try to get exclusive access on both frontend on start, so the second frontend is inusabile. Vdr should probe for multiple frontend at start, and access frontend only on channel change. Please can someone give me an help to wrote a patch for this issue? Best Regards, Eddi

4 21

vdr xine-lib eac3
by zaverel 10 Jul '12

10 Jul '12

hello your second patch doesn't work : no sound on eac3 channel if you want there is a sample of vdr hd-eac3 recording here: http://dl.free.fr/ew4rJddM8 103mo else , i don't know what mailing-list is the more indicate for debuging the vdr or xine-dev mailing-list ?

7 38

[ANNOUNCE] noad-0.7.1
by the Noad 01 May '12

01 May '12

Hi, there is a new version of noad at http://noad.heliohost.org This Version handles also TS-Recordings. Greetings theNoad

7 10

[ANNOUNCE] vdr-pvrinput
by L. Hanisch 17 Sep '11

17 Sep '11

Hi all, The plugin for integrating analog MPEG2 cards by Hauppauge (et al.) into the vdr has a new home. http://projects.vdr-developer.org/projects/show/plg-pvrinput It's adapted to the latest changes of vdr (>= 1.7.13). For older versions the plugin-param-patch is still needed. Take a look at the README to adjust your channels.conf to the matching syntax of your vdr. http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/README http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/HISTORY I think, it's stable enough to be tested by you. :-) Use the new home page for documenting bugs you encounter. A short changelog: - the generated TS now contains valid PAT, PMT and PCR packets so streaming with streamdev-server now works in TS mode. The used PIDs are the same as in the TS of cx18 cards, so the vdr will not alter them in mixed environments. vpid: 301+101=2 ; apid: 300 ; tpid: 305 - the Hauppauge HD PVR is now supported but uses different PIDs as the cx18/ivtv cards. vpid: 4113+4097=27 ; apid: 0;4352 - for radio channels no more video packets are sent. If you use a PVR350 as output device make sure you have a recent version of the pvr350-plugin which generates black video on its own. - if you use a PVRUSB2 make sure you have the latest driver otherwise you can see occasionally no picture after a channel switch. The corresponding patch of pvrusb2 will be integrated in kernel 2.6.34. - if you experience stuttering video on switching channels you can tweak some buffers with some parameters in the setup.conf (stop your vdr before editing, of course) pvrinput.ReadBufferSizeKB = 64 // size of buffer for reader in KB (default: 64 KB) pvrinput.TsBufferSizeMB = 3 // ring buffer size in MB (default: 3 MB) pvrinput.TsBufferPrefillRatio = 0 // wait with delivering packets to vdr till buffer is filled up to x% If the default values don't make you happy, please report working values for your setup. Please report also your used input and output devices. The latest versions of w_pvrscan and wirbelscan supports the new vdr 1.7.13 syntax if you don't want to change your channels.conf by hand. http://wirbel.htpc-forum.de/w_pvrscan/index2.html http://wirbel.htpc-forum.de/wirbelscan/index2.html Here's the announcement in the vdr-portal: http://www.vdr-portal.de/board/thread.php?threadid=95389 Have fun! Lars.

2 4

ATSC Channel frequency crashing VDR
by Rob Davis 24 Jun '11

24 Jun '11

Hi Guys, I have two ATSC adapter. On one I scan my channels, create my channels.conf file (via a convoluted script), the channels work on that laptop using 1.6. I make a couple of edits to allow it to work on 1.7.12, but a particular frequency causes VDR to crash and get restarted by the watchdog.. The offending frequency is 567000, It's a Qam256 ATSC Cable frequency. I have an HVR1850 PCI-E adapter. Unfortunetly, it's the mux with all my local SD channels, although I can watch the HD ones, two channels don't have HD versions.. I can't see anything in dmesg or the vdr log which causes a problem. As an aside, a scan using w_scan to create a kaffeine channels.conf file on that adapter, doesn't find anything on that frequency. Am I getting interference from something? Any ideas?

4 17

priorities in streamdev
by Rainer Blickle 13 Mar '11

13 Mar '11

Hi everybody, i have a question regarding the streamdev plugin. I have 2 tv cards, both gets accessed with the pvrinput plugin, but the problem i have would be the same with dvb devices. I also watch TV on the PC with the two cards. I have another pc (laptop) with vdr installed. There i installed the streamdev-client plugin. When switching the channel on the laptop with the up/down keys, the live picture gets interrupted with a black screen for about half a second. My wife doesn't like this very much. I had a look into the source code and found following: - The receiver of the pc has the priority 0, the receiver of the streamdev-server 1. - When switching with the up/down keys, the streamdev-client sends an "PROV"-Message to the streamdev-server. The streamdev-server tries to get a device (Method cServerConnection::GetDevice). The Receiver of the "old" streamdev-channel is still receiving. - The Method cServerConnection::GetDevice calls cDevice::GetDevice. The priority in the function call is 1. In the cDevice::GetDevice method the devices gets iterated, calling on each device the method cDevice::ProvidesChannel. Because the priority property of this call is 1, the "old" receiver of the streamdev-server has also a priority of 1 and the live-receiver has the priority of 0, the only device which can provide the channel is the device of the live-tv. - In the latter of the method cDevice::GetDevice the live-receiver gets detached via "d->DetachAllReceivers". Later in the code of cServerConnection::GetDevice, if the Method cDevice::GetDevice doesn't return a device, the current receiver gets detached. In my infrastructure this doesnt happend because the live receiver will nearly always gets detached ( The only exception is when a timer records). To prevent this, i changed the code in that way that the streamdev-receiver gets detached before calling cDevice::GetDevice). Is the detaching of live-tv an known issue or is this a feature ? Should have the live tv receiver a priority greather than streamdev-receiver ? If so, the live-tv wouldn't get detached ? Regards, Rainer

6 20

CAM auto resetting - feature request??
by Simon Baxter 27 Dec '10

27 Dec '10

Hello My v 1.6.0 system has 2x Alphacrypt multi-CAMs. Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both. I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back. Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed". My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state or 2)Be notified, by generating a console/kernel message, so I can know to come in and fix this. Any ideas?

7 20

Re: [vdr] ERROR: driver buffer overflow on device 1
by peter 07 Oct '10

07 Oct '10

>Does this happen too when not using vdpau? I'm not using vdpau (haven't got the hardware for it). vdr-1.7.10 xine-lib-1.2 The problem occurs when running xine with dxr3 output (xine --verbose=1 -V dxr3 -A alsa vdr:/tmp/vdr-xi/stream) Mar 18 13:26:43 vdr-desktop kernel: [ 6250.760298] em8300-0: adjusting scr: 30791 Mar 18 13:26:45 vdr-desktop kernel: [ 6252.872307] em8300-0: adjusting scr: 125823 Mar 18 13:27:05 vdr-desktop vdr: [4159] buffer usage: 70% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 80% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 90% (tid=4158) Mar 18 13:27:07 vdr-desktop vdr: [4159] buffer usage: 100% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4159] ERROR: driver buffer overflow on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4159] buffer usage: 30% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4158] ERROR: skipped 11 bytes to sync on TS packet on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (3) Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (11) Mar 18 13:27:18 vdr-desktop vdr: [4158] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame However: When running without dxr3 (xine --verbose=1 -V xshm -A alsa vdr:/tmp/vdr-xine/stream) everything is fine. Here's gdb output from a bad run: (gdb) thread apply all bt Thread 10 (Thread 0xb7648b70 (LWP 4030)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0x9d7fac4, Mutex=..., TimeoutMs=1000) at thread.c:127 #3 0x080afd3e in cDvbTuner::Action (this=0x9d7f508) at dvbdevice.c:389 #4 0x08119d40 in cThread::StartThread (Thread=0x9d7f508) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 9 (Thread 0xb6e47b70 (LWP 4031)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0x080ff76a in cSectionHandler::Action (this=0x9d6f610) at sections.c:184 #3 0x08119d40 in cThread::StartThread (Thread=0x9d6f610) at thread.c:257 #4 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (Thread 0xb6646b70 (LWP 4032)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 ---Type <return> to continue, or q <return> to quit--- #2 0x0811f97b in cPoller::Poll (this=0x64, TimeoutMs=100) at tools.c:1195 #3 0x002a513d in PluginXine::cXineRemote::Action (this=0x9d842d8) at xineRemote.c:157 #4 0x08119d40 in cThread::StartThread (Thread=0x9d842e8) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (Thread 0xb5e1ab70 (LWP 4033)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0xb5e1d7b8, Mutex=..., TimeoutMs=100) at thread.c:127 #3 0x00298ead in PluginXine::cXineLib::Action (this=0xb5e1d260) at xineLib.c:2632 #4 0x08119d40 in cThread::StartThread (Thread=0xb5e1d260) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (Thread 0xb5619b70 (LWP 4034)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0x0811a56e in cCondVar::TimedWait (this=0xb5e1d310, Mutex=..., TimeoutMs=100) at thread.c:127 #3 0x002a6278 in PluginXine::cXineExternal::Action (this=0xb5e1d2b8) at xineExternal.c:204 #4 0x08119d40 in cThread::StartThread (Thread=0xb5e1d2b8) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (Thread 0xb4e18b70 (LWP 4035)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5ec8b in read () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x00113901 in cRemoteDevInput::getKey() () from /usr/lib/vdr/libvdr-remote.so.1.7.10 #3 0x00113d87 in cRemoteGeneric::Action() () from /usr/lib/vdr/libvdr-remote.so.1.7.10 #4 0x08119d40 in cThread::StartThread (Thread=0x9d867f0) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xb4617b70 (LWP 4036)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0x0811f97b in cPoller::Poll (this=0x32, TimeoutMs=50) at tools.c:1195 ---Type <return> to continue, or q <return> to quit--- #3 0x080f9028 in cKbdRemote::ReadKey (this=0x9d86910) at remote.c:296 #4 0x080f90ce in cKbdRemote::ReadKeySequence (this=0x9d86910) at remote.c:312 #5 0x080f97c2 in cKbdRemote::Action (this=0x9d86910) at remote.c:353 #6 0x08119d40 in cThread::StartThread (Thread=0x9d86920) at thread.c:257 #7 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb3cf2b70 (LWP 4070)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5ec0b in write () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0029593a in PluginXine::cXineLib::xwrite (this=0xb5e1d260, f=7, b=0x9f65968, n=585) at xineLib.c:2457 #3 0x0029722b in PluginXine::cXineLib::execFuncStream (this=0xb5e1d260, Data=0x9f65968 "", Length=585) at xineLib.c:2937 #4 0x002972c4 in PluginXine::cXineLib::execFuncStream1 (this=0xb5e1d260, Data=0x9f65968 "", Length=585) at xineLib.c:2906 #5 0x00290072 in PluginXine::cXineDevice::PlayCommon3 (this=0xb5e1b008, Data=0x9f65968 "", Length=585, ptsForce=7920770849) at xineDevice.c:1969 #6 0x002900e5 in PluginXine::cXineDevice::PlayCommon2 (this=0xb5e1b008, Data=0x9f65968 "", Length=585, ptsForce=7920770849) at xineDevice.c:1849 #7 0x00290344 in PluginXine::cXineDevice::PlayCommon1 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, ptsForce=-1) at xineDevice.c:3134 #8 0x0029182a in PluginXine::cXineDevice::PlayCommon (this=0xb5e1b008, ---Type <return> to continue, or q <return> to quit--- Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:3092 #9 0x00293dab in PluginXine::cXineDevice::PlayVideo3 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=<value optimized out>) at xineDevice.c:2132 #10 0x0029469a in PluginXine::cXineDevice::PlayVideo2 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:2052 #11 0x002948b6 in PluginXine::cXineDevice::PlayVideo1 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:1781 #12 0x00294983 in PluginXine::cXineDevice::PlayVideo (this=0xb5e1b008, Data=0x9e1117c "", Length=2048) at xineDevice.c:1760 #13 0x0029088e in PluginXine::cXineDevice::PlayTsTrampoline (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=false) at xineDevice.c:1727 #14 0x002949d1 in PluginXine::cXineDevice::PlayVideo (this=0x249, Data=0xb3cf21dc "", Length=20) at xineDevice.c:1752 #15 0x080a8ad2 in cDevice::PlayPesPacket (this=0xb5e1b008, Data=0xb3cf21dc "", Length=20, VideoOnly=false) at device.c:1174 #16 0x00290a00 in PluginXine::cXineDevice::PlaySingleTs (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022---Type <return> to continue, or q <return> to quit--- ", Length=188, VideoOnly=<value optimized out>) at xineDevice.c:1646 #17 0x0028d838 in PluginXine::cXineDevice::PlayTsImpl (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=false) at xineDevice.c:1590 #18 0x0028e77a in PluginXine::cXineDevice::PlayTs (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=<value optimized out>) at xineDevice.c:1572 #19 0x08123541 in cPlayer::PlayTs (this=0x9da5a50, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188) at player.h:47 #20 cTransfer::Receive (this=0x9da5a50, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188) at transfer.c:46 #21 0x080a7438 in cDevice::Action (this=0x9d7d250) at device.c:1464 #22 0x08119d40 in cThread::StartThread (Thread=0x9d7d250) at thread.c:257 ---Type <return> to continue, or q <return> to quit--- #23 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #24 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb32f0b70 (LWP 4071)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a650 in cCondWait::Wait (this=0x9d9cc04, TimeoutMs=100) at thread.c:71 #3 0x080fd8d7 in cRingBuffer::WaitForPut (this=0x9d9cc00) at ringbuffer.c:58 #4 0x080fdc5c in cRingBufferLinear::Read (this=0x9d9cc00, FileHandle=13, Max=0) at ringbuffer.c:247 #5 0x080a5982 in cTSBuffer::Action (this=0x9d9cbb8) at device.c:1606 #6 0x08119d40 in cThread::StartThread (Thread=0x9d9cbb8) at thread.c:257 #7 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb77a96d0 (LWP 4026)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0x817e080, Mutex=..., TimeoutMs=1000) at thread.c:127 ---Type <return> to continue, or q <return> to quit--- #3 0x080f9258 in cRemote::Get (WaitMs=1000, UnknownCode=0x0) at remote.c:191 #4 0x08126826 in main (argc=9, argv=0xbfc82424) at vdr.c:920 /Peter Odéus

4 5

check cam status
by Simon Baxter 05 Sep '10

05 Sep '10

Hello I'm needing to reset my CAM periodically, and in order to do this I need to check it's status from outside VDR. I've been doing the following, which is not ideal: if [ $((`tail -n $LINES /var/log/messages | grep 'vdr:' | grep 'ERROR' | grep 'CI' | wc -l`)) = 0 ] to test for: "May 22 00:49:45 freddy vdr: [9061] ERROR: can't write to CI adapter on device 1: Input/output error " messages and then: "while [ $((`tail -n $LINES /var/log/messages | grep 'dvb_ca adapter 1: DVB CAM detected and initialised successfully' | wc -l`)) = 0 ]" to test it's recovered Does anyone have any better suggestions???

2 6

vdr-1.7.15 problem with TV
by Simon Baxter 05 Sep '10

05 Sep '10

Hi I've just installed vdr-1.7.15 on my development box which has a single TT-2300 DVB card and CAM installed. I'm using vdr-xine as my front end. When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable. logs look like this: Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available! The same setup works fine under vdr-1.6.0. Any ideas?

10 30

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr July 2010