[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), 0xFF);  // use the CAM slot with the lowest