<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<<a href="mailto:anothersname@googlemail.com" target="_blank">anothersname@googlemail.com</a>> wrote:<br>
...<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anything obviously wrong here?<br>
</blockquote>
<br>
Other than I hate wrapped lines, not really.<br>
<br>
But I notice the 753 recording rule (estimated) number. That is a large<br>
number (much larger than I have by 1.5 orders of magnitude). My WAG<br>
is that will that many rules, and the select using bit manipulation for<br>
checks, this is just an intense operation.<br>
<br>
The first thing I would do is review those rules to see if you can<br>
eliminate or simplify your recording rules substantially.<br>
______________________________<u></u>_________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/<u></u>listinfo/mythtv-users</a><br>
</blockquote>
<br>
Sorry about wrapped lines, using gmail web frontend......<br>
<br>
That looks like it's given me a fix.....<br>
<br>
I cleaned up the rules and while doing so came across something that<br>
could be a conflict.<br>
<br>
When I originally built the system as a combined Freeview and Freesat<br>
service the CHANID values get set according to the order that the<br>
source device is chosen.<br>
<br>
In my original build I'd actually scanned the DVB-T channels twice<br>
from two different DVB-T tuners as I didn't realise that the source<br>
could be shared by the other tuners. So then when I scanned the DVB-S<br>
channels there was a 4000 offset for the SID and therefore CHANID, for<br>
example BBC HD which has a SID of 6940 got allocated a CHANID of 10940<br>
to allow for the offset.<br>
<br>
When I did the recent rebuild I didn't make the same error so the SID<br>
and CHANID were instead 8940 rather then the original 10940. This<br>
means the database had recording rules for CHANID values that just<br>
didn't exist in the database anymore.<br>
<br>
I've cleaned the rules down from 750+ to about 150 and will monitor<br>
for a few more days, if I'm right it'll be worth putting this into the<br>
wiki so it doesn't catch out other users later.<br>
<br>
Fingers crossed but good job guys.<br>
<br>
</blockquote>
That raises an important question that wouldn't have bothered us in the old analog days.<br>
<br>
In the digital world, channels are getting moved about on a fairly frequent basis which means we end up rescanning more than we used to. End result: CHANID for any particular channel can get changed from time to time.<br>
<br>
This means that "record on channel xxx" rules are likely not going to work after a scan. I have some of these, and they are a pain to try and figure out which channel they referred to, as they display as "Record on channel ." - that is, the history is gone.<br>
<br>
Is there any chance that in the future these rules won't be tied to CHANID but some other identifier like CALLSIGN, perhaps? (Remembering for those of you in the US that CALLSIGN can be a /lot/ longer than 5-6 characters elsewhere in the world.) Not necessarily CALLSIGN itself, perhaps, but a uniqueid indexed on CALLSIGN.</blockquote>
<div><br></div><div>I could have sworn that the recording rules already used the call sign rather than channel id? I know they used to, because I used to switch from cable to antenna and back again whenever my cable company was running a really good promotional bundle with my internet.</div>
<div><br></div><div>That may have changed?</div></div><br>