Opened 17 years ago

Closed 14 years ago

Last modified 14 years ago

#3640 closed defect (duplicate)

mythtv-setup stores incorrect transport frequencies (DVB-C)

Reported by: anonymous Owned by: Stuart Auchterlonie
Priority: minor Milestone: 0.23
Component: MythTV - Channel Scanner Version: head
Severity: low Keywords:
Cc: Ticket locked: no

Description

I've had a hell of a job getting my channels working. I would get partial locks on maybe half of my channels and the log would be full of "Program #n not found in PAT!" messages as has appeared in other tickets...

I've discovered what is happening, but not yet why. It would seem that when the channel scanner associates a channel with a particular transport, that transports frequency is incorrectly stored after a successful scan. Even just rescanning an existing transport can cause the transport frequency to be changed and loose the ability to tune to any existing channels associated with that transport.

I've gone through all my broken channels and corrected the frequency for each transport manually in the database, any attempt to scan for new channels will lose the fix-up.

This occurs in both trunk and 0.20.x. I'm using DVB-C QAM64 with a tt-premium c-2300 card.

Attachments (6)

scan.log.bz2 (43.8 KB) - added by anonymous 17 years ago.
dvbsnoop (52.4 KB) - added by anonymous 17 years ago.
dvbsnoop-0x11.bz2 (50.7 KB) - added by anonymous 17 years ago.
dvb_broken_nit_providers1.diff (3.2 KB) - added by Janne Grunau 17 years ago.
dvbstreamdata.cpp.patch (4.9 KB) - added by klaas.de.waal@… 16 years ago.
scan fixed network id
mythic.pl (1.9 KB) - added by anonymous 16 years ago.
Perl Script to fix all frequency data in channel and dtv_multiplex tables from channels.conf, fills in all columns from channels.conf including symbols per second, and removes all unreferenced multiplexes. To use load channels.conf into mythtv-setup as usual, optionally delete all channels and do a scan on all existing multiplexes, then run this script on the channels.conf.

Download all attachments as: .zip

Change History (67)

comment:1 Changed 17 years ago by anonymous

I've been thinking some more about what's happening here. The transportid comes from the cable company (correct?), but for some reason the mplexid for the channels detected for a given transport is getting set to another transport. Subsequently "fixing" the frequency for the mplexid leaves the the wrong transportid, while this doesn't affect the reception of the channel, the scanner ends up correcting the frequency according to the transport detection.

comment:2 Changed 17 years ago by anonymous

One more thing, I've just performed a scan existing transports and paid careful attention to what has changed. Strangely for the broken channels not only does the transport for the mplexid not have the right frequency, no transport has the right frequency. I suspect the either the transport scan is broken or the transport data from the cable company is broken. I'm going to have a look at the code and see how the transport scanning works.

comment:3 Changed 17 years ago by anonymous

You should probably know, that using a DVB-C card with cable in the UK is illegal

comment:4 in reply to:  3 Changed 17 years ago by anonymous

Replying to anonymous:

You should probably know, that using a DVB-C card with cable in the UK is illegal

hence posting anonymously(!)

comment:5 Changed 17 years ago by anonymous

For what it's worth, I am a customer and I'm only using it for the FTA channels...

comment:6 Changed 17 years ago by danielk

Component: mythtvchannelscan
Owner: changed from Isaac Richards to danielk
Priority: majorminor
Severity: mediumlow

comment:7 Changed 17 years ago by danielk

Resolution: wontfix
Status: newclosed

I highly doubt the queen holds some list of approved television set models, but I'm not going to help someone break the laws of their own country if these laws actually exist.

comment:8 Changed 17 years ago by Janne Grunau

Resolution: wontfix
Status: closedreopened

It's either bogus SI or a bug in the scanner.

If it's a bug it might affect in different countries and should be fixed. Hence I reopen this ticket.

comment:9 Changed 17 years ago by Janne Grunau

Owner: changed from danielk to Janne Grunau
Status: reopenednew

please attach the output of mythtv-setup -v channel,siparser,record and reopen the ticket

comment:10 Changed 17 years ago by Janne Grunau

Resolution: invalid
Status: newclosed

comment:11 Changed 17 years ago by erez

Resolution: invalid
Status: closedreopened

same problem with dvb-s

when i scan channels with mythtv-setup, it stores wrong transponder data for some of the transponders. i have noticed: wrong requency, wrong samplerate, wrong polarity.

my hunch is that the information on the transponder is incorrect, and myth saves the data from the tarnsponder, instead of using the physical data (i.e. freq, samprate,polarity) used when scanning the transponder. just a hunch though.

comment:12 in reply to:  11 Changed 17 years ago by anonymous

Replying to erez:

same problem with dvb-s

when i scan channels with mythtv-setup, it stores wrong transponder data for some of the transponders. i have noticed: wrong requency, wrong samplerate, wrong polarity.

my hunch is that the information on the transponder is incorrect, and myth saves the data from the tarnsponder, instead of using the physical data (i.e. freq, samprate,polarity) used when scanning the transponder. just a hunch though.

Removing the check for existing db frequency results in all the mplex values being off by 1. That is the mplex-1 has the correct values. With the comparison in place I think it is getting lucky out on some transports and leaving the correct frequency in place.

comment:13 Changed 17 years ago by anonymous

In channelutil.cpp ChannelUtil::GetMplexID is defined twice. One function returns the mplexid from the channel table, the other from the dtv_multiplex table. Surely they should have different names!?!

comment:14 Changed 17 years ago by anonymous

Sorry, not twice, four times... is there something I'm not understanding about C++ (likely! though there is definitely a problem here somewhere)

comment:15 Changed 17 years ago by anonymous

OK a little reading up on multiple dispatch clears that one up.

comment:16 Changed 17 years ago by anonymous

It's an overloaded function. It's behaviour changes according to the arguments that it is called with.

Calling it with two unsigned ints means that ChannelUtil::GetMplexID(uint sourceid, uint frequency) is used. With a uint and a QString means ChannelUtil::GetMplexID(uint sourceid, const QString &channum)

comment:17 in reply to:  16 Changed 17 years ago by anonymous

Replying to anonymous:

It's an overloaded function. It's behaviour changes according to the arguments that it is called with.

Calling it with two unsigned ints means that ChannelUtil::GetMplexID(uint sourceid, uint frequency) is used. With a uint and a QString means ChannelUtil::GetMplexID(uint sourceid, const QString &channum)

Thanks, I worked that out, my high-level programming language skills are a "work in progress", most of my programming has been in assembly language! (for ARM CPUs mostly) :-D So, it's still very much a mystery where the off-by-one is coming from. I've been reading though the code and I can't see anything obviously wrong, it's not clear to me whether the fault lies with the mplexid in channel or dtv_multiplex...

comment:18 Changed 17 years ago by anonymous

It is possibly relevent that scanning existing transports *always* results in the channels being updated, so the scanner thinks it has *better* information each and every scan.

comment:19 Changed 17 years ago by anonymous

It looks like the off-by-one was a co-incidence. I've been using the scan specific transport mode and checking the database each time. Entering the initial frequency for the first transport works fine. It filled in many of the transports in the dtv_multiplex table, I then scanned on each frequency from that list. It worked for the next transport, but the following one ended up with the channels having the wrong mplexid (or the frequency for that mplexid was wrong, there was an mplexid with the correct frequency). The frequency for the scanned transport had been changed in the database (why?), the scanner still showed the previous frequency on hitting back.

Buttom line seems to be that the scanner is updating the transport frequency for a given multiplex from the correct value to a bogus one. The initial scan fills in the correct values, but a subsequent update breaks it.

comment:20 Changed 17 years ago by anonymous

Problem lies somewhere in the NIT transport scanner. Adding the code below from DVB-T improves things considerably though it still gets a few wrong.

Use the frequency we already have for this mplex as it may be one of the other_frequencies for this mplex uint mux = ChannelUtil::GetMplexID(sourceid, tsid, netid); if (mux > 0) {

QString dummy_mod; QString dummy_sistd; uint dummy_tsid, dummy_netid; ChannelUtil::GetTuningParams?(mux, dummy_mod, freq,

dummy_tsid, dummy_netid, dummy_sistd);

}

I suspect this would help the DVB-S case too. Any reason why it is only currently used for DVB-T?

comment:21 in reply to:  20 Changed 17 years ago by Stuart Auchterlonie

Replying to anonymous:

Problem lies somewhere in the NIT transport scanner. Adding the code below from DVB-T improves things considerably though it still gets a few wrong.

Use the frequency we already have for this mplex

I suspect this would help the DVB-S case too. Any reason why it is only currently used for DVB-T?

Because only DVB-T has other frequency descriptors, they are not used at all on DVB-C/S.

As has been mentioned before, the underlying issue will be due to the broadcaster sending out bogus tables. Numerous issues exist with this and we already have another ticket tracking what needs to be done to improve the scanner's handling of providers who send non compliant stream.

Stuart

comment:22 Changed 17 years ago by anonymous

I can confirm the bug, I have a dvb-s card, after scanning the polarity in the database was wrong (it was v instead of an h)...

manually changing the value fixed the problem (mysql - update DTV_MULTIPLEX set polarity='h' where mplexid='1';

comment:23 in reply to:  3 Changed 17 years ago by anonymous

Replying to anonymous:

You should probably know, that using a DVB-C card with cable in the UK is illegal

Only if you don't pay for the service, as it would be theft of services, if you pay and only pickup FTA over the cables (which is most BBC channels) then you'll only be in breach of T&Cs with Virgin Media for using unapproved hardware on their network. Last I recalled you can't go to jail for breaking T&Cs.

Changed 17 years ago by anonymous

Attachment: scan.log.bz2 added

comment:24 Changed 17 years ago by anonymous

Attached log is --verbose siparser,channel,record of a scan of an affected network. First is a tuned scan, followed by a 'scan all transports'. This is using a physical DVB device - no other software, no patches to SVN trunk.

comment:25 Changed 17 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

Changed 17 years ago by anonymous

Attachment: dvbsnoop added

comment:26 Changed 17 years ago by anonymous

Attached DVBSnoop is: dvbsnoop -adapter 4 -spiderpid 0

of the multiplex with BBC One Scotland on it.

Changed 17 years ago by anonymous

Attachment: dvbsnoop-0x11.bz2 added

comment:27 Changed 17 years ago by anonymous

dvbsnoop-0x11 is: dvbsnoop -adapter 4 0x11 -n 80 80 since this is just after where it loops.

Changed 17 years ago by Janne Grunau

comment:28 Changed 16 years ago by anonymous

Tested this patch, works very well.

comment:29 Changed 16 years ago by marcello

Same problem in Switzerland with Cablecom Network. When I do a channelscan without the patch I get no valid transponder frequencies. Looking on the Cablecom Support Website I saw that they use what they call a Setup ID (which is nothing else than the Network ID) that has to be enter in the STB settings to identify the geographical location. I tried a Dreambox once, which did have no problems to scan for the right transponders. Also w_scan does get the right settings. So there might be two approaches to get around this, have the possibility to pass the Network ID to the scanner or rely on the physical data read from the card instead of the NIT.

comment:30 Changed 16 years ago by Golffies

Same concern in Paris on Noos TV cable network (which belongs to UPS - Numericable), with MythTV 0.20.2 (KnoppMyth? R5F27) and TechnoTrend? DVB-C 1.0 Budget. All transponder frequencies have been shifted up by a few hundred Khz, after being successfully scanned, which make any reception impossible. Should also be noticed that many encrypted channels were wrongly tagged as free-to-air, which they are not; they have to be removed by hand from the channels list.

BTW, seems to me that receiving free-to-air channels from cable TV, even by other means than the official settopboxes, is by no way illegal under French regulation. Please, avoid such disgraceful statements as this is illegal stuff, which are unrelevant on this page dedicated to bug tracking.

comment:31 Changed 16 years ago by daniel.akerud@…

This is relevant for DVB-T also! I just, after reading this ticket, fixed a few "broken" channels by updating dtv_multiplex.frequency. I imported a channels.conf and the frequency was wrong after update. Now my system seems rock solid -- Tuning to a "broken" channel upsets the dvb_usb_dib0700 driver :-D

comment:32 Changed 16 years ago by anonymous

I am having this issue with DVB-S in the lastest trunk as well. I get partial local and backend is filled with "Progarm # not found it PAT". Looks like its tuned to a wrong transport as well. I will try to attach logs.

Changed 16 years ago by klaas.de.waal@…

Attachment: dvbstreamdata.cpp.patch added

scan fixed network id

comment:33 Changed 16 years ago by klaas.de.waal@…

In bug #1866 the DVB-C scanning problem is described as:

Each TS contains several NIT-Others as well as invalid NIT-Actual (NIT-Actual present but effectively not used - Each NIT-Other describes the valid setup for a particular geographical area (and is identified by a different network-id) - the original network-id is the same on all TS. This is the network setup of @home, casema and Multikabel in NL.

This description of the problem is correct for the @home network in the Netherlands where I live. There are a large number of different cable network regions in the Netherlands and they all have different frequencies, but the digital signals are exactly the same everywhere.
The digital signal has a number of different network information tables, one for each region. However, there is no way you can find out the actual network ID for your own region automatically.
This is also true for commercial DVB-C set-top-boxes such as my Samsung box; when you take a subscription for the digital TV service you get a piece of paper with the network ID and the initial frequency, and with this information your DVB-C set-top-box can do a service scan.

I have made a patch for libs/libmythtv/mpeg/dvbstreamdata.cpp in which it searches for a user-defined network ID, in my case hardcoded to 1111. This works OK. The way to get all channels is now:
(1) Do one "full scan" for a single frequency. After this the dtv_multiplex table has all the correct frequencies.
(2) Then do a "scan all transports" and then you have found all services. The attached patch is for version 0.20.2 but I have also tested this with a svn15604 (end of january).
N.B. The network ID stored in dtv_multiplex is still 1000. This does not hurt.

Instead of using a hard-coded network ID a better way is to add an option to MythTV to let the user specify the network ID for DVB-C networks, and store this somewhere in the MySQL database. I think the best place for the user-defined network ID is in the videosource table. I have made some testcode to do just that; I'm currently stuck at what is the best way to get the value of the user-defined network ID from videosource table in the MySQL database into the dvbstreamdata.cpp code. Suggestions are most welcome.

comment:34 in reply to:  33 Changed 16 years ago by Janne Grunau

Replying to klaas.de.waal@gmail.com:

I have made a patch for libs/libmythtv/mpeg/dvbstreamdata.cpp in which it searches for a user-defined network ID, in my case hardcoded to 1111.

I would prefer my approach dvb_broken_nit_providers1.diff since it doesn't include as much code.

N.B. The network ID stored in dtv_multiplex is still 1000. This does not hurt.

That's probably correct since it is not the network id but the original network id which is probably 1000 for your channels.

Instead of using a hard-coded network ID a better way is to add an option to MythTV to let the user specify the network ID for DVB-C networks, and store this somewhere in the MySQL database. I think the best place for the user-defined network ID is in the videosource table.

It belongs to the video source since it a video source dependent fixup. Please try to make sure that the setting is not to easily activated as users with standard conform providers don't need it.

I have made some testcode to do just that; I'm currently stuck at what is the best way to get the value of the user-defined network ID from videosource table in the MySQL database into the dvbstreamdata.cpp code. Suggestions are most welcome.

Function for dvbstreamdata from which scanstreamdata inherits called in the siscan constructor (libs/libmythtv/siscan.cpp). I'm unsure how siscan should know the correct NetworkID. Probably with a sql query in the the constructor (implemented as cardutil function). Adding it as argument to the siscan constructor is equally ugly.

comment:35 Changed 16 years ago by Janne Grunau

Milestone: 0.210.22

Changed 16 years ago by anonymous

Attachment: mythic.pl added

Perl Script to fix all frequency data in channel and dtv_multiplex tables from channels.conf, fills in all columns from channels.conf including symbols per second, and removes all unreferenced multiplexes. To use load channels.conf into mythtv-setup as usual, optionally delete all channels and do a scan on all existing multiplexes, then run this script on the channels.conf.

comment:36 Changed 16 years ago by Loki

The fix of janne work great, only one remark about the severity status: Should this ticket not have a higher severity than "minor"? Cable is in europe one of the most used TV providers, which is at the moment just nog working without recompiling MythTV with above fix of perl script.

"Minor" does not cover the fact that MythTV users in multiple countries can not watch cable TV. Even if they import a channellist, mythTV just does not work on cable at the moment (i've tried that).

comment:37 Changed 16 years ago by anonymous

ACK, this should be rated high, because its a show stopper for europe.

comment:38 Changed 16 years ago by anonymous

After running the mythic.pl script (without patching mythtv) i still get these errors: 2008-06-24 00:34:26.451 DVBChan(1:0) Warning: Your frequency setting (10972000) is out of range. (min/max:47000000/862000000) 2008-06-24 00:34:26.452 DVBChan(1:0) Warning: Symbol Rate setting (27500000) is out of range (min/max:451875/7230000) 2008-06-24 00:34:26.463 DVBChan(1:0) Warning: Unsupported fec_inner parameter. 2008-06-24 00:34:26.471 DVBChan(1:0) Error: Tune(): Setting Frontend tuning parameters failed.

eno: Invalid argument (22)

2008-06-24 00:34:26.479 DVBChan(1:0) Error: SetChannelByString?(2850): Tuning to frequency. 2008-06-24 00:34:26.488 TVRec(1) Error: Failed to set channel to 2850. Reverting to kState_None

comment:39 in reply to:  37 Changed 16 years ago by BertK

Replying to anonymous:

ACK, this should be rated high, because its a show stopper for europe.

In the Netherlands, a merger of cable operaters (called Ziggo) provides DVB-C to the largest part of the country. Because of the problem this part of the Netherlands can't use MythTV with DVB-C.

I'm willing to donate 100$ (70euro), to a developer to get a decent patch into the 0.22 branch and document it. (And 0.21.1 would be nice too)

Klaas de Waal? Janne?

bert -at- koelewijn -dot- bz

comment:41 Changed 15 years ago by co

the fix results in empty files...

0 -rw-r--r-- 1 alex alex 0 2008-10-15 01:58 czap-final.txt

0 -rw-r--r-- 1 alex alex 0 2008-10-15 01:34 czap-scan-n5.txt 0 -rw-r--r-- 1 alex alex 0 2008-10-15 01:34 czap-scan-nP.txt 0 -rw-r--r-- 1 alex alex 0 2008-10-15 01:34 czap-scan-n.txt

comment:42 Changed 15 years ago by glemsom@…

I tried the dvb_broken_nit_providers1.diff patch - but sadly that didn't do it for me.
The dvbstreamdata.cpp.patch did work though[[BR]]

My provider expects its users to know the correct network ID - then then just ignore whatever the actual DVB signal says... Sadly they (YouSee?) do not want to fix it - even though it IS their fault.
I've seen several people in the same situation as me - and in my opinion we need to support the option of forcing a network ID. (Forcing the network ID is actually what my DVB-C box does... The box I got from my provider!)

And regarding the "co:the fix results in empty files..." - I've updated the Channel_tuning_broken_with_DVB-C page with new scripts that should work now.

comment:43 Changed 15 years ago by Dibblah

Status: newassigned

comment:44 Changed 15 years ago by glemsom@…

In my previous post I was wrong about dvb_broken_nit_providers1.diff patch not working correctly!

It was due to another problem - that it did not work for me.
So, I've tried both patches - and they both solve the problem for me!

Currently I'm using the dvb_broken_nit_providers1.diff patch - which seems to work fine (except from not showing the right network name when scanning - but I cannot see a way around that with that patch)

comment:45 Changed 15 years ago by anonymous

Can anyone tell me how to apply the dvb_broken_nit_providers1.diff patch? I am using a mythbuntu installation?

comment:46 Changed 15 years ago by Janne Grunau

Status: assignedinfoneeded

is this resolved after the channelscan merge?

comment:47 in reply to:  46 Changed 15 years ago by Cello

Replying to janne:

is this resolved after the channelscan merge?

I will give it a try and let you know.

comment:48 Changed 15 years ago by Cello

Hi janne

I have installed a fresh trunk version 20489 build on my spare server. The issue seems to be resolved, but I did not add more than one multiplex yet, because of the annoying scan procedure. Since the channels found seem to be conflicting, I had to accept every channel manually. Although all correct values are shown, I had to enter the channelname manually, which by the way was a real pain because the keyboard was useless. Did I miss some option or parameter to avoid that behaviour during the scan? However, the 7 channels on the added multiplex are all usable within mythfrontend and the EPG table starts to get populated.

I guess I will have some more time tomorrow to add some more channels. If you need some log files or need some other information, please let me know. I am very pleased that this issue seems to finally get a fix after nearly two years. Your broken_nit_providers patch did solve the problem for me during the past 18 months, so I guess I owe you at least some support with testing.

comment:49 Changed 15 years ago by danielk

Resolution: fixed
Status: infoneededclosed

reported fixed by janne in trunk

comment:50 Changed 14 years ago by klaas.de.waal@…

I have installed trunk 22288 from scratch, with a new blank database, to test the service scan but the DVB-C service scan issue is not solved. At least not for me here in the Netherlands with the DVB-C signal from provider Ziggo.

The problem is still the same (see my previous post of about 20 months ago) but fortunately the solution is also still the same!

The patch from janne (attachment dvb_broken_nit_providers1.diff) can be applied to trunk and still works OK.

To recap, the complete procedure is:
(a) apply patch from janne,
(b) edit your network id (mine is 1111),
(c) make & install,
(d) do a "Full scan" of an initial frequency (mine is 356MHz) with the correct symbol rate (6875000 for me).

comment:51 Changed 14 years ago by glemsom@…

I just installed mythtv 0.22 (fixes-22920).
This bug is still present - so I guess this ticket needs a reopen.

comment:52 Changed 14 years ago by Dibblah

Resolution: fixed
Status: closednew

This issue does not appear to be fixed in trunk.

comment:53 Changed 14 years ago by robertm

Component: channelscanMythTV - Channel Scanner

comment:54 Changed 14 years ago by robertm

Status: newinfoneeded_new

Glemsom, If you are still seeing this with .22, please provide channel scan logs by invoking mythtv-setup with the following arguments:

mythtv-setup --verbose siparser,channel,record

Thanks.

comment:55 in reply to:  54 Changed 14 years ago by Stuart Auchterlonie

Status: infoneeded_newnew

Replying to robertm:

mythtv-setup --verbose siparser,channel,record

With the new channel scanner that's actually

mythtv-setup --verbose channelscan,siparser,channel,record

comment:56 Changed 14 years ago by glemsom@…

As requested, I tried with the latest 0.22-fixes - and without any additional patches

Here's what I did:

  • Recompile mythtv@0.22-fixes rev. 23473 WITHOUT the dvbstreamdata.cpp.patch stream patch.
  • Start mythtv-setup with: "mythtv-setup --verbose channelscan,siparser,channel,record -O ThemePainter?=qt >> mythtv-channelscan.log"
  • Delete all capture cards and input (to start from a fresh!)
  • Do a full initial scan in freq. 143000000, ksym 6875000, QAM 64
  • Try to do a scan on all existing transports. (I did it twice actually)

My results are the same, without the dvbstreamdata.cpp.patch, I do not get all channels (I only get the channels on the initial transponder at 143Mhz)

Log is uploaded here as I'm unable to attach it: http://glemsom.anapnea.net/mythtv-channelscan.log

comment:57 Changed 14 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie removed
Milestone: 0.220.23
Owner: changed from Janne Grunau to Stuart Auchterlonie
Status: newassigned

This ticket and #7486 both require the same solution. I've put the schema change in for #7486 that allows us to specify the desired netid per datasource.

Need a bit of work in the setup gui to allow the netid on the data source to be specified as auto or manual and then adding the netid.

Then a few bits and pieces from the patches on this ticket to treat the netid from the datasource as the correct one, ignoring all others found in both NITa and NITo

Might be able to get this done for 0.23 hence the milestone setting.

comment:58 Changed 14 years ago by sb@…

Hi,

I am fighting a similar issue here. I get 33 of 38 channels (I can see 38 in all other programs I can dig up on Linux (dvbscan) and Windows).

I have tried the dvbstreamdata.cpp patch. It did not really help (still 33 channels). The perl scripts patches trashed the channel list in the database.

Is there anything I can do to help?

/Soeren

comment:59 Changed 14 years ago by Dibblah

Resolution: duplicate
Status: assignedclosed

Duplicate of #7486

comment:60 Changed 14 years ago by anonymous

How can this be closed marked as a duplicate of a NEWER bug?
It should be the other way around!

comment:61 in reply to:  60 Changed 14 years ago by Nick Morrott <knowledgejunkie (at) gmail (dot) com>

Replying to anonymous:

How can this be closed marked as a duplicate of a NEWER bug?
It should be the other way around!

Because it makes the bug ageing report look better :)

(The real reason is most likely because #7486 has more recent patches and debug output attached, and so is more useful to keep open than #3640.)

Note: See TracTickets for help on using tickets.