from:"Olliver Schinagl"

Re: [PATCH] dtv-scan-tables - dvb-s - add the config file for Eutelsat 5 West A - 5.0W - C Band

2017-05-30 Thread Olliver Schinagl

Hey Lenny,

On 01/11/17 14:54, l...@netcourrier.com wrote:
> Hello,
>
> There is no config scan file for Eutelsat 5 West A - 5.0W - C Band 
> transponders at https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-s/
> Attached is a config scan file for  Eutelsat 5 West A - 5.0W - C Band 
> transponders in dvbv5 format.
> Could you please ensure that this new patch is committed into the DVB source 
> code tree repositery ?
>
> Thank you
>
> Best regards
>
>
>
Is this the same satellite as in your previous patch? Should it not
simply have been a git mv? If you can do those 2 patches in one
patch-series/pull request that'd be great.

Olliver

Re: [PATCH] dtv-scan-tables - dvb-t - add file for France Paris Eiffel Tower DVB-T transmitters

2017-05-30 Thread Olliver Schinagl

Hey Lenny,

On 01/11/17 14:51, l...@netcourrier.com wrote:
> Hello,
>
> There is no file for Paris Eiffel Tower DVB-T transmitters at 
> https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-t/ .
> Attached is a config scan file for Paris Eiffel Tower transmitters in dvbv5 
> format.
> Could you please ensure that this new file is committed into the DVB source 
> code tree repositery ?

Sorry for the long delay. I did some fixes and it has been pushed now.
>
> Thank you
>
> Best regards
>
>

Re: [PATCH dtv-scan-tables] Rename pl-Krosno_Sucha_Gora with only ASCII characters

2016-11-18 Thread Olliver Schinagl


Hey Thomas,

On 14-11-16 22:05, Thomas Petazzoni wrote:

The pl-Krosno_Sucha_Gora file, added in commit
4cb113fd15e562f0629000fcad9f41405595198d, is the only file that
contains non-ASCII characters in the tree. This causes a number of
build issues with other packages that don't necessarily handle very
well non-ASCII file name encodings.

Since no other file in the tree contain non-ASCII characters in their
name, this commit renames pl-Krosno_Sucha_Gora similarly.

Examples of files that are named with only ASCII characters even if
the city name really contains non-ASCII characters:

   - pl-Wroclaw should be written pl-Wrocław
   - se-Laxsjo should be written se-Laxsjö
   - de-Dusseldorf should be written de-Düsseldorf
   - vn-Thaibinh should be written vn-Thái_Bình

Since there is no real standardization on the encoding of file names,
we'd better be safe and use only ASCII characters.

Signed-off-by: Thomas Petazzoni 
---
  "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora | 0
  1 file changed, 0 insertions(+), 0 deletions(-)
  rename "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora 
(100%)

diff --git "a/dvb-t/pl-Krosno_Sucha_G\303\263ra" b/dvb-t/pl-Krosno_Sucha_Gora
similarity index 100%
rename from "dvb-t/pl-Krosno_Sucha_G\303\263ra"
rename to dvb-t/pl-Krosno_Sucha_Gora


I agree for consistency sake and ease of use, to use plain ascii for 
pl-Krosno_Sucha_Gora as well. If someone feels that we should follow 
proper spelling using UTF-8, someone should fix up and correct all names 
in 1 rename patch.


Also there are various downstream users, which may simply not support 
UTF-8. So by using ascii we also reduce the risk of trouble there.



Thank you for the patch and it has been merged.


Olliver

--
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: [PATCH 0/3] Update Brazilian channel tables

2015-12-04 Thread Olliver Schinagl


Hey Mauro,

On 03-12-15 22:27, Mauro Carvalho Chehab wrote:

(re-sent as vger didn't recognize the original post)

Em Thu, 03 Dec 2015 14:56:52 +0100
Olliver Schinagl  escreveu:


Hey Mauro,

On 03-12-15 14:55, Mauro Carvalho Chehab wrote:

Em Mon, 6 Jul 2015 21:28:10 +0200
Olliver Schinagl  escreveu:


I tried to manually fix things, by changing the charset to utf-8 in the
saved e-mail. That worked but it was only wrong for patch 1/3 and 3/3. I
blindly did assume it was utf-8 so i'm not sure if I got for patch 1:

warning: squelched 70 whitespace errors
warning: 75 lines add whitespace errors.

and about the same for patch 3 the same amount.

So i have the correct data now in my local tree (sans the whtiespace
fixes). Do you want me to push them as is, or do you want to see/fix
things first?

Hi Olliver,

It seems that you're not finding much time lately to apply those
patches, as there are some patches pending for quite some time at
patchwork.

Are there? I admit I do not check patchwork, I'll have to re-learn to
use patchwork. I apply everything I get via e-mail though within a few days.

Applying via email is ok. The big advantage of patchwork is that it
prevents us to forget something.

So, in thesis, all patches sent to the ML should also be at patchwork,
as it stores every valid patch there. The status update of the patch
is manual, though.

Yet, with the patchwork version we've just upgraded, there's a way to
tell patchwork to automatically update a patch when it gets applied
upstream via a hook.

I installed such hook today. Let's see if it will work. If it works, it
should print something like:

remote: I: 1 patch(es) updated to state Accepted.

after the patch got pushed upstream.


If you don't mind, I would like to add myself to it, as this way
I can drop those patches from patchwork, avoiding me to look on
them every time I review the pending patches ;)

No problem, feel free to add them! As an excersize however, should I do
this round of patchwork files?

Can you send me a link to a patch so I can figure it out from there on out?

I'm seeing those two patches:

Patchwork: http://patchwork.linuxtv.org/patch/31537/
Patchwork: http://patchwork.linuxtv.org/patch/32006/

plus this broken one:

Patchwork: http://patchwork.linuxtv.org/patch/31724/
Ok applied them all and fixed the broken one. Took me more then an hour 
and a half to fix and verify it!


Pushing worked, but got the following messages:

Total 12 (delta 7), reused 0 (delta 0)
remote: E: failed to find patch for rev 
78fa84fbfac86aef7921f5381828dea8ab9af053.
remote: E: failed to find patch for rev 
16270d7088c2bae2ffbfc8a73946db58ff4498fd.
remote: E: failed to find patch for rev 
6da0f5e851dd5e51e43b87136228a88705a7ba69.

remote: I: 0 patch(es) updated to state Accepted.

Also under my patchwork account (which I rememberd the log in for!) did 
not find any reference to the patches? Are they supposed to show up 
somewhere where I can easily recognize them (and am I supposed to be 
notified by mail when there are patches there?)


Olliver


Regards,
Mauro



My appologies for not looking at the right place!

Regards,
Mauro


Olliver

On 06-07-15 21:19, Olliver Schinagl wrote:

Hey Mauro,

I still am having issues with your patches. Maybe my workflow is wrong
or my git installation is somehow borked, but i'm getting:

git am \[PATCH\ 1_3\]\ Update\ Brazilian\ ISDB-T\ tables\ -\ Mauro\
Carvalho\ Chehab\ \\ -\ 2015-07-06\ 1509.eml
fatal: cannot convert from true to UTF-8

I download the messages from thunderbird as email's and then run git am
on them. This tends to work from others just fine. My git is from a
pretty recent build, git version 2.3.6. I am one of the crazy people
that does use gentoo for things, but that should be pretty UTF-8 happy..
([ebuild   R] dev-vcs/git-2.3.6::gentoo USE="blksha1 curl gpg iconv
mediawiki nls pcre perl python subversion threads webdav -cgi -cvs -doc
-emacs -gnome-keyring -gtk -highlight (-ppcsha1) {-test} -tk -xinetd"
PYTHON_TARGETS="python2_7" 0 KiB). Then again, it complains about not
being able to convert from 'true', whatever that may be? THe mail header
does list the content type as being true: Content-Type: text/plain;
charset=true. Patch 0/3 however does not even have any content-type. All
very strange this is!

Can you send them as patches or send me a pull-request? (or feel free to
push them yourself ;)

Olliver

On 06-07-15 15:09, Mauro Carvalho Chehab wrote:

The Brazilian channel tables were updated in Oct, 2014.
There were lots of changes since there, as Digital TV is
still under deployment in Brazil.

So, update all tables to reflect the current status.

Mauro Carvalho Chehab (3):
  Update Brazilian ISDB-T tables
  Rename ISDB-T table for Gama city
  Add new cities to Brazilian ISDB-T lists

 isdb-t/br-al-Maceio   |  58 +++
 isdb-t/br-al-Ma

Re: [PATCH 0/3] Update Brazilian channel tables

2015-07-06 Thread Olliver Schinagl

I tried to manually fix things, by changing the charset to utf-8 in the 
saved e-mail. That worked but it was only wrong for patch 1/3 and 3/3. I 
blindly did assume it was utf-8 so i'm not sure if I got for patch 1:


warning: squelched 70 whitespace errors
warning: 75 lines add whitespace errors.

and about the same for patch 3 the same amount.

So i have the correct data now in my local tree (sans the whtiespace 
fixes). Do you want me to push them as is, or do you want to see/fix 
things first?


Olliver

On 06-07-15 21:19, Olliver Schinagl wrote:

Hey Mauro,

I still am having issues with your patches. Maybe my workflow is wrong
or my git installation is somehow borked, but i'm getting:

git am \[PATCH\ 1_3\]\ Update\ Brazilian\ ISDB-T\ tables\ -\ Mauro\
Carvalho\ Chehab\ \\ -\ 2015-07-06\ 1509.eml
fatal: cannot convert from true to UTF-8

I download the messages from thunderbird as email's and then run git am
on them. This tends to work from others just fine. My git is from a
pretty recent build, git version 2.3.6. I am one of the crazy people
that does use gentoo for things, but that should be pretty UTF-8 happy..
([ebuild   R] dev-vcs/git-2.3.6::gentoo USE="blksha1 curl gpg iconv
mediawiki nls pcre perl python subversion threads webdav -cgi -cvs -doc
-emacs -gnome-keyring -gtk -highlight (-ppcsha1) {-test} -tk -xinetd"
PYTHON_TARGETS="python2_7" 0 KiB). Then again, it complains about not
being able to convert from 'true', whatever that may be? THe mail header
does list the content type as being true: Content-Type: text/plain;
charset=true. Patch 0/3 however does not even have any content-type. All
very strange this is!

Can you send them as patches or send me a pull-request? (or feel free to
push them yourself ;)

Olliver

On 06-07-15 15:09, Mauro Carvalho Chehab wrote:

The Brazilian channel tables were updated in Oct, 2014.
There were lots of changes since there, as Digital TV is
still under deployment in Brazil.

So, update all tables to reflect the current status.

Mauro Carvalho Chehab (3):
Update Brazilian ISDB-T tables
Rename ISDB-T table for Gama city
Add new cities to Brazilian ISDB-T lists

   isdb-t/br-al-Maceio   |  58 +++
   isdb-t/br-al-MatrizDeCamaragibe   |  61 
   isdb-t/br-al-PalmeiraDosIndios|  32 
   isdb-t/br-al-Penedo   |  32 
   isdb-t/br-am-BocaDoAcre   |  32 
   isdb-t/br-am-Itacoatiara  |  32 
   isdb-t/br-am-Manaus   |  60 +---
   isdb-t/br-am-Parintins|  29 
   isdb-t/br-ba-Barreiras|  29 
   isdb-t/br-ba-Camacari |  31 +++-
   isdb-t/br-ba-ConceicaoDaFeira |  29 
   isdb-t/br-ba-ConceicaoDoJacuipe   |  87 +++
   isdb-t/br-ba-CruzDasAlmas |  89 ++-
   isdb-t/br-ba-Eunapolis|  29 
   isdb-t/br-ba-FeiraDeSantana   |  29 
   isdb-t/br-ba-Itabuna  |  29 
   isdb-t/br-ba-Juazeiro |  29 
   isdb-t/br-ba-Pojuca   |  60 +++-
   isdb-t/br-ba-Salvador |  31 +++-
   isdb-t/br-ba-SantoAntonioDeJesus  |   2 +-
   isdb-t/br-ba-Seabra   |  32 
   isdb-t/br-ba-VitoriaDaConquista   |  29 
   isdb-t/br-ce-Aquiraz  |  58 +++
   isdb-t/br-ce-Camocim  |  32 
   isdb-t/br-ce-Crateus  |  32 
   isdb-t/br-ce-Fortaleza|  87 +++
   isdb-t/br-ce-Horizonte|  29 
   isdb-t/br-ce-Iguatu   |  32 
   isdb-t/br-ce-Itapipoca|  32 
   isdb-t/br-ce-Massape  |  32 
   isdb-t/br-ce-Pacajus  |  29 
   isdb-t/br-ce-Russas   |  32 
   isdb-t/br-ce-Sobral   |  29 
   isdb-t/br-df-Brasilia |  61 ++--
   isdb-t/br-df-Gama | 177 
++
   isdb-t/br-es-Aracruz  |   4 +-
   isdb-t/br-es-Itapemirim   |  32 
   isdb-t/br-es-JoaoNeiva|  32 
   isdb-t/br-es-Marataizes   |  33 +++-
   isdb-t/br-es-Piuma|  32 
   isdb-t/br-es-VendaNovaDoImigrante |  32 
   isdb-t/br-go-AguasLindasDeGoias   |  31 +---
   isdb-t/br-go-Anapolis

Re: [PATCH 0/3] Update Brazilian channel tables

2015-07-06 Thread Olliver Schinagl


Hey Mauro,

I still am having issues with your patches. Maybe my workflow is wrong 
or my git installation is somehow borked, but i'm getting:


git am \[PATCH\ 1_3\]\ Update\ Brazilian\ ISDB-T\ tables\ -\ Mauro\ 
Carvalho\ Chehab\ \\ -\ 2015-07-06\ 1509.eml

fatal: cannot convert from true to UTF-8

I download the messages from thunderbird as email's and then run git am 
on them. This tends to work from others just fine. My git is from a 
pretty recent build, git version 2.3.6. I am one of the crazy people 
that does use gentoo for things, but that should be pretty UTF-8 happy.. 
([ebuild   R] dev-vcs/git-2.3.6::gentoo USE="blksha1 curl gpg iconv 
mediawiki nls pcre perl python subversion threads webdav -cgi -cvs -doc 
-emacs -gnome-keyring -gtk -highlight (-ppcsha1) {-test} -tk -xinetd" 
PYTHON_TARGETS="python2_7" 0 KiB). Then again, it complains about not 
being able to convert from 'true', whatever that may be? THe mail header 
does list the content type as being true: Content-Type: text/plain; 
charset=true. Patch 0/3 however does not even have any content-type. All 
very strange this is!


Can you send them as patches or send me a pull-request? (or feel free to 
push them yourself ;)


Olliver

On 06-07-15 15:09, Mauro Carvalho Chehab wrote:

The Brazilian channel tables were updated in Oct, 2014.
There were lots of changes since there, as Digital TV is
still under deployment in Brazil.

So, update all tables to reflect the current status.

Mauro Carvalho Chehab (3):
   Update Brazilian ISDB-T tables
   Rename ISDB-T table for Gama city
   Add new cities to Brazilian ISDB-T lists

  isdb-t/br-al-Maceio   |  58 +++
  isdb-t/br-al-MatrizDeCamaragibe   |  61 
  isdb-t/br-al-PalmeiraDosIndios|  32 
  isdb-t/br-al-Penedo   |  32 
  isdb-t/br-am-BocaDoAcre   |  32 
  isdb-t/br-am-Itacoatiara  |  32 
  isdb-t/br-am-Manaus   |  60 +---
  isdb-t/br-am-Parintins|  29 
  isdb-t/br-ba-Barreiras|  29 
  isdb-t/br-ba-Camacari |  31 +++-
  isdb-t/br-ba-ConceicaoDaFeira |  29 
  isdb-t/br-ba-ConceicaoDoJacuipe   |  87 +++
  isdb-t/br-ba-CruzDasAlmas |  89 ++-
  isdb-t/br-ba-Eunapolis|  29 
  isdb-t/br-ba-FeiraDeSantana   |  29 
  isdb-t/br-ba-Itabuna  |  29 
  isdb-t/br-ba-Juazeiro |  29 
  isdb-t/br-ba-Pojuca   |  60 +++-
  isdb-t/br-ba-Salvador |  31 +++-
  isdb-t/br-ba-SantoAntonioDeJesus  |   2 +-
  isdb-t/br-ba-Seabra   |  32 
  isdb-t/br-ba-VitoriaDaConquista   |  29 
  isdb-t/br-ce-Aquiraz  |  58 +++
  isdb-t/br-ce-Camocim  |  32 
  isdb-t/br-ce-Crateus  |  32 
  isdb-t/br-ce-Fortaleza|  87 +++
  isdb-t/br-ce-Horizonte|  29 
  isdb-t/br-ce-Iguatu   |  32 
  isdb-t/br-ce-Itapipoca|  32 
  isdb-t/br-ce-Massape  |  32 
  isdb-t/br-ce-Pacajus  |  29 
  isdb-t/br-ce-Russas   |  32 
  isdb-t/br-ce-Sobral   |  29 
  isdb-t/br-df-Brasilia |  61 ++--
  isdb-t/br-df-Gama | 177 ++
  isdb-t/br-es-Aracruz  |   4 +-
  isdb-t/br-es-Itapemirim   |  32 
  isdb-t/br-es-JoaoNeiva|  32 
  isdb-t/br-es-Marataizes   |  33 +++-
  isdb-t/br-es-Piuma|  32 
  isdb-t/br-es-VendaNovaDoImigrante |  32 
  isdb-t/br-go-AguasLindasDeGoias   |  31 +---
  isdb-t/br-go-Anapolis |  29 
  isdb-t/br-go-AparecidaDeGoiania   |  29 
  isdb-t/br-go-CaldasNovas  |  58 +++
  isdb-t/br-go-Catalao  |  29 
  isdb-t/br-go-Formosa  |  35 +
  isdb-t/br-go-Goianesia|  29 
  isdb-t/br-go-Goiania  |  29 
  isdb-t/br-go-Goiatuba |  29 
  isdb-t/br-go-Itumbiara|  29 
  isdb-t/br-go-Jatai|  58 +++
  isdb-t/br-go-Luziania

Re: [PATCH] dtv-scan-tables: update dvb-t/au-SunshineCoast

2015-03-28 Thread Olliver Schinagl


Thanks guys,

applied and pushed :)

On 03/21/2015 12:40 PM, Jonathan McCrohan wrote:

From: Brian Burch 

Update dvb-t/au-SunshineCoast as per Brian Burch's bug report on Ubuntu
Launchpad:
https://bugs.launchpad.net/ubuntu/+source/dtv-scan-tables/+bug/1415262

Signed-off-by: Jonathan McCrohan 
---
  dvb-t/au-SunshineCoast | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/dvb-t/au-SunshineCoast b/dvb-t/au-SunshineCoast
index 5d22931..ff6f5dd 100644
--- a/dvb-t/au-SunshineCoast
+++ b/dvb-t/au-SunshineCoast
@@ -1,8 +1,8 @@
  # Australia / Sunshine Coast
-# SBS36 SBS ***
+# SBS40 SBS ***
  [CHANNEL]
DELIVERY_SYSTEM = DVBT
-   FREQUENCY = 585625000
+   FREQUENCY = 61350
BANDWIDTH_HZ = 700
CODE_RATE_HP = 2/3
CODE_RATE_LP = NONE
@@ -12,10 +12,10 @@
HIERARCHY = NONE
INVERSION = AUTO
  
-# TNQ47 10 ***

+# TNQ44 10 ***
  [CHANNEL]
DELIVERY_SYSTEM = DVBT
-   FREQUENCY = 662625000
+   FREQUENCY = 64150
BANDWIDTH_HZ = 700
CODE_RATE_HP = 3/4
CODE_RATE_LP = NONE
@@ -25,10 +25,10 @@
HIERARCHY = NONE
INVERSION = AUTO
  
-# ABQ62 ABC ***

+# ABC41 ABC ***
  [CHANNEL]
DELIVERY_SYSTEM = DVBT
-   FREQUENCY = 767625000
+   FREQUENCY = 62050
BANDWIDTH_HZ = 700
CODE_RATE_HP = 3/4
CODE_RATE_LP = NONE
@@ -38,10 +38,10 @@
HIERARCHY = NONE
INVERSION = AUTO
  
-# STQ65 7 ***

+# STQ42 7 ***
  [CHANNEL]
DELIVERY_SYSTEM = DVBT
-   FREQUENCY = 788625000
+   FREQUENCY = 62750
BANDWIDTH_HZ = 700
CODE_RATE_HP = 3/4
CODE_RATE_LP = NONE
@@ -51,10 +51,10 @@
HIERARCHY = NONE
INVERSION = AUTO
  
-# STQ68 WIN ***

+# RTQ43 WIN ***
  [CHANNEL]
DELIVERY_SYSTEM = DVBT
-   FREQUENCY = 80950
+   FREQUENCY = 63450
BANDWIDTH_HZ = 700
CODE_RATE_HP = 3/4
CODE_RATE_LP = NONE


--
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

2015-01-11 Thread Olliver Schinagl


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  
wrote:



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

2015-01-11 Thread 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.


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

Re: [PATCH 00/12] dvbv5 scan tables for Brazil

2014-09-02 Thread Olliver Schinagl

Ah, you sent this to my +list e-mail, I have a backlog there of 10k 
mails due to a new job there now :)


I pulled from your repository, and pushed it upstream.

Thanks!

Olliver


On 08/31/2014 06:57 PM, Mauro Carvalho Chehab wrote:

Ping.

Em Sun, 27 Jul 2014 22:39:25 -0300
Mauro Carvalho Chehab  escreveu:


Hi Olliver,x

Em Thu, 12 Jun 2014 21:59:13 +0200
Olliver Schinagl  escreveu:


Mauro,

Sorry for my late reply!!

I've tried to merge your patches, but besides some blank line errors, I got:

fatal: cannot convert from true to UTF-8

I upgraded to git 2.0.0 and kept getting the error, atleast for 02.

My git-foo is not strong enough to figure out whats going on here, or if
the error is on my end or not. If it is on your end, could you re-send
the patch series with the correct formatting?


Weird... the patches are already in UTF-8. I just re-checked and
applied them without any issue. I didn't even get any blank line errors.

I suspect that something got mangled when you saved the patches from a
file.

I'm enclosing a tarball with all of them. As the patches are using
UTF-8 encoding (due to the name of the Brazilian cities and due to
the channel names that have accents), you need to be sure that you're
using UTF-8 on your distribution.

Here, I'm using:

LANG=pt_BR.UTF-8

On my environment, to be sure that my charset is UTF-8.

Anyway, you can also pull from my git tree directly with:
git pull git://linuxtv.org/mchehab/dtv-scan-tables.git

It will miss your SOB on the patches, though, but you can sign
them either with git rebase or with git filter, with something like:

$ git branch base
$ git pull git://linuxtv.org/mchehab/dtv-scan-tables.git
$ git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: Olliver Schinagl 
"' base..HEAD
$ git branch -d base


Regards,
Mauro


--
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: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found

2014-05-14 Thread Olliver Schinagl


Hey Fred,

On 05/14/2014 06:50 PM, fredbob...@free.fr wrote:

Thank you guys for your support !

Olliver,
thank you for your commit I tested it and the parsing 1) is now good.

However problem 2) is still there : no services are found at the end of the 
scan.

I mean when doing :
scan dtv-scan-tables/dvb-t/fr-All

the end result is :
"ERROR: initial tuning failed
dumping lists (0 services)
Done.
"

Digging further I think the problem is due to FEC, QAM and Guard Interval 
parameters consistency.

Indeed in France it seems there are 2 schemes for DVB-T services depending on where 
you live (I'm not quite 100% sure as I could only find very few official & 
reliable information) :
FEC 3/4, QAM64, Guard Interval 1/8
FEC 2/3, QAM16, Guard Interval 1/32

Whereas in the file we have :
FEC 2/3, QAM64, Guard Interval 1/32
Have you tried wscan? wscan is able to generate a 'initial scanning 
file' which should result in a proper file. See, the thing is, I don't 
know what is right and what is from for the entirety of France, I don't 
have the range nor the lingustic skill to read the dvb-t sites from 
French providers about the proper parameters. We are kind of Dependant 
on people who live in an area to submit the proper scan files.


If you think or know that identical frequencies are used with different 
parameters in different regions, then that is something that needs to be 
explored. If the auto setting works well, we could use that. But try to 
do a wscan and generate an initial scan file from it and see what it 
says, I'd be very curious indeed.


Olliver

However I think this scheme may be OK depending on your HW frontend tolerance. 
Unfortunately it doesn't work with my Hauppauge NOVA-TD-500.

I propose 2 options :
A) rely on the the AUTO capability and use FEC AUTO, QAM AUTO, GI AUTO in the 
frequency file (please refer to attached file fr-All-optionA)
B) double the file with both schemes for each frequency (please refer to 
attached file fr-All-optionB) : the drawback is that the scan is twice longer.

I sucessfully managed to scan services with both A & B. I've attached both 
tests outputs for your reference.
=> But I only have TV channels with the first scheme in my area.

Do you have an opinion about A or B ?

Thank you.

Cheers,
Fred





- Original Message -
From: "Olliver Schinagl" 
Cc: "fredboboss" 
Sent: Monday, May 12, 2014 11:16:18 PM
Subject: Re: Fwd: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file 
: invalid enum and no DVB-T services found

Apologies to all involved, I overlooked this e-mail. I patched it to fix
the casing as suggested in the e-mail and pushed it upstream. Can you
please test it?

Olliver

On 04/29/2014 11:57 PM, Jonathan McCrohan wrote:

Hi Oliver,

Please find Debian bug report from fredboboss regarding
dtv-scan-tables below.

Thanks,
Jon

On Tue, 29 Apr 2014 19:50:57 +0200, fredboboss wrote:

Package: dtv-scan-tables
Version: 0+git20140326.cfc2975-1
Severity: normal
1246b27f8b45f84c1824925060ad931530542f2e
Dear Maintainer,

Dear Debian Maintainer,

when performing a DVB-T frequency scan with the /usr/bin/scan utility (dvb-apps 
package) and the /usr/share/dvb/dvb-t/fr-All frequency file (dtv-scan-tables 
packages) the following 2 problems occur :

1) file parsing error :
ERROR: invalid enum value '8MHZ'
ERROR: invalid enum value '8K'

2) in the end no DVB-T services are found with a Hauppauge NOVA-TD-500 DVB-T 
card.

Those problems seem to come from the /usr/share/dvb/dvb-t/fr-All file.

The following changes are proposed in this file :

For 1) :
- 8MHZ changed by 8MHz
- 8K changed by 8k

For 2) :
- change FEC_HI parameter by AUTO

Thus the 1st frequency line of the file would be changed like that :
-T 47400 8MHZ 2/3 NONE QAM64 8K 1/32 NONE #Channel UHF 21
+T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21

(Please refer to the end of the mail for the complete modified file).

Thanks to those modifications I successfully performed a DVB-T scan with the 
NOVA TD-500 card.

In case more information is needed don't hesitate to contact me.

Best regards,
Fred

-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information

Modified file :
# France ALL (All channel 21 to 60)
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21
T 48200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 22
T 49000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 23
T 49800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 24
T 50600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 25

Re: Fwd: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found

2014-05-12 Thread Olliver Schinagl

Apologies to all involved, I overlooked this e-mail. I patched it to fix 
the casing as suggested in the e-mail and pushed it upstream. Can you 
please test it?


Olliver

On 04/29/2014 11:57 PM, Jonathan McCrohan wrote:

Hi Oliver,

Please find Debian bug report from fredboboss regarding
dtv-scan-tables below.

Thanks,
Jon

On Tue, 29 Apr 2014 19:50:57 +0200, fredboboss wrote:

Package: dtv-scan-tables
Version: 0+git20140326.cfc2975-1
Severity: normal

Dear Maintainer,

Dear Debian Maintainer,

when performing a DVB-T frequency scan with the /usr/bin/scan utility (dvb-apps 
package) and the /usr/share/dvb/dvb-t/fr-All frequency file (dtv-scan-tables 
packages) the following 2 problems occur :

1) file parsing error :
ERROR: invalid enum value '8MHZ'
ERROR: invalid enum value '8K'

2) in the end no DVB-T services are found with a Hauppauge NOVA-TD-500 DVB-T 
card.

Those problems seem to come from the /usr/share/dvb/dvb-t/fr-All file.

The following changes are proposed in this file :

For 1) :
- 8MHZ changed by 8MHz
- 8K changed by 8k

For 2) :
- change FEC_HI parameter by AUTO

Thus the 1st frequency line of the file would be changed like that :
-T 47400 8MHZ 2/3 NONE QAM64 8K 1/32 NONE #Channel UHF 21
+T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21

(Please refer to the end of the mail for the complete modified file).

Thanks to those modifications I successfully performed a DVB-T scan with the 
NOVA TD-500 card.

In case more information is needed don't hesitate to contact me.

Best regards,
Fred

-- System Information:
Debian Release: jessie/sid
   APT prefers testing-updates
   APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information

Modified file :
# France ALL (All channel 21 to 60)
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21
T 48200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 22
T 49000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 23
T 49800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 24
T 50600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 25
T 51400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 26
T 52200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 27
T 53000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 28
T 53800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 29
T 54600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 30
T 55400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 31
T 56200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 32
T 57000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 33
T 57800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 34
T 58600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 35
T 59400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 36
T 60200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 37
T 61000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 38
T 61800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 39
T 62600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 40
T 63400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 41
T 64200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 42
T 65000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 43
T 65800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 44
T 66600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 45
T 67400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 46
T 68200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 47
T 69000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 48
T 69800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 49
T 70600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 50
T 71400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 51
T 72200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 52
T 73000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 53
T 73800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 54
T 74600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 55
T 75400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 56
T 76200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 57
T 77000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 58
T 77800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 59
T 78600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 60


--
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: DTV-Scan-tables tarballs not generated properly

2014-03-24 Thread Olliver Schinagl

On 03/23/2014 03:58 PM, Mauro Carvalho Chehab wrote:

Em Sun, 23 Mar 2014 11:14:13 +0100
Olliver Schinagl escreveu:

Hey Mauro,

Hope everything is well.

People have noticed that the tarballs for the dtv-scan-tables aren't
being generated properly. The 'LATEST' appears to be correct, but there
is only one dated one, no new ones. If you have a few minutes, can you
see what's going on?

Fixed. Basically, the logic that were getting the date were after
the command that was moving to the repository. So, it was returning an
empty date. So, the file was always named as:
dtv-scan-tables-.tar.gz

As dtv-scan-tables-LATEST.tar.gz is actually a link to the produced
file, it was working.

Now, it was properly generated, based on git last commit:
dtv-scan-tables-2014-03-09-177b522.tar.bz2

The name there matches the latest changeset:

http://git.linuxtv.org/dtv-scan-tables.git/commit/177b522e4c815d034cfda5d1a084ad074bc373b6

As usual, the produced files are at:
http://linuxtv.org/downloads/dtv-scan-tables/

Please check it again the day after you add some new commit(s) there,
for us to be sure that everything is working ok. Ah, you should never
rebase the tree, as otherwise the script may fail.
But will 'work' again a commit later? Just wondering how badly it would
break ;)

Secondly, I guess we are way past the year marker, how do you feel the
dtv-scan-tables are handled? I hope it is all satisfactory still?

Yes. I would add a few things on a TODO list:

1) Work with major distros for them to have a package for dtv-scan-tables;
I know that debian and fedora allready package them. So that's a good
thing, I'll see what I can do with regards to other major distro's
(gentoo, arch come to mind)

2) Convert the files to the libdvbv5 format. On libdvbv5 format, all
properties of a DVB channel/transponder are properly represented, as
it uses the same definitions as found at DVBv5 API.

I dunno if you are aware, but the current format is not compatible
with some standards (like ISDB-T). Ok, there are tables there for
ISDB-T, but that relies on the frontend to be able to auto-discover
the properties, because the only thing that it is right there is
the channel frequency.

Even for DVB-T2/S2, there's a new property that is needed to tune
a channel with is not represented with the current format
(DTV_STREAM_ID). Thankfully, afaikt, there aren't many broadcasters
using it.

Of course, in order to preserve backward compat, we should still have
the same format at /usr/share/dvb.

So, my suggestion is to convert the files there to libdvbv5, and
store them at /usr/share/dvbv5. Then, add a Makefile that will
use dvb-format-convert to generate the current contents, and store
them at /usr/share/dvb.

I'll put this on my todo list for this year.

Thanks Mauro!

Olliver

Regards,
Mauro

--
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

DTV-Scan-tables tarballs not generated properly

2014-03-23 Thread Olliver Schinagl


Hey Mauro,

Hope everything is well.

People have noticed that the tarballs for the dtv-scan-tables aren't 
being generated properly. The 'LATEST' appears to be correct, but there 
is only one dated one, no new ones. If you have a few minutes, can you 
see what's going on?


Secondly, I guess we are way past the year marker, how do you feel the 
dtv-scan-tables are handled? I hope it is all satisfactory still?


Olliver
--
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: Updated DVB-T tables - where to send them?

2014-03-23 Thread Olliver Schinagl


On 03/18/2014 10:24 AM, Chris Rankin wrote:

Hi,


Fedora 20 is using a new dvb-scan-tables package:

* Mon Jan 13 2014 Till Maas  - 0-4.20130713gitd913405

Unfortunately, it's still full of files dating from 2012! I will raise a bug in 
their bugzilla for them to ignore completely and then close when Fedora 22 is 
released.
Till e-mailed me not to long ago asking me to fix something in the 
dvb-apps package so he could repackage a bunch of things. So it might be 
available soon.


That said, the downloads section of linux tv only lists 1 ancient 
'named' package, the latest one is up to date.


I'll ping mauro about the packages to get those fixed again, but the 
-LATEST should contain anything that is in the git repo. If there is 
anything still wrong or missing, a patch here, or a Pullrequest even, 
will make it merged quickly :)


Olliver


Cheers,
Chris


On Tuesday, 18 March 2014, 9:07, Simon Liddicott  wrote:


I submitted updates for the whole of the UK in September.
Check Crystal Palace here: 


You will probably find your distro hasn't updated.

I did a pull request into this github repo 


Si.




On 17 March 2014 23:44, Chris Rankin  wrote:




Hi,

The DVB-T initial tuning information for Crystal Palace in the UK is completely 
obsolete - despite my two attempts to submit an updated version over the YEARS. 
Where is the best place to send this information, please?

Thanks,
Chris

--
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


--
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



--
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-apps build failure

2014-03-21 Thread Olliver Schinagl


On 03/11/2014 12:39 AM, Jonathan McCrohan wrote:

Hi Oliver,

On Thu, 06 Feb 2014 09:25:14 +0100, Quentin Glidic wrote:

Hello,

When building dvb-apps from the Mercurial repository, you hit the
following error:
install: cannot stat 'atsc/*': No such file or directory
Can you test it now? I removed the install section from the makefile and 
pushed it upstream. It worked on my outdated virtual machine, so it 
should be good now.


Sorry for the delay, was hoping one of the dvb-apps maintainers would 
pick it up ...


Olliver


In the latest changeset
(http://linuxtv.org/hg/dvb-apps/rev/d40083fff895) scan files were
deleted from the repository but not their install rule.

Could someone please remove the bottom part of util/scan/Makefile (from
line 31,
http://linuxtv.org/hg/dvb-apps/file/d40083fff895/util/scan/Makefile#l31)
to fix this issue?


Ping on Quentin's behalf. I'd like to upload a new version of dvb-apps
to Debian, but the build is currently broken after your recent patch.

Would you be able to take a look?

Thanks,
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: Initial scan table for au-Melbourne-Selby

2014-01-14 Thread Olliver Schinagl


Hi Philip,

On 07-01-14 07:42, Philip Yarra wrote:

Hi, please find attached a scan table for au-Melbourne-Selby. This file
is very similar to the scan table file for au-Melbourne-Upwey (which I
was able to use until quite recently). However the fec_hi value of "2/3"
for SBS no longer works for me, and I need to use "AUTO" instead. I
don't know if this change also affects the Upwey repeater.

Details on the geographic locations of these repeaters can be found here:
Upwey: http://www20.sbs.com.au/transmissions/index.php?pid=2&id=795
Selby: http://www20.sbs.com.au/transmissions/index.php?pid=2&id=792

Note that the Selby repeater actually covers the parts of Upwey which
are not able to get signal from the Upwey repeater, due to hilly
terrain. Although they use identical frequencies, the polarisation is
different.

I think that makes sense to have the two transmitters seperated then.


I assume AUTO allows the DVB tuner to choose one of the FEC types
dynamically, though I don't know if this is supported by all tuners. If
there's a way I can find out which actual fec_hi is in use, please let
me know and I will supply it.

I have provided a brief write-up at
http://pyarra.blogspot.com.au/2014/01/mythtv-and-sbs-in-dandenong-ranges.html
- please let me know if there is further information I can provide.

Next time use git send-mail ;)



Regards,
Philip.

Thanks, I've pushed it now.
Oliver
--
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: [PATCH] [dvb-apps] Remove scan files from dvb-apps repository

2013-12-06 Thread Olliver Schinagl


On 06-12-13 00:22, Jonathan McCrohan wrote:

Hi Oliver,

On 20/10/13 11:45, Oliver Schinagl wrote:

On 10/20/13 12:14, Jonathan McCrohan wrote:

Heh heh. Do you have commit rights for the dvb-apps repository? Would
you be able to get Mauro or someone else to delete those files if you
don't?

Yeah I do, I'll wait a few days to see if the messages show up eventually.


I don't think those messages ever showed up. Would you be able to delete
those files from the dvb-apps repo?


Done as per request.

Oliver


Thanks,
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: [PATCH] dtv-scan-tables - dvb-s - add the config file for Eutelsat 5 West A - 5.0W - C Band

Re: [PATCH] dtv-scan-tables - dvb-t - add file for France Paris Eiffel Tower DVB-T transmitters

Re: [PATCH dtv-scan-tables] Rename pl-Krosno_Sucha_Gora with only ASCII characters

Re: [PATCH 0/3] Update Brazilian channel tables

Re: [PATCH 0/3] Update Brazilian channel tables

Re: [PATCH 0/3] Update Brazilian channel tables

Re: [PATCH] dtv-scan-tables: update dvb-t/au-SunshineCoast

Re: dvb-t scan tables

Re: dvb-t scan tables

Re: [PATCH 00/12] dvbv5 scan tables for Brazil

Re: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found

Re: Fwd: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found

Re: DTV-Scan-tables tarballs not generated properly

DTV-Scan-tables tarballs not generated properly

Re: Updated DVB-T tables - where to send them?

Re: dvb-apps build failure

Re: Initial scan table for au-Melbourne-Selby

Re: [PATCH] [dvb-apps] Remove scan files from dvb-apps repository

18 matches

Site Navigation

Mail list logo

Footer information