Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#3640 closed defect (duplicate)

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

Reported by: anonymous Owned by: stuarta
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 7 years ago.
dvbsnoop (52.4 KB) - added by anonymous 7 years ago.
dvbsnoop-0x11.bz2 (50.7 KB) - added by anonymous 7 years ago.
dvb_broken_nit_providers1.diff (3.2 KB) - added by janne 7 years ago.
dvbstreamdata.cpp.patch (4.9 KB) - added by klaas.de.waal@… 6 years ago.
scan fixed network id
mythic.pl (1.9 KB) - added by anonymous 6 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 7 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 7 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 follow-ups: Changed 7 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 7 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 7 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 7 years ago by danielk

  • Component changed from mythtv to channelscan
  • Owner changed from ijr to danielk
  • Priority changed from major to minor
  • Severity changed from medium to low

comment:7 Changed 7 years ago by danielk

  • Resolution set to wontfix
  • Status changed from new to closed

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 7 years ago by janne

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 7 years ago by janne

  • Owner changed from danielk to janne
  • Status changed from reopened to new

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

comment:10 Changed 7 years ago by janne

  • Resolution set to invalid
  • Status changed from new to closed

comment:11 follow-up: Changed 7 years ago by erez

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 7 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 7 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 7 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 7 years ago by anonymous

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

comment:16 follow-up: Changed 7 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 7 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 7 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 7 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 follow-up: Changed 7 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 7 years ago by stuarta

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 7 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 7 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 7 years ago by anonymous

comment:24 Changed 7 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 7 years ago by stuarta

  • Cc stuarta added

Changed 7 years ago by anonymous

comment:26 Changed 7 years ago by anonymous

Attached DVBSnoop is:
dvbsnoop -adapter 4 -spiderpid 0

of the multiplex with BBC One Scotland on it.

Changed 7 years ago by anonymous

comment:27 Changed 7 years ago by anonymous

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

Changed 7 years ago by janne

comment:28 Changed 7 years ago by anonymous

Tested this patch, works very well.

comment:29 Changed 6 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 6 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 6 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 6 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 6 years ago by klaas.de.waal@…

scan fixed network id

comment:33 follow-up: Changed 6 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 6 years ago by janne

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 6 years ago by janne

  • Milestone changed from 0.21 to 0.22

Changed 6 years ago by anonymous

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 6 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 follow-up: Changed 6 years ago by anonymous

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

comment:38 Changed 6 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 6 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 6 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 5 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 5 years ago by Dibblah

  • Status changed from new to assigned

comment:44 Changed 5 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 5 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 follow-up: Changed 5 years ago by janne

  • Status changed from assigned to infoneeded

is this resolved after the channelscan merge?

comment:47 in reply to: ↑ 46 Changed 5 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 5 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 5 years ago by danielk

  • Resolution set to fixed
  • Status changed from infoneeded to closed

reported fixed by janne in trunk

comment:50 Changed 5 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 4 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 4 years ago by Dibblah

  • Resolution fixed deleted
  • Status changed from closed to new

This issue does not appear to be fixed in trunk.

comment:53 Changed 4 years ago by robertm

  • Component changed from channelscan to MythTV - Channel Scanner

comment:54 follow-up: Changed 4 years ago by robertm

  • Status changed from new to infoneeded_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 4 years ago by stuarta

  • Status changed from infoneeded_new to new

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 4 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 4 years ago by stuarta

  • Cc stuarta removed
  • Milestone changed from 0.22 to 0.23
  • Owner changed from janne to stuarta
  • Status changed from new to assigned

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 4 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 4 years ago by Dibblah

  • Resolution set to duplicate
  • Status changed from assigned to closed

Duplicate of #7486

comment:60 follow-up: Changed 4 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 4 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.)

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.