Re: DVB-T scan tables for es-Vitoria-Gasteiz, es-All and channels.conf for Vitoria-Gasteiz
The channels file has get into the mail body. [La 1] SERVICE_ID = 560 ... ... ... TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [Radio Vitoria] SERVICE_ID = 1264 AUDIO_PID = 7004 FREQUENCY = 77000 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT 2015-04-30 1:34 GMT+02:00 David Santamaría Rogado howl@gmail.com: Attached the following files: es-All DVB-T scan table contains all the frequencies used in Spain for DVB-T, perhaps it could server as All for every Europe country if someone adds also the DVB-T2 configuration inside this one as I think the spectrum for digital television in all Europe in now the same. Spain only have DVB-T nowadays. es-Vitoria-Gasteiz DVB-T scan table is the third update of my scan file (I didn't submit the second version) with the updated reorganization to leave room for the LTE spectrum and containing some annotations explaining that there are some autonomical channels from es-Burgos and also some illegal emissions tarot, contact and similar scam channels. dvb_channel.conf is the channels-conf dvb-t for Vitoria-Gasteiz in DVBv5 format, in git I see all files in DVBv3 format, if it's needed I could convert it to the old one. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB-T scan tables for es-Vitoria-Gasteiz, es-All and channels.conf for Vitoria-Gasteiz
Attached the following files: es-All DVB-T scan table contains all the frequencies used in Spain for DVB-T, perhaps it could server as All for every Europe country if someone adds also the DVB-T2 configuration inside this one as I think the spectrum for digital television in all Europe in now the same. Spain only have DVB-T nowadays. es-Vitoria-Gasteiz DVB-T scan table is the third update of my scan file (I didn't submit the second version) with the updated reorganization to leave room for the LTE spectrum and containing some annotations explaining that there are some autonomical channels from es-Burgos and also some illegal emissions tarot, contact and similar scam channels. dvb_channel.conf is the channels-conf dvb-t for Vitoria-Gasteiz in DVBv5 format, in git I see all files in DVBv3 format, if it's needed I could convert it to the old one. [La 1] SERVICE_ID = 560 VIDEO_PID = 101 AUDIO_PID = 103 104 105 PID_86 = 8110 PID_06 = 112 111 102 PID_05 = 115 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [La 2] SERVICE_ID = 561 VIDEO_PID = 201 AUDIO_PID = 203 204 205 PID_86 = 8120 PID_06 = 212 211 202 PID_05 = 215 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [24h] SERVICE_ID = 562 VIDEO_PID = 1001 AUDIO_PID = 1003 1004 PID_06 = 1011 1002 PID_05 = 1015 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [Clan] SERVICE_ID = 563 VIDEO_PID = 1501 AUDIO_PID = 1503 1504 1505 PID_06 = 1512 1511 1502 PID_05 = 1515 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [La 1 HD.] SERVICE_ID = 564 VIDEO_PID = 301 AUDIO_PID = 302 303 304 311 PID_05 = 115 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [Radio Nacional] SERVICE_ID = 565 AUDIO_PID = 2001 PID_05 = 2005 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [Radio 5] SERVICE_ID = 566 AUDIO_PID = 2031 PID_05 = 2005 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [Radio Exterior RNE] SERVICE_ID = 567 AUDIO_PID = 2011 PID_05 = 2005 FREQUENCY = 48200 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [7_CYLTV] SERVICE_ID = 1005 VIDEO_PID = 101 AUDIO_PID = 102 103 PID_06 = 8041 104 PID_05 = 310 FREQUENCY = 49800 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [8_La 8 Burgos] SERVICE_ID = 1013 VIDEO_PID = 201 AUDIO_PID = 203 204 PID_06 = 32 PID_05 = 302 FREQUENCY = 49800 MODULATION = QAM/64 BANDWIDTH_HZ = 800 INVERSION = AUTO CODE_RATE_HP = 2/3 CODE_RATE_LP = 1/2 GUARD_INTERVAL = 1/4 TRANSMISSION_MODE = 8K HIERARCHY = NONE DELIVERY_SYSTEM = DVBT [CASTILLA Y LEÓN esRADIO]
Updated DVB-T scan tables for Adelaide region
Greetings, I have attached a couple of updated scan tables for the two Adelaide transmission areas: * au-Adelaide (Australia / Adelaide / Mt Lofty) * au-AdelaideFoothills (Australia / Adelaide / Grenfell Street) A number of channels in the area underwent a final retune in late 2013 as per http://myswitch.digitalready.gov.au. I have used these files successfully with TvHeadend and confirmed the frequencies are correct. Regards, Daniel Merritt. au-Adelaide Description: Binary data au-AdelaideFoothills Description: Binary data
Re: dvb-t scan tables
On 11/01/15 10:26, Olliver Schinagl wrote: 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. 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 -- Adam Laurie Tel: +44 (0) 20 7993 2690 Suite 7 61 Victoria Road Surbiton Surrey mailto:a...@algroup.co.uk KT6 4JX http://rfidiot.org diff --git a/dvb-t/uk-StocklandHill b/dvb-t/uk-StocklandHill index 8b9ad5a..5d2ee81 100644 --- a/dvb-t/uk-StocklandHill +++ b/dvb-t/uk-StocklandHill @@ -6,7 +6,7 @@ # date (-mm-dd): 2014-03-25 # #-- -[C26+ BBC A] +[C26 BBC A] DELIVERY_SYSTEM = DVBT FREQUENCY = 51400 BANDWIDTH_HZ = 800 @@ -18,7 +18,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C23+ D34] +[C23 D34] DELIVERY_SYSTEM = DVBT FREQUENCY = 49000 BANDWIDTH_HZ = 800 @@ -30,7 +30,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C25- SDN] +[C25 SDN] DELIVERY_SYSTEM = DVBT FREQUENCY = 50600 BANDWIDTH_HZ = 800 @@ -42,7 +42,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C22- ARQ A] +[C22 ARQ A] DELIVERY_SYSTEM = DVBT FREQUENCY = 48200 BANDWIDTH_HZ = 800 @@ -54,7 +54,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C28- ARQ B] +[C28 ARQ B] DELIVERY_SYSTEM = DVBT FREQUENCY = 53000 BANDWIDTH_HZ = 800 @@ -66,7 +66,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C29+ BBC B HD] +[C29 BBC B HD] DELIVERY_SYSTEM = DVBT2 FREQUENCY = 53800 BANDWIDTH_HZ = 800
Re: dvb-t scan tables
Hey Brian, On 01/09/2015 12:22 AM, Brian Burch wrote: On 08/01/15 13:16, Jonathan McCrohan wrote: Hi Olliver/Brian/Adam, On 8 January 2015 09:29:10 GMT+00:00, Olliver Schinagl oli...@schinagl.nl wrote: snip Because I am basically an ubuntu user, I took the source from the latest debian unstable repository to generate my patch. I submitted it as an ubuntu bug so it would be documented and distributed throughout that particular distribution tree. I felt (perhaps wrongly) 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 tree. I'm not sure how quickly or _if at all_ 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. 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. 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. I hope to have a change to au_SunshineCoast quite 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. 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. (Thinks... it is a pity this thread didn't take place on the appropriate mailing list). CC-ed the list :) Best wishes, and thanks for the very useful software! Technically, it's not software ;) olliver Brian Best to send them directly upstream to linux-media@vger.kernel.org if you can manage it though :-) Jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-t scan tables
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. 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 On 01/08/2015 03:12 PM, Adam Laurie wrote: On 08/01/15 13:16, Jonathan McCrohan wrote: 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 linux-media@vger.kernel.org if you can manage it though :-) Unfortunately the tables in /usr/share/dvb are 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: $ 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 # COM6 For what it's worth, here is the patch, untested. If you're happy with it, I'll certainly send it to linux-media@vger.kernel.org - your call. cheers, Adam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
