Opened 15 years ago

Closed 14 years ago

#5754 closed enhancement (wontfix)

Enhancement to make EIT Active Scanning end after a period, then restart later (a duty cycle)

Reported by: simonwalls@… Owned by: Stuart Auchterlonie
Priority: minor Milestone: unknown
Component: MythTV - EIT Version: 0.21-fixes
Severity: medium Keywords: active scan continuous
Cc: Ticket locked: no

Description (last modified by Janne Grunau)

Hi,

I want to see if the power consumption of my server reduces if I don't have a tuner card doing Active EIT Scan all the time. I am in the UK and using Nova-T PCI DVB cards.

Also, some folks have experienced issues which have been blamed on Myth's continuous EIT scanning. (Example: ticket #2741 : disable the active EIT scan for open on demand DVB cards. "Some dibcom based usb devices (including the Nova-T500) have a nasty bug which is mostly triggered by our continuous eit scanning.")

I have noticed on various forums, conversations mentioning how nice it would be to make EIT scanning have a duty-cycle rather than be continuous but it has not been possible to date. (However, it's not immediately apparent from mythtv-setup but it is true that Active EIT scan yields to a recording, so using Active Scan does not 'cost' you a tuner card, merely makes it busy when it's not being used for recordings).

So this patch is for a simple modification to the Active EIT Scan behaviour. It has hard-coded timing information, which it would be nice to ultimately have as a GUI control (in mythtv-setup, adjacent to the EIT Active Scan tickbox I guess....) but I have not got the skills to code that yet.

It shouldn't be necessary to scan EIT continously to keep a full program guide, and this patch will allow me to work out how much scanning time is required in general. I will also update this ticket with any power (ie. wattage) information I find out (I have a Nova-T PCI). It is very warm to the touch, so I hope that 'turning it off' (if this is what happens) is going to make it cool and save a few watts.

The patch is currently set to do 1 hour of scanning in every 8 hour period but this is easily adjustable, the appropriate places are commented.

Some backend logs are also attached, a full log, and a slimmed down log just showing the relevant EIT and TVRec log entries with timestamps. The timing works as expected, 1 hour of scanning then a 7 hour break. I am still testing and have some recordings scheduled today which will test the interruption by a recording, and restarting of the cycle.

Realistically I don't think I will get to add a GUI control in mythtv-setup, perhaps interfaced to mythconverg database entries to store user-changeable on-time and off-period (per card) for this 'Improved Active Scan' so if anyone else wants to write that, please do. GUI programming is not my forte.

Other possible improvements:

  • I originally wanted to make the scan duration dependent upon the number of multiplexes received by the card. This will be more scalable for when the number of multiplexes increases as it surely will. This information is in a different scope however, is is available in EITScanner not in TVRec. I'm sure a better programmer than I could make activeScanChannels more global, so that code in TVRec can find out its size.

Attachments (12)

activeeit-one-in-eight-hours.diff (5.2 KB) - added by simonwalls@… 15 years ago.
Patch for 0.21-fixes SVN 17451 to make Active EIT scan for only one hour in eight
patch-log-slimmed.txt (13.5 KB) - added by simonwalls@… 15 years ago.
Log of the above patch in operation, extraneous lines removed from log
patch-log.txt (145.6 KB) - added by simonwalls@… 15 years ago.
Log of the above patch in operation, virtually all log entries (personalisation removed)
activeeit-improved-021008.diff (7.0 KB) - added by simonwalls@… 15 years ago.
Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle
activeeit-improved-031008.diff (7.4 KB) - added by simonwalls@… 15 years ago.
Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle
activeeit-improved-031008b.diff (7.4 KB) - added by simonwalls@… 15 years ago.
Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle
eit-closedown-cx8802errors.txt (963 bytes) - added by simonwalls@… 15 years ago.
Parts of system messages and mythbackend.log when cx8802 dma messages started just after Active Scan stopped due to patch action
stress-test-mythbackend.log.gz (51.0 KB) - added by simonwalls@… 15 years ago.
Gzipped system log of 'stress test', see 09-10-2008 posting
more-server-logs.txt (3.1 KB) - added by simonwalls@… 15 years ago.
Snips of backend and system logs showing correlation of cx8802 dma error messages
SWpatch_activeeit-improved_031108.diff (8.2 KB) - added by simonwalls@… 15 years ago.
Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle. Does not cause cx8802 errors any more
SWpatch_activeeit-improved_081208.diff (8.4 KB) - added by simonwalls@… 15 years ago.
Patch against svn18900 0.21-fixes to further improve. Checks for running recording before closing channel.
strictly_notes.txt (6.5 KB) - added by simonwalls@… 15 years ago.
Notes on a recording seeming to be stopped by Active EIT scan (modified) closing the channel

Download all attachments as: .zip

Change History (37)

Changed 15 years ago by simonwalls@…

Patch for 0.21-fixes SVN 17451 to make Active EIT scan for only one hour in eight

Changed 15 years ago by simonwalls@…

Attachment: patch-log-slimmed.txt added

Log of the above patch in operation, extraneous lines removed from log

Changed 15 years ago by simonwalls@…

Attachment: patch-log.txt added

Log of the above patch in operation, virtually all log entries (personalisation removed)

comment:1 Changed 15 years ago by Janne Grunau

Description: modified (diff)
Milestone: unknown0.22
Priority: majorminor

Continuous scanning has advantages it can update program information in the case of last minute schedule changes.

The dibcom usb driver bug is resolved, changing the scanner for that isn't necessary anymore.

You shouldn't scan only for a limited period of time but until all transponders are scanned. Otherwise the current active scanner may miss some multiplexes for days.

comment:2 Changed 15 years ago by simonwalls@…

Thanks. Once I find out how many watts it saves, there may be no need for this patch (ie. it's not economically worthwhile).

You are right about scanning not for a fixed time, but until all transponders are scanned - this is what I meant above .... but I was unable to achieve that. I found the scope of 'activeScanChannels' meant I couldn't find out its size from within TVRec. Then the size could be used in the Duration calculation.

If this patch is justified based on power saving - I'll report back on that one - then maybe a better programmer can get it to scan until all muxes/transponders are scanned. Obviously, only if everything is right, could this patch be adopted.

comment:3 Changed 15 years ago by Janne Grunau

I would guess that the power savings are minimal especially compared to the power savings of powering down the backend when it isn't used for a couple of hours.

comment:4 Changed 15 years ago by simonwalls@…

Well I have measured the power savings and they are worthwhile for me, I run a low-power mythtv backend and file server (24/7/100%) and am a reader of silentpcreview.com. We can be a bit obsessive about these things....

I have 2 Nova-T PCI cards, one was always in active scan. Idle power consumed by the server reduced to 84Watts from 95Watts at the wall socket, during the active scan's 'rest' period, using the improved patch I attach today. That's about 8kWh or £1.00 saved per month, at current UK electricty prices. It corresponds to about 8.5 Watts before PSU inefficiencies. If both cards had been in active scan, I think the saving would be greater.

To make it work, I added some new lines to the patch to close the card(s) when not in use, and I have set "Open DVB card on demand" for both cards in mythtv-setup. I now do a database query just like the one in eitscanner.cpp to find the number of dvb multiplexes, it avoids increasing the scope of the existing variable(s).

I have revised the patch to scan on a one-hour cycle, and for 2 minutes per multiplex. Duty cycle is thus 12 minutes is 60 for my 6-mux reception conditions in the UK. To use this time setting, you must adjust (in mythtv-setup, General, "EIT Transport Timeout" a.k.a max_seconds_per_source) which controls the time per mux in the Active scan. This is 5 minutes by default, which means you would not cover all your muxes, but I have adjusted mine to 1 minute so each mux is 'seen' twice in the active eit period.

Since you can see hundreds of EIT events in a few seconds, I believe this could work well. I will test the 2 mins per mux / 1 hour cycle to see how well the EPG is kept filled for 1 week. The power saving will only be for 4/5ths of the time, of course.

This document looks like it has some useful information related to EIT delivery rate: http://www.bci.eu.com/library/articles/delivery.pdf

Shortening the cycle time means that schedule changes have a greater chance of being picked up if they occur shortly before a programme. It's okay because tuner cards won't mind being enabled and disabled in short succession, unlike hard disc drives. Still, these timings are only for evaluation, and a week's trial may dictate changing them. Passive scan is still being done.

I'm not posting a log this time as it was captured with a different set of cycle timings, but I'll post a summary log after my test.

This improved patch might be more technically acceptable, but I note your views, janne. Given that my backend is never shut down, I think the power saving is worthwhile.

Changed 15 years ago by simonwalls@…

Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle

comment:5 Changed 15 years ago by anonymous

There is a bug in the 'improved' patch posted, it results in the following: [root@mythserver mythtv]# grep Database /var/log/mythtv/mythbackend.log 2008-10-02 22:32:01.241 TVRec(1): Database query returns 6 DVB multiplexes. 2008-10-02 23:32:01.688 TVRec(1): Database query returns 12 DVB multiplexes. 2008-10-03 00:32:02.079 TVRec(1): Database query returns 18 DVB multiplexes. 2008-10-03 01:32:03.010 TVRec(1): Database query returns 24 DVB multiplexes. 2008-10-03 02:32:03.495 TVRec(1): Database query returns 30 DVB multiplexes. 2008-10-03 03:32:04.068 TVRec(1): Database query returns 36 DVB multiplexes. 2008-10-03 04:44:04.587 TVRec(1): Database query returns 42 DVB multiplexes. 2008-10-03 05:56:05.146 TVRec(1): Database query returns 48 DVB multiplexes. 2008-10-03 07:08:05.723 TVRec(1): Database query returns 54 DVB multiplexes.

This results in increasing on-time, of course. I will update the posted patch when I fix it.

comment:6 Changed 15 years ago by simonwalls@…

I should have let it run longer before posting, it was a simple mistake.

I've posted a new patch, activeeit-improved-031008.diff which I'm now testing for a week.

Changed 15 years ago by simonwalls@…

Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle

Changed 15 years ago by simonwalls@…

Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle

comment:7 Changed 15 years ago by simonwalls@…

activeeit-improved-031008b.diff is the one to use. I found another small bug in the first one, leading to a similar problem to before. Now we have:

2008-10-03 11:20:13.563 TVRec(1): Improved Active Scan Duration 12 minutes 2008-10-03 11:32:13.426 TVRec(1): Reached Active Scan Duration, ceasing active scan until next cycle. Flushing cache... 2008-10-03 12:20:13.963 TVRec(1): Improved Active Scan Duration 12 minutes

comment:8 Changed 15 years ago by simonwalls@…

My test had to end after 3 days run because I had to restart the machine to fiddle with the HDDs. What I saw until the test ended was this:

  • The guide data indication on Mythweb Status stayed at 8 days throughout, indicating that 12 minutes per hour is enough to obtain data for 6 multiplexes in the UK. Yes, if a last-minute reschedule arrives it may be missed, so that could be handled better. This might be by ensuring that the Active Scan time(s) immediately precede a recording, rather than being asynchronous.
  • The EIT transmission rate is very high, so that with a correctly chosen on-time, which looks like it can be <2 minutes per mux, the EPG can be kept full. There isn't an indication of how full it is, at present, as the Mythweb (from Mythbackend) indication is the time of the last entry in the guide. 'Holes in the guide' are not measured at present.
  • The EIT present/following info is transmitted for the tuned mux at least every 2 seconds (according to the PDF link I supplied above). This means that immediately before a recording, a quick now/next check could be made to confirm the intended programme is still about to be transmitted. Using the SDT data for the tuned mux would require at least 10 seconds - still feasible.
  • 12 minutes (precisely) timed using the system clock is not enough time for 2 runs through 6 muxes at 1 minute Active Scan per mux. (Only one and a half runs through the set of 6 muxes were made). In my logs, the time between "Looking for EIT data on multiplex of channel ... " messages is 1 min 23 secs whereas max_seconds_per_source is set to 60s in my mythtv-setup. There are other tasks going on between these messages, like database access etc, and since the EIT process runs at idle priority this may explain this.
  • The second period of scanning, when it occurred for a mux, was some 9 minutes later and resulted in smaller numbers of EIT events (2% to 50%) than the first period.
  • The power saving was worthwhile at 11 Watts AC (~8.4Watts DC after PSU inefficiencies) which was in a machine with 2 Nova-T PCI cards, and one was using Active Scan. If you use mythshutdown, the backend will usually not be on for long enough to make worthwhile savings (and you will want all the guide data you can get to be gathered during an on-time).
  • I noted some 'cx8802_start_dma() Failed' errors in dmesg, which correlated in time with when I started testing patches that closed the DVB card. According to postings on the [linux-dvb] list: "It means the dvb sub-driver hasn't claimed the IRQ, probably because the demux was not opened (which indirectly causes the subdriver to claim ownership). The error is reported because someone asked DMA to start, but no subdriver owns the transport bus."

That's good enough for me. It may mean that the way I closed the DVB channel, CloseChannel?(), is not good or complete enough and something (DMA?) is still set up. So, to confirm that it was the patch, I reverted my patch and recompiled, the cx8802 messages had disappeared (test duration 1 hour run).

I am going to have to leave this for some time, as we are expecting a new baby in the family! I will look into, perhaps, a measurement of 'how full the guide is' so that a future EIT patch could keep scanning until the guide is full, then stop and re-scan when it drops below some limit. And a way is needed for EIT scanning to close the DVB card, without this cx8802 error occurring. I am sure Myth does it properly, if the correct call is used, the one I picked was insufficient in some way.

Thanks for all your comments and perhaps we'll speak again in the future. This ticket could be closed now, so it could be reopened in the future.

comment:9 in reply to:  8 Changed 15 years ago by elkin@…

I have also been testing it in Germany with 50+ DVB-S channels and have not had any problems.

Changed 15 years ago by simonwalls@…

Parts of system messages and mythbackend.log when cx8802 dma messages started just after Active Scan stopped due to patch action

comment:10 Changed 15 years ago by simonwalls@…

elkin,

Good to hear from you, and thank you for testing it. Good news! Please could you confirm if you are seeing any messages in /var/log/messages relating to your capture cards when the Active Scan goes into the wait period?

comment:11 in reply to:  10 Changed 15 years ago by anonymous

I am checking if this patch crashes mythbackend when recording 2+ programs from one transport. can someone please check too?

Changed 15 years ago by simonwalls@…

Gzipped system log of 'stress test', see 09-10-2008 posting

Changed 15 years ago by simonwalls@…

Attachment: more-server-logs.txt added

Snips of backend and system logs showing correlation of cx8802 dma error messages

comment:12 Changed 15 years ago by simonwalls@…

Hi, I still have a short while before our new arrival, so I am running some more tests.

I attach a backend log during a 'stress test' where I record:

2 consecutive programs on the same mux (BBC One and BBC Two).

and shortly after that finished, I record

6 consecutive programs from 2 Nova-T PCI cards.

System load rises to ~7.5 in the second test, and all recordings play back ok (tested by a quick view only). I did not see any backend crash or anything unusual. Thanks for your interest, anonymous :-)

Points of interest noted in my test:

Here, Active scan attempts to restart after a recording has ended, but the tuner is still in use by other recording(s) from that mux:

2008-10-09 19:52:30.680 TVRec(1): EIT Active Scan being (re)started.
2008-10-09 19:52:30.682 EITScanner (1): StartActiveScan called with 6 multiplexes
2008-10-09 19:52:32.192 DVBChan(1:0) Error: SetChannelByString(81): Multiplex is not available
2008-10-09 19:52:32.276 TVRec(1) Error: Failed to set channel to 81. Reverting to kState_None
2008-10-09 19:52:34.088 EITScanner (1): Now looking for EIT data on multiplex of channel 81

This causes an error although it seems to be handled gracefully.

My DVB tuners are set up for 3 recordings each, and the tuner numbers are 1,4,9,10,11,12 (don't ask....). Using a channel/mux map for my tv transmitter, Sutton Coldfiled, I picked channels from Mux2 as follows:

Encoder status
Encoder 1 is local on mythserver and is recording: 'The Wonder Years' on ITV3. This recording will end at 7:50 PM.
Encoder 4 is local on mythserver and is recording: 'My Name Is Earl' on E4. This recording will end at 8:00 PM.
Encoder 9 is local on mythserver and is recording: 'Channel 4 News' on Channel 4. This recording will end at 7:55 PM.
Encoder 10 is local on mythserver and is recording: 'Slim to Win with Rosemary Conley' on ITV1. This recording will end at 8:00 PM.
Encoder 11 is local on mythserver and is recording: 'Hollyoaks' on Channel 4+1. This recording will end at 8:00 PM.
Encoder 12 is local on mythserver and is recording: 'Property Ladder' on More 4. This recording will end at 8:00 PM.

Interestingly the first two recordings came off the first tuner, then tuner 2 was brought into play. I wonder if that's intended or not? (Maybe it's down to my wierd numbering: I have gone back to one stream per tuner and then upped to three, that's how I got it like that).

Full log attached: stress-test-mythbackend.log.gz (52kb)

Another test I have done is to revert my patch, run Myth for two days looking out for cx8802 errors in the /var/log/messages (saw none) and then use the patched version again for the above test.

The cx8802 dma errors re-appeared in /var/log/messages with the patch in place, occurring a few secs after the Active Scan closed the scan down for its rest period. They were not seen when the recordings were in progress (and all recordings checked out ok) so it doesn't affect usage. Still, it would be nice to eliminate those messages and I'm sure finding what is not closed down (dma?) when the DVB channel is closed, will locate the cause.

Snips of mythbackend.log and /var/log/messages attached: more-server-logs.txt

Changed 15 years ago by simonwalls@…

Patch for 0.21-fixes SVN 17451 to make Active EIT scan for 2 mins per mux, on a 1 hour cycle. Does not cause cx8802 errors any more

comment:13 Changed 15 years ago by simonwalls@…

Just attached an updated patch. The cx8802 dma errors seem to have been solved (based on a 1 hour test so far).

The 'solution' was to use some code from TuningShutdowns? which closes the DTVSignalMonitor and/or StreamData?, particularly the former was likely to be running when the channel was closed, causing the dma data flow to still be present and causing the kernel to comment in /var/log/messages. No more messages of that type seen.

This patch is for 0.21-fixes but also applies to Trunk (trunk svn 18954) with only one hunk requiring relocation. Compile-tested only, as I do not have a functional trunk system.

comment:14 Changed 15 years ago by elkin@…

tried the patch on fixes (mythbuntu), but it crashes the backend after a few minutes. I use a budget SkyStar2 DVB-S card.

comment:15 Changed 15 years ago by simonwalls@…

Hi elkin,

That's interesting. When you reported success above (4 weeks ago), were you using activeeit-improved-031008b.diff ?

The reason I ask is that the only change from that time is in the code which closes the card when EIT scan pauses. The same code is executed when a channel change is made, as it's the subroutine TVRec::TuningShutdowns?. Could you post a bit of mythbackend.log when the crash occurs, for reference? Thanks.

comment:16 Changed 15 years ago by elkin@…

you are right, I was still using the old patch. I have to check tonight if the new SWpatch_activeeit-improved_031108.diff does the trick...

comment:17 Changed 15 years ago by simonwalls@…

Just to report this patch has been working continuously in a production system since I last posted. No cx8802 errors, etc, have been noted.

Elkin have you any further information?

I can continue to look at the 'how full the guide is' topic.

Simon.

comment:18 Changed 15 years ago by Dibblah

Status: newassigned

Changed 15 years ago by simonwalls@…

Patch against svn18900 0.21-fixes to further improve. Checks for running recording before closing channel.

Changed 15 years ago by simonwalls@…

Attachment: strictly_notes.txt added

Notes on a recording seeming to be stopped by Active EIT scan (modified) closing the channel

comment:19 Changed 15 years ago by simonwalls@…

Just attached SWpatch_activeeit-improved_081208.diff which contains a check that a recording is not in progress before closing the channel. In lots of weeks of testing I have just got caught out by seemed to be that! Log (strictly_notes.txt) also attached.

comment:20 Changed 15 years ago by simonwalls@…

Log extract of the above patch working (at 08:26:31):

2008-12-09 07:52:02.189 TVRec(1): Changing from None to RecordingOnly
2008-12-09 07:52:02.233 TVRec(1): HW Tuner: 1->1
2008-12-09 08:14:00.088 TVRec(1): Changing from RecordingOnly to None
2008-12-09 08:14:30.251 TVRec(1): Improved Active Scan cycle time 60 minutes
2008-12-09 08:14:30.274 TVRec(1): Improved Active Scan Duration   12 minutes
2008-12-09 08:14:30.275 TVRec(1): EIT Active Scan being (re)started.
2008-12-09 08:17:29.485 TVRec(1): ASK_RECORDING 1 29 0 0
2008-12-09 08:17:29.788 TVRec(10): ASK_RECORDING 10 29 0 0
2008-12-09 08:17:29.975 TVRec(9): ASK_RECORDING 9 29 0 0
2008-12-09 08:18:01.591 TVRec(1): Stopping EIT Active Scan due to tuning.
2008-12-09 08:18:02.203 TVRec(1): Changing from None to RecordingOnly
2008-12-09 08:18:02.208 TVRec(1): HW Tuner: 1->1
2008-12-09 08:26:30.822 TVRec(1): Reached Active Scan Duration, ceasing active scan until next cycle. Flushing cache...
2008-12-09 08:26:31.259 TVRec(1): For Reference - Signal Monitor not running.
2008-12-09 08:26:31.262 TVRec(1): For Reference - Recording was running. Not closed channel.
2008-12-09 08:26:31.264 TVRec(1): Calculated Active Scan wait time of 48 minutes. Active Scan will resume then.
2008-12-09 08:47:00.854 TVRec(1): Changing from RecordingOnly to None
2008-12-09 08:47:31.816 TVRec(1): Improved Active Scan cycle time 60 minutes
2008-12-09 08:47:31.853 TVRec(1): Improved Active Scan Duration   12 minutes
2008-12-09 08:47:31.854 TVRec(1): EIT Active Scan being (re)started.
2008-12-09 08:59:30.898 TVRec(1): Reached Active Scan Duration, ceasing active scan until next cycle. Flushing cache...
2008-12-09 08:59:31.186 TVRec(1): Stopping Signal Monitor...
2008-12-09 08:59:31.566 TVRec(1): Calculated Active Scan wait time of 48 minutes. Active Scan will resume then.

comment:21 Changed 15 years ago by simonwalls@…

I have noticed that the patch SWpatch_activeeit-improved_081208.diff causes periodic crashes of mythbackend. I have caught 2 examples in the last day. I run mythmon which detects the stoppage and restarts mythbackend, but this is still unacceptable. The backend log files around the time are:

2009-01-08 04:43:04.569 EITHelper: Added 1 events
2009-01-08 04:43:05.420 EITHelper: Added 1 events
2009-01-08 04:43:06.275 EITHelper: Added 1 events
2009-01-08 04:43:37.935 EITHelper: Added 1 events
2009-01-08 04:43:54.797 EITHelper: Added 1 events
2009-01-08 04:44:31.663 EITScanner (1): Added 5 EIT Events
2009-01-08 04:44:31.689 EITScanner: Rate limiting reschedules..
2009-01-08 04:44:31.769 EITCache: Wrote 1 modified entries of 121 for channel 10
20 to database.
2009-01-08 04:44:31.901 EITCache: Wrote 2 modified entries of 189 for channel 10
81 to database.
2009-01-08 04:44:32.001 EITCache: Wrote 2 modified entries of 55 for channel 171
2 to database.
2009-01-08 04:44:33.285 TVRec(1): Reached Active Scan Duration, ceasing active s
can until next cycle. Flushing cache...
2009-01-08 04:44:33.771 TVRec(1): Stopping Signal Monitor...
2009-01-08 04:44:34.172 TVRec(1): Calculated Active Scan wait time of 48 minutes
. Active Scan will resume then.
2009-01-08 04:44:34.198 EITScanner (1): Now looking for EIT data on multiplex of
 channel 30
2009-01-08 04:44:34.201 EITCache: Pruning all entries that ended before UTC 2009
-01-07T04:46:02
2009-01-08 04:44:34.640 EITCache: Deleting old cache entries from the database
2009-01-08 04:45:02.68 mythmon: mythbackend not running!
2009-01-08 04:45:06.842 Using runtime prefix = /usr
2009-01-08 04:45:06.886 Empty LocalHostName.
2009-01-08 04:45:06.894 Using localhost value of mythserver
2009-01-08 04:45:07.051 New DB connection, total: 1
2009-01-08 04:45:07.100 Connected to database 'mythconverg' at host: localhost
2009-01-08 04:45:07.103 Closing DB connection named 'DBManager0'
2009-01-08 04:45:07.106 Connected to database 'mythconverg' at host: localhost
2009-01-08 04:45:07.110 New DB connection, total: 2
2009-01-08 12:55:29.765 EITScanner (1): Now looking for EIT data on multiplex of
 channel 30
2009-01-08 12:55:29.796 EITCache: Pruning all entries that ended before UTC 2009
-01-07T12:56:39
2009-01-08 12:55:29.950 EITCache: Deleting old cache entries from the database
2009-01-08 12:56:41.034 EITScanner (1): Now looking for EIT data on multiplex of channel 18
2009-01-08 12:56:41.070 EITCache: Pruning all entries that ended before UTC 2009-01-07T12:57:51
2009-01-08 12:56:41.370 EITCache: Deleting old cache entries from the database
2009-01-08 12:57:52.396 EITScanner (1): Now looking for EIT data on multiplex of channel 1
2009-01-08 12:57:52.428 EITCache: Pruning all entries that ended before UTC 2009-01-07T12:59:02
2009-01-08 12:57:52.624 EITCache: Deleting old cache entries from the database
2009-01-08 12:57:59.399 TVRec(1): Reached Active Scan Duration, ceasing active scan until next cycle. Flushing cache...
2009-01-08 12:57:59.656 TVRec(1): Stopping Signal Monitor...
2009-01-08 12:57:59.705 TVRec(1): Calculated Active Scan wait time of 48 minutes. Active Scan will resume then.
2009-01-08 13:00:01.949 mythmon: mythbackend not running!
2009-01-08 13:00:08.930 Using runtime prefix = /usr
2009-01-08 13:00:09.149 Empty LocalHostName.
2009-01-08 13:00:09.152 Using localhost value of mythserver
2009-01-08 13:00:09.370 New DB connection, total: 1
2009-01-08 13:00:09.484 Connected to database 'mythconverg' at host: localhost
2009-01-08 13:00:09.487 Closing DB connection named 'DBManager0'
2009-01-08 13:00:09.489 Connected to database 'mythconverg' at host: localhost
2009-01-08 13:00:09.533 New DB connection, total: 2
2009-01-08 13:00:09.564 Connected to database 'mythconverg' at host: localhost
2009-01-08 13:00:09.568 Current Schema Version: 1214
Starting up as the master server.
2009-01-08 13:00:09.620 New DB connection, total: 3

I suspected something was not quite right in December, so I ran without the patch included over the critical 'holiday recordings' period and experienced no crashes. There are no other patches compiled-in at the same time, so it's pretty clear what is responsible. I will have a deeper look into it as soon as I can.

Simon.

comment:22 Changed 15 years ago by stuartm

Milestone: 0.22unknown

comment:23 Changed 14 years ago by stuartm

Component: eitMythTV - EIT

comment:24 Changed 14 years ago by simonwalls@…

Original submitter here again. I have migrated to 0.22 since November 2009, which includes the very useful changeset 20084 from cpinkham (Slave backends can shut down when not in use, and be woken by master for recordings).

I've re-arranged my system hardware for 0.22, and now have an always-on Master BE (low-power EPIA M10000) which holds all storage drives, and a Slave BE (Athlon, my old MBE) which has 2xDVB tuner cards. This wakes up and sleeps as needed to make recordings and also handles commflagging etc.

So my original driver to do this work, power saving, has been bettered by this method - power consumption is less than 50% of what it was, and I still keep a server on 100% of the time for other tasks. I get enough EIT data from the hour or so per day that the Slave is awake to keep my UK 7-day EPG full at all times. (If I didn't get a full EPG, then perhaps the way to approach that would be to force some on-time of the Slave BE periodically).

It's a shame I didn't get to find the problems with my patch, but a better solution has been found. It was pleasing to find that a Nova-T card drew around 10Watts and that a saving could be made. The patch was working its best before I added the detection of a recording in progress before closing the channel - perhaps something was wrong in that.

If someone else wants to take this up, please do (I can't spend any more time on it). There are one or two things about [20084] that could be bettered, I should really debug those.

All the best, Simon.

comment:25 Changed 14 years ago by sphery

Resolution: wontfix
Status: assignedclosed

Simon, thanks for the patch. Since you're no longer interested in this and have adopted the preferred approach for power savings (powering down systems when not in use), I'm closing this as wontfix. Note, though, that last I heard, Janne has some changes planned that will give the same type of benefits this patch aims to provide but with a slightly different implementation (that doesn't require the settings and that should "just work" for everyone).

Note: See TracTickets for help on using tickets.