Hi Phil,
The log does show that you have used country code "gb" with scanning. This is good. This value determines the frequency range that is scanned and it also determines if only the specified frequency is scanned or that it also tries to scan with offsets of +167kHz and -167kHz. The UK uses offsets, as found for two frequencies, but e.g. the Netherlands does not. When, for a given channel, there is a lock then mythtv-setup is done with that channel. Only if there is no lock then the frequency with the plus offset is used and if that also does not lock then the frequency with the minus offset is tried. What now happens is that for channels with an offset the HDHomeRun already locks on the frequency without the offset. This happens for both the 530MHz and the 546MHz. The only difference is that for the two channels with a frequency offset the HDHomeRun locks in about 500ms; for the five channels without a frequency offset the lock takes about 300ms.
In principle, I could change mythtv-setup so that it also tries the offset frequencies and then determine which frequency is best, e.g. on locking time or on signal strength. Another way is to use the frequency value in the TerrestrialDeliverySystemDescriptor and that is present for the DVB-T channels but not for the DVB-T2 channel. This is not in the DVB standards or so, there is considerable freedom in composing a TV signal and this is apparently just how Crystal Palace does it. I have to think about this for a while.
Anyway, I understand that using the exact frequency, so including the offset, does not solve the problem.
About testing with the "swamp". I made 400 recordings, two sets of four TV channels, each on a different multiplex, on the DVB-C HDHomeRun.
The four recordings start at the same time, they last 5 minutes and then a pause of 1 minute until the next set of recordings start.
And.. all recordings are good. So the hypothesis that there is something going wrong because four recordings start at the same time is not supported by this.
About the recording times.
When I specify a recording of 1 minute then I get a recording, according to the mythtv-setup GUI, that starts 2 minutes early and stops 2 minutes late. Which gives indeed a total of 5 minutes.
I use the following set of timings:
Code: Select all
my $stagger=0; #gap between start of recordings within a batch (in seconds)
my $preroll=0; #in mins
my $postroll=4; #in mins
my $reclength=1; #length of recording in mins
my $gap=1; #gap after postroll before next preroll in minutes
This then gives recordings of 5 minutes with a pause of 1 minute between recordings.
Why the two minutes early start and two minutes late stop are added I do not know but this is something that is relatively easy to find. To be investigated at some point but parked for now.
Additional recording time extensions can be specified globally, to be applied to all recordings when possible. This is usually referred to as preroll and postroll. It is configured with mythfrontend, page Setup / Video / General / General (Advanced) and then the settings "Time to Record Before Start of Show (secs)" and "Time to Record Past End of Show (secs)". It might be a good idea to check these values; I have set the values to 0 before doing the swamp tests.
About video sources and channel selection in "swamp".
On my desktop test system I have 8 video sources with in total 1800 channels and this makes it a bit cumbersome to get the channels to test.
It would be helpful if the "--listchannels" option also has a "--videosource" option so that only the channels of that video source are shown.
The swamp tests do uncover another bug in MythTV, this time in the frontend in the "Upcoming Recordings" page. This page can easily show 8 recordings being in progress while the "Watch Recordings" screen just shows four (which is the correct number of course).
I also found that mythfrontend can crash in the "Upcoming Recordings" page when there are that many recordings scheduled and when scrolling up and down. Crashes should never happen so this is something that needs to be fixed.
One thing that has not yet been tested is the fix in the tuning code that is now in master. This is the code that generates "t8dvbt:530000000" tuning commands instead of "auto:530000000" and there is a minor chance that might make a difference.
You can try this by installing master from the mythbuntu ppa or so I understand.
Altogether we do now have the "swamp" stress testing utility, small fixes in MythTV and a few more things to fix.
Unfortunately I do not have the feeling that we are getting closer to solving the tuning problem.....
Klaas.