[vdr] problem with patch

2008-01-05 Thread serge pecher
Hello, 

 

I did download
http://www.linuxtv.org/pipermail/vdr/attachments/20071124:f209db92/attachmen
t-0002.bin.

I am following the same wiki as for 1.5.10. (mv .., patch -p1 -I ..)

When I apply this patch I get :

Patch unexpectly ends in middle of line

Patch:  only garbage found in patch input.

 

No idea what to do ?

 

Thanks,

 

serge

 

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] problem with patch

2008-01-05 Thread Reinhard Nissl
Hi,

serge pecher schrieb:

> I did download
> http://www.linuxtv.org/pipermail/vdr/attachments/20071124:f209db92/attachment-0002.bin.
> 
> I am following the same wiki as for 1.5.10. (mv …., patch –p1 –I ….)
> 
> When I apply this patch I get :
> 
> Patch unexpectly ends in middle of line
> 
> Patch:  only garbage found in patch input.
> 
> No idea what to do ?

Well, you should have red
http://www.linuxtv.org/pipermail/vdr/2007-November/014748.html
more precisely:

.
.
.
Type: application/x-bzip2
.
.
.

You need to bunzip2 the attachment first before patching. I had
to bzip2 them due to mail size limitations on the mailing list.

BTW: why not using the revised patch from here?
http://www.linuxtv.org/pipermail/vdr/2008-January/014956.html

And apply this one afterwards, too:
http://www.linuxtv.org/pipermail/vdr/2008-January/015000.html

Watch out: the latter one is plain text, so no need to use
bunzip2 first.

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] [ANNOUNCE] Clock Plugin 0.0.8

2008-01-05 Thread Mario Aistleitner
Hello,

there is another small update for the clock plugin available. The new version 
can be found here [1]

2008-01-05: Version 0.0.8 (thanks to Tobias Grimm)
- Another correction on the Makefile
- Some adaption to satisfy correct implementation of the License

[1] http://vdr.aistleitner.info/vdr-clock-0.0.8.tgz

Greetings,
Mario

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

2008-01-05 Thread Reinhard Nissl
Hi,

Reinhard Nissl schrieb:

>> Well, I was in contact with Marco already and attached you'll
>> find a minimalistic change which reports "channel not available".
>> Now VDR should already be able to kick a low priority DVB-S
>> recording (or transfer thread) from a DVB-S2 device.
> 
> The previous patch was wrong. Only DVB-S2 devices "could" provide
> channels. The revised patch works now as expected.
> 
>> Still missing is to prefer DVB-S devices for DVB-S recordings so
>> that DVB-S2 devices remain available for DVB-S2 recordings of
>> same priority.
> 
> Still to do.

The attached version implements this behavior now. You may want
to experiment a bit with the decision logic as explained below.

The decision is based on the number of modulation systems a card
provides. For example, my NOVA-S provides one (DVB-S) and my
SkyStar HD provides three (DVB-S, DVB-DSS, DVB-S2).

The decision logic is implemented in cDevice::GetDevice(), so
have a look into device.c. After applying the patch, you'll find
two lines in that function marked with comments like /*1*/ and
/*2*/, and the latter one was disabled by a line comment.

In my scenario with just the above cards and vdr-xine as software
device, watching a channel requires VDR to operate in transfer
mode. Therefore it selects a device which provides for example a
DVB-S channel. The patched version will choose the NOVA-S with
either implementation /*1*/ or /*2*/.

Let's then start a DVB-S recording on a different transponder.
When implementation /*2*/ would be active, VDR would choose the
SkyStar HD, as the NOVA-S is claimed by transfer mode. Then, try
to switch to a DVB-S2 channel. It wouldn't work, as the SkyStar
HD would be claimed by a DVB-S recording.

That's why I've chosen implementation /*1*/ as default. For the
above scenario, starting a DVB-S recording on a different
transponder will choose the NOVA-S and kick off transfer mode.
Then VDR will look for a card to set up transfer mode again and
it will choose the only remaining card, the SkyStar HD. If you
then try to switch to a DVB-S2 channel, it will work as the
SkyStar HD is not claimed by a recording.

>> The patch is incremental to the original dvbs2 patch from
>> yesterday, i. e. you can simply apply it to your already patched VDR.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.12-dvbs2-other/device.c	2008-01-01 22:55:18.0 +0100
+++ device.c	2008-01-05 18:06:15.0 +0100
@@ -359,6 +359,21 @@ cDevice *cDevice::GetDevice(int Index)
   return (0 <= Index && Index < numDevices) ? device[Index] : NULL;
 }
 
+inline int GetClippedModulationSystemCount(int AvailableBits, cDevice *Device)
+{
+  int ModulationSystemCount = Device->ModulationSystemCount();
+  int MaxModulationSystemCount = 1 << AvailableBits;
+  if (ModulationSystemCount > MaxModulationSystemCount) {
+ esyslog("ERROR: device %d supports %d modulation systems but cDevice::GetDevice() currently only supports %d modulation systems which should be fixed", Device->CardIndex() + 1, ModulationSystemCount, MaxModulationSystemCount);
+ ModulationSystemCount = MaxModulationSystemCount;
+ }
+  else if (ModulationSystemCount <= 0) {
+ esyslog("ERROR: device %d reported an invalid number (%d) of supported modulation systems. The device should be fixed to return at least 1", Device->CardIndex() + 1, ModulationSystemCount);
+ ModulationSystemCount = 1;
+ }
+  return ModulationSystemCount;
+}
+
 cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
 {
   // Collect the current priorities of all CAM slots that can decrypt the channel:
@@ -408,11 +423,13 @@ cDevice *cDevice::GetDevice(const cChann
  imp <<= 1; imp |= LiveView ? !device[i]->IsPrimaryDevice() || ndr : 0;  // prefer the primary device for live viewing if we don't need to detach existing receivers
  imp <<= 1; imp |= !device[i]->Receiving() && (device[i] != cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice()) || ndr; // use receiving devices if we don't need to detach existing receivers, but avoid primary device in local transfer mode
  imp <<= 1; imp |= device[i]->Receiving();   // avoid devices that are receiving
+/*1*/imp <<= 2; imp |= GetClippedModulationSystemCount(2, device[i]) - 1;// avoid cards which support multiple modulation systems
  imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice();  // avoid the Transfer Mode receiver device
  imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF);   // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
  imp <<= 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] : 0) + MAXPRIORITY, 0),

[vdr] watching H.264 makes xine crash

2008-01-05 Thread vdr
Hi!

I'm having a problem with that xine crashes sometimes when I'm watching 
H.264 over DVB-S2. It looks like this in the logs

buffer usage: 498,  0,  0,  0, 0xcced10
buffer usage: 474,  0,  0,  0, 0xcced10
[h264 @ 0x2c2cb140]Interlaced pictures + spatial direct mode is not 
implemented
xiTK received SIGSEGV signal, RIP.
sh: line 1:  5411 Aborted /usr/local/bin/xine -f 
--no-splash -V xv --verbose=3 --post vdr_video --post vdr_audio --post 
upmix_mono vdr://tmp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log

and on other channels when it crashes
buffer usage: 111,  0, 11,  0, 0xccdbf0
buffer usage: 183,  0, 11,  1, 0xccdbf0
sh: line 1:  6731 Illegal instruction /usr/local/bin/xine -f 
--no-splash -V xv --verbose=3 --post vdr_video --post vdr_audio --post 
upmix_mono vdr://tmp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log

I'm having a Athlon 64 x2 4200' so I've been trying to overclock it 
today, everything else works fine, watching MPEG2 etc but as fast as I 
starts watching a MPEG4 channel it crashes with the above "illegal 
instruction" error after a few seconds. If I set it back to normal speed 
I can watch a few minutes before xine crashes.

Is there anyone that have a similar problem?

vdr-1.5.12 with the latest DVB-S2 H.264 patch
xine-lib/ui from http://home.vrweb.de/~rnissl/
FFMpeg CVS

Thanks for any help!

Best regards, Lars Fredriksson

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr