dvb-t scan tables
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Olliver Schinagl
AppliedHey Adam,
I've merged your changes, but this last patch seems to go against the old (obsolete) dvbv3 stuff (that gets auto-generated afaik) and fails to apply.
Look at the result on the various repositories and see what needs to be changed.
Best way to send a patch, is to use git to checkout the tree, and then do a git format-patch to send the patch, saves me some work ;)
Olliver
Quoted 31 lines · Adam Laurie
Quoted 4 lines · Jonathan McCrohan
Submitting a bug against dtv-scan-tables to the Debian/Ubuntu bug tracker isn't the worst thing in the world; I maintain the package in Debian and keep it up to date. Ubuntu then syncs the package from Debian. I monitor both bug trackers for bug reports and send any upstream.
Best to send them directly upstream to [email protected] if you can manage it though :-)
Unfortunately the tables in
/usr/share/dvbare even more broken and I have no simple way of testing any patch, but I would suggest they could be auto-generated from the correct one we've just created.As you can see, it's not just the frequencies that are wrong, but FEC and MOD etc:
Quoted 10 lines
$ cat /usr/share/dvb/dvb-t/uk-StocklandHill # UK, Stockland Hill # http://www.ukfree.tv/txdetail.php?a=ST222014 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 514167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB1 T 490167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB2 #T 538167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB3 (DVB-T2) T 505833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM4 T 481833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM5 T 529833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM6For what it's worth, here is the patch, untested. If you're happy with it, I'll certainly send it to [email protected] - your call.
cheers,
Adam
Quoted 8 lines · Olliver Schinagl
Hey Adam,
I've merged your changes, but this last patch seems to go against the old (obsolete) dvbv3 stuff (that gets auto-generated afaik) and fails to apply.
Look at the result on the various repositories and see what needs to be changed.
OK, I'll take a look.
Quoted 4 lines
Best way to send a patch, is to use git to checkout the tree, and then do a git format-patch to send the patch, saves me some work ;)
Is that different from the attached?
I've updated the channel numbers as they are now exact and not +/-
cheers,
Adam
Signature · 6 lines
Adam Laurie Tel: +44 (0) 20 7993 2690 Suite 7 61 Victoria Road Surbiton Surrey mailto:[email protected] KT6 4JX http://rfidiot.org
dvb-t/uk-StocklandHill +6 -6
@@ -6,7 +6,7 @@ # date (yyyy-mm-dd) : 2014-03-25 # #---------------------------------------------------------------------------------------------- -[C26+ BBC A] +[C26 BBC A] DELIVERY_SYSTEM = DVBT FREQUENCY = 514000000 BANDWIDTH_HZ = 8000000
@@ -18,7 +18,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C23+ D3&4] +[C23 D3&4] DELIVERY_SYSTEM = DVBT FREQUENCY = 490000000 BANDWIDTH_HZ = 8000000
@@ -30,7 +30,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C25- SDN] +[C25 SDN] DELIVERY_SYSTEM = DVBT FREQUENCY = 506000000 BANDWIDTH_HZ = 8000000
@@ -42,7 +42,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C22- ARQ A] +[C22 ARQ A] DELIVERY_SYSTEM = DVBT FREQUENCY = 482000000 BANDWIDTH_HZ = 8000000
@@ -54,7 +54,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C28- ARQ B] +[C28 ARQ B] DELIVERY_SYSTEM = DVBT FREQUENCY = 530000000 BANDWIDTH_HZ = 8000000
@@ -66,7 +66,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C29+ BBC B HD] +[C29 BBC B HD] DELIVERY_SYSTEM = DVBT2 FREQUENCY = 538000000 BANDWIDTH_HZ = 8000000
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hey Brian,
Quoted 25 lines · Brian Burch
Quoted 16 lines · Jonathan McCrohan
Hi Olliver/Brian/Adam,
Quoted 13 lines · Olliver Schinagl
<snip>
Quoted 2 lines
Because I am basically an ubuntu user, I took the source from the latest debian unstable repository to generate my patch. I submitted
it
Quoted 2 lines
as an ubuntu "bug" so it would be documented and distributed throughout that particular distribution tree. I felt (perhaps
wrongly)
Quoted 3 lines
that submitting directly to the original developers would a) miss the documentation cascade, and b) might not be committed to the ubuntu repositories as quickly.
While this might be the fastest way to get a seperated patch into ubuntu, ideally we'd like to have it as quickly as possible in the main
Quoted 8 lines
Quoted 6 lines
tree. I'm not sure how quickly or
_ifatall_ubuntu sends their table patches upstream! I would imagine the ubuntu devs keeping the patch until the patch fails, indicating that it has landed upstream ...So while faster in ubuntu, it wlll be slower, or not at all everywhere else :(.
Submitting a bug against dtv-scan-tables to the Debian/Ubuntu bug tracker isn't the worst thing in the world; I maintain the package in Debian and keep it up to date. Ubuntu then syncs the package from Debian. I monitor both bug trackers for bug reports and send any upstream.
Quoted 8 lines
There are a LOT of distros that branch off this particular tree. I use four of them, for example.
In the past I've submitted fixes to the original developers of other packages, but it has taken months or years to get them pulled into the distros that matter to me. It is very frustrating to have a fix accepted but /still/ having to manually patch my own systems to maintain synchronisation with the main repositories.
Yes, that's the reason why we split off the dtv-scan-tables from the dvb-utils repository, as some of those changes where lingering for ages.
Quoted 4 lines
I've been advised by the ubuntu maintenance people that the best way to close the loop is to start at their end. If the report and the patch are credible, they usually push it upstream using the best path quite quickly.
While it's an extra step and takes a bit longer, it certainly works ;)
cc-ing me and the linux-media list with dtv-scan-tables in the subject does both ;)
The big difference with normal code patches, and dvb patches is, we more or less rely on the persons in the area to verify the data, there's only very little that can get 'reviewed' as we don't know if the data is right or wrong.
Quoted 4 lines
I hope to have a change to
au_SunshineCoastquite soon, so I am very pleased to know that Jonathan will be looking after any changes that flow along my chosen path.
cc me + ml and it'll happen faster.
Quoted 5 lines
I don't think there is a "perfect" solution, but ubuntu/debian bugs often turn up high on general searches. If a fix exists, it is much easier to get maintainers of non-debian distros to accept a bug report, easy for them to pull down the source and then quickly release an update.
also true, I like how tv-headend handles this, they pull the latest git periodically I think.
Quoted 3 lines
(Thinks... it is a pity this thread didn't take place on the appropriate mailing list).
CC-ed the list :)
Quoted 2 lines
Best wishes, and thanks for the very useful software!
Technically, it's not software ;)
olliver
Quoted 7 lines
Brian
Quoted 4 lines
Best to send them directly upstream to [email protected] if you can manage it though :-)
Jon