Re: [vdr] CAM auto resetting - feature request??
Hi! Got the same problem here, would be nice to have at least a possibility to check for crashed CAM's per SVDRP and maybe the possibility to reset it. Regards Marco Simon Baxter schrieb: > 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? > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- Needful GbR Rheinstraße 60a Telefon +49 (0) 26 24 / 95 29 301 56203 Hoehr-Grenzhausen Telefax +49 (0) 26 24 / 95 29 303 http://www.needful.deE-Mail m...@needful.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No EIT for channel Yesterday
On Monday 10 Aug 2009, Tony Houghton wrote: > On Sun, 09 Aug 2009 23:01:07 +0200 > > In fact, it isn't just Yesterday, the entire Freeview network has no EPG > in VDR. I can tune to the channels though. The DVB-S EPG is present > though. Are you referring to Freeview, the UHF terrestrial DVB-T service in the UK, or Freesat, the free-to-air satellite service? FreeSAT uses a dedicated transponder to carry the EPG for all channels, and the information is carried using a non-standard coding scheme. There is a patch for Freesat at http://www.rst38.org.uk/vdr/ though I have no idea whether it works. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] optimize device selection
Timothy D. Lenz wrote: I don't yet know if this patch is the cause, but I have a setup I am working on which has a FusionHDTV7 dual express and after it has been running for a few days, vdr seems to loose contact with the second tunner. When selecting other channels using vdradmin and then going back to the channel it had been left on for awhile, I get the xine no signal screen. Switching to any other channel works. Using femon I switch tunners while on the channel that no longer works and it starts working. I can go to any channel and swith between the tunners and only get video on the first tunner. The problem may be triggered by recording but sure. The amount of time to pass for it to show changes. Using vdr-1.7.8 First I thought it was the driver crashing. So I tried restarting vdr, but not the drivers and that got the second tunner back. Hi, Sounds similiar to my problem description posted here some time ago: http://www.linuxtv.org/pipermail/vdr/2008-December/018991.html Nobody answered :(, so I am still using that getstream/iptv workaround. Hoped this patch could help me, but had no opportunity to check for this yet. Thanks, Janusz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No EIT for channel Yesterday
Hi I confirm it work nice , it read the EPG data from any "freesat" transpondeur you are and feed epg data transparently , usually watching ITV or BBC feed it @+ Selon Dave P : There is a patch for Freesat > at http://www.rst38.org.uk/vdr/ though I have no idea whether it works. > -- > Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] optimize device selection
The patch in the previous message is not complete, please use this one.
Thanks Timothy D. Lenz
Regards,
--
Hi,
I have a update to this patch (attached file), try it and keep me
inform about your problem.
this patch is for vdr-1.7.8
Regards,
2009/8/8 Timothy D. Lenz :
> I don't yet know if this patch is the cause, but I have a setup I am working
> on which has a FusionHDTV7 dual express and after it
> has been running for a few days, vdr seems to loose contact with the second
> tunner. When selecting other channels using vdradmin and
> then going back to the channel it had been left on for awhile, I get the xine
> no signal screen. Switching to any other channel
> works. Using femon I switch tunners while on the channel that no longer works
> and it starts working. I can go to any channel and
> swith between the tunners and only get video on the first tunner. The problem
> may be triggered by recording but sure. The amount of
> time to pass for it to show changes.
>
> Using vdr-1.7.8
>
> First I thought it was the driver crashing. So I tried restarting vdr, but
> not the drivers and that got the second tunner back.
>
> - Original Message -
> From: "jlacvdr"
> To: "VDR Mailing List"
> Sent: Sunday, May 10, 2009 10:35 AM
> Subject: [vdr] [patch] optimize device selection
>
>
>> Hi,
>>
>> This patch is for vdr users's which have several cards.
>>
>> He changes the device selection, by adding two factors in the 'impact'
>> choice :
>> - prefering a already tuned device
>> - the last usage time of device
>>
>> So, all devices are used and zapping time is reduce.
>>
>> Works better when eitscanner is disable.
>>
>> Regards,
>>
>> JLac
>>
>
>
>
>
>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
diff -bBurN vdr-1.7.8-orig/device.c vdr-1.7.8/device.c
--- vdr-1.7.8-orig/device.c 2009-06-06 15:25:58.0 +0200
+++ vdr-1.7.8/device.c 2009-08-09 20:20:12.0 +0200
@@ -80,6 +80,7 @@
camSlot = NULL;
startScrambleDetection = 0;
+ startReceiving = 0;
player = NULL;
isPlayingVideo = false;
@@ -238,6 +239,43 @@
cDevice *d = NULL;
cCamSlot *s = NULL;
+ int deviceTuneOld[MAXDEVICES];
+ time_t deviceTuneAge[MAXDEVICES];
+ time_t now = time(NULL);
+ for (int i = 0; i < numDevices; i++)
+ {
+if( device[i]->IsTunedToTransponder(Channel) )
+{
+ now = 0;
+}
+ }
+
+ if( now != 0 )
+ {
+ for (int i = 0; i < numDevices; i++)
+ {
+ deviceTuneAge[i] = 1+(now-device[i]->startReceiving);
+ }
+ for (int i = 0; i < numDevices; i++)
+ {
+ int max = 0;
+ int idx = -1;
+ for (int j = 0; j < numDevices; j++)
+ {
+ if( deviceTuneAge[j] > max )
+ {
+max = deviceTuneAge[j];
+idx = j;
+ }
+ }
+ if( idx != -1 )
+ {
+ deviceTuneOld[idx] = i;
+ deviceTuneAge[idx] = 0;
+ }
+ }
+ }
+
uint32_t Impact = 0x; // we're looking for a device with the least impact
for (int j = 0; j < NumCamSlots || !NumUsableSlots; j++) {
if (NumUsableSlots && SlotPriority[j] > MAXPRIORITY)
@@ -260,6 +298,9 @@
// to their individual severity, where the one listed first will make the most
// difference, because it results in the most significant bit of the result.
uint32_t imp = 0;
+
+ imp <<= 1; imp |= device[i]->IsTunedToTransponder(Channel) ? 0 : 1; // prefer device already tune
+ imp <<= 3; imp |= deviceTuneOld[i] & 0x07; // sort devices by last time usage
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
@@ -286,6 +327,7 @@
break; // no CAM necessary, so just one loop over the devices
}
if (d) {
+ d->startReceiving = time(NULL);
if (NeedsDetachReceivers)
d->DetachAllReceivers();
if (s) {
diff -bBurN vdr-1.7.8-orig/device.h vdr-1.7.8/device.h
--- vdr-1.7.8-orig/device.h 2009-06-06 13:15:49.0 +0200
+++ vdr-1.7.8/device.h 2009-08-09 20:20:12.0 +0200
@@ -333,6 +333,7 @@
private:
time_t startScrambleDetection;
+ time_t startReceiving;
cCamSlot *camSlot;
public:
virtual bool HasCi(void);
__
Re: [vdr] No EIT for channel Yesterday
On Mon, 10 Aug 2009 12:03:28 +0100 Dave P wrote: > On Monday 10 Aug 2009, Tony Houghton wrote: > > On Sun, 09 Aug 2009 23:01:07 +0200 > > > > In fact, it isn't just Yesterday, the entire Freeview network has no EPG > > in VDR. I can tune to the channels though. The DVB-S EPG is present > > though. > > Are you referring to Freeview, the UHF terrestrial DVB-T service in the UK, > or Freesat, the free-to-air satellite service? FreeSAT uses a dedicated > transponder to carry the EPG for all channels, and the information is > carried using a non-standard coding scheme. There is a patch for Freesat > at http://www.rst38.org.uk/vdr/ though I have no idea whether it works. Freeview is the one I'm having the problem with. I am using the Freesat patch because I've got both types of card; the Freesat EPG is working, the Freeview one isn't. I'll have a look at the patch later and confirm that it adds the Freesat pids rather than replacing the standard ones, but I'm sure they both used to work together and I haven't changed anything recently. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] No audio with recordings, XBMC frontend, LATM AAC
Hi, I'm setting up VDR using xbmc as a frontend as described here: http://xbmc.org/forum/showthread.php?t=45314&highlight=audio I've got live streaming working well but have an issue with recordings where no audio comes through. I am using mirak's VDR 1.7.7 from the repository here: https://launchpad.net/~mirak-mirak/+ppa-packages Could this have something to to do with the audio used for NZ tv which broadcasts in LATM encapsulated AAC? I'm not sure why the streamed live tv would work fine and the recordings don't though. Any pointers much appreciated. Thanks, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
