Re: [vdr] dvb-ttpci: ARM crashed @ card 1
Rainer Zocholl wrote: until he learned that every card in the system MUST have a -good- antenna signal, regardless if the card is used or not... because EPG scan would use every card and that VDR behaves -unexpectable- sick without -good- antenna signals. I cannot confirm that. My VDR always had strange tuning problems that are caused by mysterious hardware problems (including some time on VDR 1.4.7), so having no signal on DVB-S is not un-typical for my system. I also had no issues while experimenting with DVB-T - which typically includes having no signal. ;) I never had a restart due to EPG scan (at least not directly *), and a missing signal for live viewing never caused more than a black screen. I never had ARM crashes because of signal quality. Restarts only happened for me if a recording got no signal. (* I had some times where tuning card 1 to channel X because of EPG scan would cause the recording card 0 to loose signal) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
Rainer Zocholl wrote: This unloading leads to ACPI interrupr errors On the VDR console i could see 3 line ACPI disabling interupt This is not an error. If a DVB driver is unloaded, its IRQ is unused and ACPI disables this IRQ line. As soon as the driver gets loaded again, the ACPI IRQ will be enabled again. For me, this is shown in syslog like this: kernel: ACPI: PCI interrupt for device :00:13.0 disabled kernel: saa7146: unregister extension 'budget dvb'. [...] kernel: ACPI: PCI Interrupt :00:13.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 kernel: saa7146: register extension 'budget dvb'. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] demuxing subtitles with projectx
On 02/12/08 02:43, Petri Helin wrote:
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?
I think this is totally unrelated.
The 0x21 in dvbsubtitle.c is about how the bitmap data is encoded,
while the 0x21 you mean is handled in cDevice::PlayPesPacket():
uchar SubStreamId = Data[PayloadOffset]; here's your 0x21
uchar SubStreamType = SubStreamId 0xF0;
uchar SubStreamIndex = SubStreamId 0x1F;
...
switch (SubStreamType) {
case 0x20: // SPU
case 0x30: // SPU
SetAvailableTrack(ttSubtitle, SubStreamIndex,
SubStreamId);
if ((!VideoOnly || HasIBPTrickSpeed())
currentSubtitleTrack !
w = PlaySubtitle(Start, d);
break;
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
Rainer Zocholl wrote: For who knows french, there is an interresting thread about udev on the dvbkivabien forum. I did use it to have my nexus always as primary device http://dvbkivabien2.info/viewtopic.php?f=21t=11255 Vous devez tre inscrit et connect pour pouvoir consulter le contenu de ce forum. I assume in english this would be translated as forget it :-( For those who are curious, there's a public login registered on bugmenot.com. Just use user=bugmenot pass=bugmenot. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-ttpci: ARM crashed @ card 1
Udo Richter [EMAIL PROTECTED] writes: I cannot confirm that. My VDR always had strange tuning problems that are caused by mysterious hardware problems (including some time on VDR 1.4.7), so having no signal on DVB-S is not un-typical for my system. Same here. I'm using two Nova-Ts for DVB-T and a TT 2.3 for output. I don't even have a satellite dish! Cheers, Jan -- Jan Exner · [EMAIL PROTECTED] · 0x9E0D3E98 · http://www.jan-exner.de/ Neues aus Frankreich und England http://www.jan-exner.de/uk.html ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-ttpci: ARM crashed @ card 1
[EMAIL PROTECTED](Udo Richter) 16.02.08 12:01 Rainer Zocholl wrote: until he learned that every card in the system MUST have a -good- antenna signal, regardless if the card is used or not... because EPG scan would use every card and that VDR behaves -unexpectable- sick without -good- antenna signals. I cannot confirm that. My VDR always had strange tuning problems that are caused by mysterious hardware problems (including some time on VDR 1.4.7), so having no signal on DVB-S is not un-typical for my system. 1.4.3 had the problem to restart vdr in such cases, beraking all other recording(*). This restart is not very noticable in the recording. Only some 10sec are missing, similar to an intented directors cut. If one does not watch live via VDR he would not surely notice that there is a problem at all. I also had no issues while experimenting with DVB-T - which typically includes having no signal. ;) So why i had no live image but OSD? Isn't the ARM not required for the OSD? I never had a restart due to EPG scan (at least not directly *), Me too (*) :-) I have to disable EPG scan because i have 3 Cards but only a single LNB! And, the Single-LNB-Patch did still not made its may into the release, so if EPG scan starts after an unpredictable time it will try to switch polarization, what fails and leads to no a signal condition witch is not detected to the EPGscan. So it again and again try to switch to that channel (see log in last mail) instead of skipping it. At least the logfile entries gives that impression. and a missing signal for live viewing never caused more than a black screen. I never had ARM crashes because of signal quality. The crash was detected after i selected a replay, not because of the (EPG)selected channel dead DVB-T. I assume that was the reason for the black screen. Step by step: I saw VDR box was running what should not be at that time. I turned on the TV-set Nothing but a black screen was shown, too no sound. I selected channel 1 (DVB-S, ARD) I saw the program info in the OSD The time was OK, and the Info was current. Went into the OSD VDR menu Restart VDR (not the box!) Nothing changed: Still no live video I selected a reecording Replay starts with image and sound I stopped the replay Now live was displayed including audio! Asking: What exactly happend? Why solves a replay the black screen problem? After that i turned on ssh and grabbed the log i mailed yesterday. Saw that for hours VDR tried to swicth to channel 87, what's DVB-T Found ARM crashed message during the replay phase. Hope it becomes more clearer now? Restarts only happened for me if a recording got no signal. VDR restart did not help. IOW: During a VDR restart the crashed ARM was not detected and the black screeen state not healed. (* I had some times where tuning card 1 to channel X because of EPG scan would cause the recording card 0 to loose signal) Maybe you need the single-LNB patch too? ;-) Rainer---= Vertraulich // // =--ocholl, Kiel, Germany ___ 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) 16.02.08 12:12 Once upon a time Udo Richter shaped the electrons to say... Rainer Zocholl wrote: This unloading leads to ACPI interrupr errors On the VDR console i could see 3 line ACPI disabling interupt This is not an error. If a DVB driver is unloaded, its IRQ is unused and ACPI disables this IRQ line. Ah, thanks. good to know. As soon as the driver gets loaded again, the ACPI IRQ will be enabled again. For me, this is shown in syslog like this: kernel: ACPI: PCI interrupt for device :00:13.0 disabled kernel: saa7146: unregister extension 'budget dvb'. [...] kernel: ACPI: PCI Interrupt :00:13.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 kernel: saa7146: register extension 'budget dvb'. So that does not explain the problem. Sad ;-( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to avoid: VPS-Aufnahme beginnt in K ürze
On 02/10/08 20:51, Rainer Zocholl wrote: Hello after upgrading from 1.4.3 to 1.4.5 i am sometimes kicked off the live view with warning VPS-Aufnahme beginnt in Kürze I can switch back to channel i want to see, but not for long. I have 3 FF cards so usually there would be a free card to get the VPS signal. After the VPS recording has started, the card seems to be free. I rember that at 1.4.3 a short discussion occurs. One said: That the good way, simply don't use VPS the other said: I have a patch, the only disadvantage: Your screen will blank for fractions of a second at some/every start of recording. Of cause only the second solution would be the least annoying, but obvioulsy, VDR choose the non-user-compatible way? :-( What do have to do to avoid this annoying card locking in the VPS-margin? (See below only 2 transponders are involved, the system has 3(!) DVT-S FF cards.) 58:03 : [3595] timer 13 (16 2000-2017 VPS 'A') entered VPS margin 58:04 : [3595] switching to channel 16 58:05 : [3754] channel 1 (Das Erste) event Son 10.02.2008 19:20-20:00 (VPS: 10.02 19:20) 'Weltspiegel' status 1 58:05 : [3595] info: VPS-Aufnahme beginnt in Kürze! 58:05 : [3754] channel 10 (SWR Fernsehen BW) event Son 10.02.2008 19:58-20:00 (VPS: 10.02 19:58) 'Baden-Württemberg Wetter' status 4 58:05 : [3754] channel 1 (Das Erste) event Son 10.02.2008 20:00-20:15 (VPS: 10.02 20:00) 'Tagesschau' status 2 58:07 : [3595] timer 75 (18 2000-2010 VPS 'K') entered VPS margin 58:18 : [3754] channel 12 (hr-fernsehen) event Son 10.02.2008 19:58-20:00 (VPS: 10.02 19:58) 'hessenschauwetter' status 4 58:20 : [3595] switching to channel 5 58:29 : [3595] switching to channel 16 58:30 : [3595] info: VPS-Aufnahme beginnt in Kürze! 58:52 : [3595] switching to channel 5 58:58 : [3595] switching to channel 15 59:00 : [3595] timer 11 (3 1910-1959 'R') stop 59:01 : [3595] switching to channel 16 59:01 : [3595] info: VPS-Aufnahme beginnt in Kürze! vdr:/var/lib/vdr# cat timers.conf | grep -n -e \-S:2000: -e \-S:19 11:1:S19.2E-1-1079-28007:--S:1910:1959:50:7:R: 12:5:S19.2E-1-1079-28006:--S:1930:2014:50:6:E: 13:5:S19.2E-1-1101-28112:--S:2000:2017:50:68:A: 75:5:S19.2E-1-1101-28109:--S:2000:2010:50:7:K: I tried this with VDR 1.5.13 (AFAICS there was no change regarding VPS recordings in vdr.c since 1.4.7) by programming 4 recordings on 2 transponders, all with VPS. I had to increase the VPS margin to have them all within the VPS margin, but the live channel was never switched away. I have 3 DVB-S cards in my system. Does your system have 3 DVB-S cards? You wrote DVT-S, so I'm wondering if this was just a typo. Can all your DVB-S cards be tuned independent of each other? IIRC you're using the lnb sharing patch, which might interfere here. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: can't set PID xxxx on device y
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting
this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just
thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like
SetCurrentSubtitleTrack() calls AttachReceiver() on the
PrimaryDevice() which is cXineDevice in my case.
(gdb) bt
#0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131,
PidType=ptOther) at device.c:612
#1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8,
Receiver=0xb44e2078) at device.c:1502
#2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8,
Type=ttSubtitle, Manual=false) at device.c:1052
#3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at
device.c:1104
#4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8,
Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 deu,
Description=0x0) at device.c:984
#5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8,
LiveView=true) at device.c:845
#6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8,
Channel=0x82526c8, LiveView=true) at device.c:735
#7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at
channels.c:1201
#8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a
cLiveSubtitle instance is created although none is needed in
transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone !Replaying()
!Transferring()) {
1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack);
1050 if (TrackId TrackId-id) {
1051liveSubtitle = new cLiveSubtitle(TrackId-id);
1052AttachReceiver(liveSubtitle);
1053}
1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually
only started after SetChannel() has ended. Therefore, as you correctly
pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode)
EnsureAudioTrack(true);
EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) {
EnsureAudioTrack(true);
EnsureSubtitleTrack();
}
Could you please test this?
Klaus
Still waiting for verification.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: can't set PID xxxx on device y
Klaus Schmidinger wrote:
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting
this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just
thought to let Klaus know about it, in case it would make some sense to
him.
I came across this log message today, too. Looks like
SetCurrentSubtitleTrack() calls AttachReceiver() on the
PrimaryDevice() which is cXineDevice in my case.
(gdb) bt
#0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131,
PidType=ptOther) at device.c:612
#1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8,
Receiver=0xb44e2078) at device.c:1502
#2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8,
Type=ttSubtitle, Manual=false) at device.c:1052
#3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at
device.c:1104
#4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8,
Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 deu,
Description=0x0) at device.c:984
#5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8,
LiveView=true) at device.c:845
#6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8,
Channel=0x82526c8, LiveView=true) at device.c:735
#7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at
channels.c:1201
#8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a
cLiveSubtitle instance is created although none is needed in
transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone !Replaying()
!Transferring()) {
1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack);
1050 if (TrackId TrackId-id) {
1051liveSubtitle = new cLiveSubtitle(TrackId-id);
1052AttachReceiver(liveSubtitle);
1053}
1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually
only started after SetChannel() has ended. Therefore, as you correctly
pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode)
EnsureAudioTrack(true);
EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) {
EnsureAudioTrack(true);
EnsureSubtitleTrack();
}
Could you please test this?
Klaus
Still waiting for verification.
Sorry, had forgotten this... I made the change you suggested in
device.c, but I am still seeing the error message.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe don't start..
Hi! Something went wrong when I update/re-emerge vdr.. Now vdr-sxfe don't start and giving reason: xine: cannot find input plugin for MRL [xvdr://127.0.0.1#nocache;demux:mpeg_block] I have re-emerge xine-lib vdr-xineliboutput and all other mpeg related packages.. No help. vdr system behind works fine, I can use vdr-sxfe from other computer to connect my vdr box.. Here is full startup log of vdr-sxfe: = vdr-sxfe 1.0.0rc2 (build with xine-lib 1.1.10, using xine-lib 1.1.10) Verbose mode VDR server not given, searching ... --- WARNING: MRL not given and server not found from local network. Trying to connect to default port on local host. --- load_plugins: skipping unreadable plugin directory /var/vdr/.xine/plugins. load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_yuv4mpeg2.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_esd.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_flac.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_flac.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_vidix.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_vidix.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_dvd.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_file.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_jack.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xvmc.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_http.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_avi.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_oss.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_fb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mng.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mpeg_elem.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_yuv_frames.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mpeg_ts.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_spudvb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xcbshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_sdl.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_real.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_v4l.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_v4l.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_sputext.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_image.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_spu.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_aa.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_iff.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_rgb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_tvtime.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_switch.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin
Re: [vdr] vdr-sxfe don't start..
On Sat, 16 Feb 2008 13:05:54 +0200 JJussi [EMAIL PROTECTED] wrote: Hi! Something went wrong when I update/re-emerge vdr.. Now vdr-sxfe don't start and giving reason: xine: cannot find input plugin for MRL [xvdr://127.0.0.1#nocache;demux:mpeg_block] [snip] There seems to be no /usr/lib/xine/plugins/1.1.10/xineplug_inp_xvdr.so in your Xine plugin list. Is there such a file on your system (maybe it's in the wrong place, in some other directory)? If that file is missing or misplaced, the xineliboutput ebuild that you are using is probably broken. Regards, Niko Mikkilä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to avoid: VPS-Aufnahme beginnt in K�rze
[EMAIL PROTECTED](Klaus Schmidinger) 16.02.08 16:54 vdr:/var/lib/vdr# cat timers.conf | grep -n -e \-S:2000: -e \-S:19 11:1:S19.2E-1-1079-28007:--S:1910:1959:50:7:R: 12:5:S19.2E-1-1079-28006:--S:1930:2014:50:6:E: 13:5:S19.2E-1-1101-28112:--S:2000:2017:50:68:A: 75:5:S19.2E-1-1101-28109:--S:2000:2010:50:7:K: I tried this with VDR 1.5.13 (AFAICS there was no change regarding VPS recordings in vdr.c since 1.4.7) by programming 4 recordings on 2 transponders, all with VPS. I had to increase the VPS margin to have them all within the VPS margin, but the live channel was never switched away. What will happen it there was a third VPS recording already running on a third transponder? BTW: Meanwhile i did not see that switching away again. Does your system have 3 DVB-S cards? You wrote DVT-S, so I'm wondering if this was just a typo. I have 3 FF-DVB-S on one LNB and one DVB-T but i found that the 1350Ghz AMD Duron K7S8XE+ is overlaoded with 3 simlutanions recordings. Too i found that channel hopping on 1.4.7 so noticable slower than 1.4.3 but that may be a DVB-driver problem too as i run a 2.6 kernel now which has a known worser memory performance than 2.4. Too i see a noticable delay/skew between cursor movement and selection. (i press down, the cursor left moves 200ms later to next line, the higlight right moves approc. 300ms delayed.) Can all your DVB-S cards be tuned independent of each other? IIRC you're using the lnb sharing patch, which might interfere here. Ooops.. does VPS (now) cause channel switching as EGP scan? That would not be good because i currently use the unpatched orginal debian/elchi package because baking patches under debian is not very easy to automate. (OK, on vertical are only the garbage programs like RTL+ which do not support VPS and are not worth recording) Rainer lspci -v .. 00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6e00 (32-bit, non-prefetchable) [size=512] 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Avermedia Technologies Inc AverMedia AVerTV DVB-T 771 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at cecfe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Avermedia Technologies Inc AverMedia AVerTV DVB-T 771 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at cecff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6c00 (32-bit, non-prefetchable) [size=512] 00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6a00 (32-bit, non-prefetchable) [size=512] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
