Re: [vdr] VDR keeps a tuner busy when a recording is paused
On 28/11/2022 18:17, Marko Mäkelä wrote: Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote: FYI I'm using the powersaving patch on a system with an Astrometa USB stick + an old Winfast PCI receiver, and I see 2-3W reduction when the Astrometa frontend is shut down: I only tested with a single receiver. Your patch may very well switch off any additional receivers, but it seems to me that one front-end would always remain enabled. Yes - true - I only see frontend 1/0 powering down Richard ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR keeps a tuner busy when a recording is paused
Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote: FYI I'm using the powersaving patch on a system with an Astrometa USB stick + an old Winfast PCI receiver, and I see 2-3W reduction when the Astrometa frontend is shut down: I only tested with a single receiver. Your patch may very well switch off any additional receivers, but it seems to me that one front-end would always remain enabled. Today, I measured the power consumption again, with the Pi TV HAT attached, but without an aerial cable. The setup is a bit flimsy; like last year, the Raspberry Pi is displaying an undervoltage warning icon on the top right corner. I do not dare to over-volt the power supply. For comparison, I am quoting my figures from last year, without the Pi TV HAT, and with/without the Astrometa stick: I measured the following current draw at 5 volts, in ascending order: 81 mA: Raspberry Pi 2B shut down 127 mA: Raspberry Pi 2B + TV HAT shut down 200 mA: Raspberry Pi 2B powered up, no Ethernet plugged in 240 mA: Ethernet cable plugged in (HDMI cable makes no difference) 256 mA: Ethernet cable plugged in; Pi TV HAT attached 267 mA: Ethernet + HDMI plugged in; Pi TV HAT attached 320 mA: Ethernet + USB DVB stick plugged in 440 mA: compiling VDR with "make -j4" (all CPU cores busy) 480 mA: compiling (peak; sometimes as low as 300 mA) 550 mA: VDR playing back a recording 530 mA: recording paused in VDR 510 mA: EPG scan running 600 mA: VDR displaying live DVB-T2 440 mA: VDR started up, blank screen (no aerial plugged in) 510 mA: VDR playing back a recording (peak value) 450 mA: recording paused in VDR This time, I did not plug in an aerial cable at all. I would guess that displaying live TV would consume at most 550 mA. As you can see from the above, the idle consumption is about 260 mA. When VDR is seemingly idle, I am seeing additional consumption of around 200 mA. Notably, after I killed the vdr process, the power consumption would hover around 330 mA. It could be that my version of rpihddevice is not properly shutting down all processes on the Videocore IV GPU. After I restarted the VDR process, I got a similar power consumption as above. While it does not like we can blame the active tuner for all of the additional consumption of 200 mA, I think that we can attribute at least 100 mA to it. The difference between 260 mA and 450 mA is +70%, not insignificant. I am glad to see that the Pi TV HAT is consuming less power than the Astrometa stick. It is logical, because the TV HAT does not have to run an additional 8051 microcontroller and a step-down SMPS to produce 3.3V from the 5V USB supply, and presumably at least one separately packaged memory chip. But I'm still running V2.20 and have a workaround for the 2 frontends on the Astometa - both for reasons mentioned before on this list. Yes, I remember the frontend-swapping issue on the Astrometa. It may have been fixed in 2.6. I didn't try the Astrometa stick on my Pi after reinstalling Raspberry OS Legacy from the scratch. Marko ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR keeps a tuner busy when a recording is paused
I conducted this test without applying the patch
https://github.com/glenvt18/vdr/commit/b368f67d00d0b466ae36028efb9336e81f77dba8
As far as I can tell, even with that patch the EPG parser could keep
running, because the patch does not set the variable InhibitEpgScan.
That would explain why the patch did not help reduce VDR power
consumption with the Astrometa USB stick.
Thanks for the info on CPU use etc.
FYI I'm using the powersaving patch on a system with an Astrometa USB
stick + an old Winfast PCI receiver, and I see 2-3W reduction when the
Astrometa frontend is shut down:
Nov 27 20:13:09 ha-server vdr[7196]: [7196] frontend 1/0 provides DVB-T,DVB-T2,DVB-C with
QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Sony CXD2837ER DVB-T/T2/C demodulator")
Nov 27 20:49:08 ha-server vdr[12959]: [12959] dvb tuner: power-down - closing
frontend 1/0
But I'm still running V2.20 and have a workaround for the 2 frontends on
the Astometa - both for reasons mentioned before on this list.
HTH/Richard
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR keeps a tuner busy when a recording is paused
Sun, Oct 17, 2021 at 10:52:11PM +0300, Marko Mäkelä wrote: I noticed that VDR is consuming about 5% of the CPU power according to "top". Could it not be made more event-based? It might be interesting to check with "powertop" how many wakeups per second there are, and with "perf record" and "perf replay" (or simply "perf top") where the CPU cycles are being spent when the playback of a recording is paused. I just conducted this experiment with VDR 2.6.1, rpihddevice, and a patch to support a /dev/lirc* remote (with no polling or wakeups in that thread). While a recording is paused, I see some VDR threads waking up periodically. I ran the command sudo perf record -p $(pgrep vdr") and hit ctrl-c (SIGINT) after a couple of minutes. I see the following threads in the "perf report" output: "dvbplayer", "ovgthread", "vdr" (something related to rpihddevice) "device 1 sectio" (cSectionHandler, possibly updating the EPG) "frontend 0/0 tu" (cDvbTuner) Updating the EPG is a valid reason to keep the tuner busy. I repeated this experiment once more, this time first manually triggering an update of the EPG, waiting it to finish, and then starting and pausing the playback of a recording, and finally running "perf record" for a couple of minutes while the recording was paused and there was no interaction with VDR. The result was the same: the system was apparently still parsing EPG data. I set some breakpoints to identify some possible culprits. This one is executed about once per second: #0 cSectionHandler::SetStatus (On=true) at thread.h:94 #1 0x00093c80 in cDevice::SetChannel (LiveView=false) at device.c:915 #2 0x00093fe0 in cDevice::SwitchChannel (LiveView=false) at device.c:815 #3 0x000ae8ac in cEITScanner::Process (this=) at eitscan.c:168 #4 0x000738cc in main () at vdr.c:1519 I see that there is a variable InhibitEpgScan, but the scan can only be disabled based on the availability of a tuner. Thus, VDR never seems to disable all tuners or completely suspend the parsing of EPG data. The main loop in that thread wakes up once per second due to the following: #4 0x00101b38 in cRemote::Get (WaitMs=1000, UnknownCode=0x0) at remote.c:194 #5 0x000b87d8 in cInterface::GetKey (Wait=true) at interface.c:36 #6 cInterface::GetKey (Wait=true) at interface.c:31 #7 0x00072e4c in main () at vdr.c:1206 I think that a periodic wakeup in the main loop is reasonable. It would still be good to disable the tuners when they are not really needed. I conducted this test without applying the patch https://github.com/glenvt18/vdr/commit/b368f67d00d0b466ae36028efb9336e81f77dba8 As far as I can tell, even with that patch the EPG parser could keep running, because the patch does not set the variable InhibitEpgScan. That would explain why the patch did not help reduce VDR power consumption with the Astrometa USB stick. I have not tried to measure the power consumption of the Pi TV HAT yet. Best regards, Marko ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
