I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or "No signal". Any ideas?
This is my channels.conf entry:
Channel 4 HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0
Not much going on in syslog:
Mar 11 23:33:37 htpc vdr: [2449] switching to channel 126 Mar 11 23:33:37 htpc vdr: [2449] setstatus 0 Mar 11 23:33:37 htpc vdr: [3031] TS buffer on device 2 thread ended (pid=2449, tid=3031) Mar 11 23:33:37 htpc vdr: [3030] buffer stats: 63732 (3%) used Mar 11 23:33:37 htpc vdr: [3030] receiver on device 2 thread ended (pid=2449, tid=3030) Mar 11 23:33:37 htpc vdr: [2537] setstatus 0 Mar 11 23:33:37 htpc vdr: [2537] setstatus 1 Mar 11 23:33:37 htpc vdr: [2537] Filter Pid:0,Tid:0 added. Mar 11 23:33:37 htpc vdr: [3535] receiver on device 2 thread started (pid=2449, tid=3535) Mar 11 23:33:37 htpc vdr: [3536] TS buffer on device 2 thread started (pid=2449, tid=3536) Mar 11 23:33:38 htpc vdr: [2537] PMT scan idle Mar 11 23:33:38 htpc vdr: [2537] EEPG: FreeView Extended EPG detected on pid f02. Mar 11 23:33:38 htpc vdr: [2537] Loading table 1 Filename </var/lib/vdr/plugins/eepg/freesat.t1> Mar 11 23:33:38 htpc vdr: [2537] Loading table 2 Filename </var/lib/vdr/plugins/eepg/freesat.t2> Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:4e,Mask:fe added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:50,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:60,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:39,Tid:50,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:39,Tid:60,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:b0 added.
On Sun, 11 Mar 2012 23:41:06 +0000 Tony Houghton h@realh.co.uk wrote:
I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or "No signal". Any ideas?
This is my channels.conf entry:
Channel 4 HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0
I realised it has a different modulation (8PSK) from the working channels so I changed the parameters to VC23M5O0S1, but it still doesn't work :-(.
Are some DVB-S2 cards incapable of 8PSK? Mine's a TBS 6920.
On Mon, 12 Mar 2012 07:43:40 +0100 Mario Schulz drcms@arcor.de wrote:
Am 12.03.2012 01:07, schrieb Tony Houghton:
Are some DVB-S2 cards incapable of 8PSK? Mine's a TBS 6920.
Tried yr 2nd variant:
Channel 4 HD;Freesat:11126:VC23M5O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0
... reception tested ok here.
That's strange. I confirmed my card's OK after all, I managed to record a bit of the channel with hdvb.
On Sun, 11 Mar 2012 23:41:06 +0000 Tony Houghton h@realh.co.uk wrote:
I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or "No signal". Any ideas?
The plot thickens. I've done some more tests. I used hdvb to record samples of BBC 1 HD, ITV1 HD and Channel 4 HD. MPlayer can play all of them. It tells me BBC is 1440x1088, the others are 1920x1088. All appear to be interlaced.
BBC appears fine on my HTPC/TV, with sxfe configured for vdpau with bob deinterlacing. On a remote PC running sxfe (onboard Intel graphics, so no vdpau) I could see interlacing artifacts, probably because I configured deinterlacing off in VDR's OSD (see below).
ITV plays too slowly in sxfe on the HTPC. The graphics card is only an 8200 so I tried reconfiguring .xine/config_xineliboutput to use xv and turned off deinterlacing (see above). It didn't seem to make any difference, but the CPU is a 2.4GHz Athlon x2, so it should be fast enough. It was with MPlayer, and so was the other PC (a somewhat faster Core i5 2500k) with vdr-sxfe.
Channel 4 won't play at all in sxfe on either PC, but does in MPlayer.
Hi,
On 12.03.2012 00:41, Tony Houghton wrote:
I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or "No signal". Any ideas?
This is my channels.conf entry:
Channel 4 HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0
Works apparently well here with Channel 4 HD;BSkyB:11126:VC23M5O35S1:S28.2E:22000:2305=27:2307=NAR@4;2306=eng@106:2309;2308=eng:0:21200:2:2068:0
received with a rather problematic TechnoTrend Budget S2-3200 with CI.
Not much going on in syslog:
[...]
Mar 11 23:33:38 htpc vdr: [2537] PMT scan idle Mar 11 23:33:38 htpc vdr: [2537] EEPG: FreeView Extended EPG detected on pid f02. Mar 11 23:33:38 htpc vdr: [2537] Loading table 1 Filename </var/lib/vdr/plugins/eepg/freesat.t1> Mar 11 23:33:38 htpc vdr: [2537] Loading table 2 Filename </var/lib/vdr/plugins/eepg/freesat.t2>
Please forgive me for going off-topic, are you actually successfully using the EEPG plugin without segfaults? If so, which version, what sources? I dropped using it because it crashed my VDR every now and then, therefore I missed to record Episode 6/7 of the Top Gear Series 18 which just ended this weekend on BBC HD... On this 6th episode the BBC folks also surprisingly (for me) rescheduled the repeat on Thursday, I've always thought they are on Mondays or Wednesdays...
Do you British folks, or more generally, Freesat viewers know of any working alternatives to the EEPG plugin for the channels on S28.2E?
Regards, Lucian
On Mon, 12 Mar 2012 22:24:16 +0100 Lucian Muresan lucianm@users.sourceforge.net wrote:
Please forgive me for going off-topic, are you actually successfully using the EEPG plugin without segfaults? If so, which version, what sources? I dropped using it because it crashed my VDR every now and then,
I haven't noticed that problem. I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind.
I use 'apt-get source' to fetch the eepg plugin from the yavdr PPA:
deb-src http://ppa.launchpad.net/yavdr/unstable-vdr/ubuntu oneiric main
The binary package is incompatible with Debian unstable, but that source always compiles OK for me when a vdr upgrade makes it necessary. The current version is 0.0.5.git20110719-0yavdr5~0.1.
Do you British folks, or more generally, Freesat viewers know of any working alternatives to the EEPG plugin for the channels on S28.2E?
I used to use the patch from here: http://www.rst38.org.uk/vdr/.
On 12.03.2012 23:01, Tony Houghton wrote:
... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind.
Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR.
Klaus
On Tue, 13 Mar 2012 09:55:06 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 12.03.2012 23:01, Tony Houghton wrote:
... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind.
Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR.
No, I haven't seen anybody else complain about this either. It's been happening to me for quite a long time, for several versions. I use the Debian packages. I thought it could be the eepg plugin but disabling that didn't seem to fix the leak. I also use xineliboutput and remote plugins, but I've been using those for years, before the leak started.
At one point it stopped leaking and I realised I'd messed up my channels.conf so either all the DVB-T or all the DVB-S channels were broken and the leak came back when I fixed that. I think I tried reproducing similar conditions but for some reason I didn't make an effort to record or remember the results! I should repeat that and make notes, but it takes about a day on each run before I can be reasonably sure whether it's leaking or not.
On 13.03.2012 14:44, Tony Houghton wrote:
On Tue, 13 Mar 2012 09:55:06 +0100 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 12.03.2012 23:01, Tony Houghton wrote:
... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind.
Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR.
No, I haven't seen anybody else complain about this either. It's been happening to me for quite a long time, for several versions. I use the Debian packages. I thought it could be the eepg plugin but disabling that didn't seem to fix the leak. I also use xineliboutput and remote plugins, but I've been using those for years, before the leak started.
At one point it stopped leaking and I realised I'd messed up my channels.conf so either all the DVB-T or all the DVB-S channels were broken and the leak came back when I fixed that. I think I tried reproducing similar conditions but for some reason I didn't make an effort to record or remember the results! I should repeat that and make notes, but it takes about a day on each run before I can be reasonably sure whether it's leaking or not.
Can you give me an estimate of the rate at which memory is consumed? Maybe you could have a shell running the command
top -b -d 600 | grep -w vdr
for a while and see whether the numbers increase. This will show a line like
27558 kls 20 0 206m 49m 3860 S 2 2.5 0:33.44 vdr
every ten minutes, where "206m" and "49m" are the relevant columns.
Klaus
On Tue, 13 Mar 2012 16:11:44 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Can you give me an estimate of the rate at which memory is consumed? Maybe you could have a shell running the command
top -b -d 600 | grep -w vdr
At the moment:
25956 vdr 20 0 520m 213m 5136 S 0.7 11.3 28:27.27 vdr
After a restart:
24585 vdr 20 0 257m 43m 5316 S 0.0 2.3 0:00.88 vdr
It starts to have a noticeable impact on the box's general performance when %MEM reaches 50% IME.
I'll run top for longer like you suggest, then try all plugins disabled and with DVB-T and DVB-S lines removed from channels.conf in turn.
Am 13.03.2012 17:52, schrieb Tony Houghton:
memory leak
I just met hepi, he also is a Doctor Who fan and is tuned to Astra2 as I am. He complained about the bad status of EEPG, restarting his server every three days or so due to a memory leak within that plugin. As this is a 'must have' if you are on Freesat, it might be closely related, even if you feel it is not...
I personally do not care because I have the receiver off most of the time.
How would you analyze or debug a memory leak in a running environment: - which thread/plugin is the root cause? - which datastructure sees the growth? - which allocs are not bracketed by a proper de-alloc?
Here is the output:
3621 vdruser 20 0 636m 80m 17m S 2 1.1 0:00.78 vdr 3621 vdruser 20 0 638m 96m 17m S 3 1.3 0:17.30 vdr 3621 vdruser 20 0 643m 100m 17m S 3 1.3 0:34.20 vdr
On Tue, 13 Mar 2012 20:06:25 +0100 Mario Schulz drcms@arcor.de wrote:
Am 13.03.2012 17:52, schrieb Tony Houghton:
memory leak
I just met hepi, he also is a Doctor Who fan and is tuned to Astra2 as I am. He complained about the bad status of EEPG, restarting his server every three days or so due to a memory leak within that plugin.
I now also believe the leak is in the eepg plugin. I was probably still running it when I thought I was testing without a few months ago, because I didn't realise the debian init script/loader now automatically loads all installed plugins, not just the ones in order.conf.
As this is a 'must have' if you are on Freesat, it might be closely related, even if you feel it is not...
More important still with Freeview HD I think, because that doesn't even have EIT p/f in plain text like Freesat does.
I personally do not care because I have the receiver off most of the time.
How would you analyze or debug a memory leak in a running environment:
- which thread/plugin is the root cause?
- which datastructure sees the growth?
- which allocs are not bracketed by a proper de-alloc?
Debian also includes a script to run vdr in valgrind but it didn't find the leak even when I added the --show-reachable option. Perhaps I need to check the fork-related options.
I haven't tried static analysis of the source code so far because C++ isn't my forte. Are any of eepg's developers available to check into this?
Am 2012-03-26 16:44, schrieb Tony Houghton:
I was probably still running it when I thought I was testing without a few months ago, because I didn't realise the debian init script/loader now automatically loads all installed plugins, not just the ones in order.conf.
I am not aware that this ever has been the case. Must be more than 5 years ago then.
Gerald
On 26 March 2012 15:44, Tony Houghton h@realh.co.uk wrote:
How would you analyze or debug a memory leak in a running environment:
- which thread/plugin is the root cause?
- which datastructure sees the growth?
- which allocs are not bracketed by a proper de-alloc?
Debian also includes a script to run vdr in valgrind but it didn't find the leak even when I added the --show-reachable option. Perhaps I need to check the fork-related options.
I haven't tried static analysis of the source code so far because C++ isn't my forte. Are any of eepg's developers available to check into this?
When I briefly ran vdr under valgrind earlier this month, it threw up a number of potential memory leaks in eepg, so I'm surprised you're not seeing those. I'll have a quick look on my box later to see if I have the .log output handy.
EEPG also caused a segfault in VDR a few times whilst valgrind was running. Tbh it should probably be rewritten from scratch, ideally with separate plugins for each of the supported extended epg services, so you can run a minimal set.
-
Dominic Evans -
Gerald Dachs -
Klaus Schmidinger -
Lucian Muresan -
Mario Schulz -
Tony Houghton