DTV-Scan-tables tarballs not generated properly
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
Em Sun, 23 Mar 2014 11:14:13 +0100
Olliver Schinagl <[email protected]> escreveu:
Quoted 8 lines
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.
Quoted 2 lines
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;
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.
Regards,
Mauro
Quoted 24 lines · Mauro Carvalho Chehab
Em Sun, 23 Mar 2014 11:14:13 +0100
Olliver Schinagl <[email protected]> escreveu:Quoted 8 lines
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.gzAs 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.bz2The name there matches the latest changeset:
Quoted 8 lines
http://git.linuxtv.org/dtv-scan-tables.git/commit/177b522e4c815d034cfda5d1a084ad074bc373b6As 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 ;)
Quoted 7 lines
Quoted 3 lines
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)
Quoted 16 lines
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.
Quoted 7 lines
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 aMakefilethat 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
Quoted 4 lines
Regards,
Mauro
Em Mon, 24 Mar 2014 10:21:46 +0100
Olliver Schinagl <[email protected]> escreveu:
Quoted 27 lines · Mauro Carvalho Chehab
Quoted 26 lines
Em Sun, 23 Mar 2014 11:14:13 +0100
Olliver Schinagl <[email protected]> escreveu:Quoted 8 lines
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.gzAs 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.bz2The name there matches the latest changeset:
http://git.linuxtv.org/dtv-scan-tables.git/commit/177b522e4c815d034cfda5d1a084ad074bc373b6
Quoted 8 lines
Quoted 6 lines
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 ;)
I hope not ;)
The script is simple, but every time it created a file where via a manual call, and not via crontab.
So, it would be good to follow what the script is doing on the next few commits.
Btw, please never rebase. The script is not prepared for git rebases, as it uses git pull to update the history of the temp repository it uses to generate the tarball.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
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.
Yeah, yesterday I requested grant to commit on Fedora. I also generated a new build for Fedora 20 (and next) repo with the latest tarball.
Btw, for those using Fedora, it would be great if you could test it and provide a feedback:
https://admin.fedoraproject.org/updates/dtv-scan-tables-0-5.20140309git177b522.fc20
Positive feedbacks will increase package Karma, and speedup the merge upstream.
Quoted 3 lines
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)
Yeah, adding it at Gentoo would be good.
Quoted 18 lines
Quoted 18 lines
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.
Quoted 6 lines
Quoted 4 lines
So, my suggestion is to convert the files there to libdvbv5, and store them at
/usr/share/dvbv5. Then, add aMakefilethat 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
Quoted 13 lines
Thanks Mauro!
Olliver
Quoted 4 lines
Regards,
Mauro--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Regards, Mauro