Difference between revisions of "User:Dekarl"
From XMLTV
m (→Best Practices: collect quotes from the DVB Standards related to the uniquenes of IDs and how to handle multiples copies of the same transport stream) |
m (→Potential Data Sources: _fr_kazer is done) |
||
Line 36: | Line 36: | ||
* _dk_ontv: XMLTV export from [http://ontv.dk/xmltv/ ontv.dk]. | * _dk_ontv: XMLTV export from [http://ontv.dk/xmltv/ ontv.dk]. | ||
* _eu_phazer: XMLTV service from tvprofil.net aka [http://tvprofil.net/xmltv/ Phazer XMLTV Service]. Notice that they provide timestamps in their local time as floating time which is intepreted as UTC... | * _eu_phazer: XMLTV service from tvprofil.net aka [http://tvprofil.net/xmltv/ Phazer XMLTV Service]. Notice that they provide timestamps in their local time as floating time which is intepreted as UTC... | ||
− | * _fr_kazer: XMLTV service from [http://kazer.org/ kazer.org]. | + | * <strike>_fr_kazer: XMLTV service from [http://kazer.org/ kazer.org].</strike> [http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/grab/fr_kazer/ done] |
* _it_ambrosa: XMLTV export from [http://www.ambrosa.net/index.php/contents/XMLTV.html ambrosa.net]. Explicit about non-commercial use only. | * _it_ambrosa: XMLTV export from [http://www.ambrosa.net/index.php/contents/XMLTV.html ambrosa.net]. Explicit about non-commercial use only. | ||
* _ru_teleguide: XMLTV export from [http://www.teleguide.info/article1.html teleguide.info]. Provides explicit time offsets. | * _ru_teleguide: XMLTV export from [http://www.teleguide.info/article1.html teleguide.info]. Provides explicit time offsets. |
Revision as of 11:41, 17 July 2011
Contents
Known Issues with Character Encoding
- Need to verify that we can dump perl strings at XMLTV::Writer and it will do the right thing with regard to escaping anything outside $encoding into XML entities.
- tv_grab_hr tv_grab_no_gfeed tv_grab_se_swedb fix commited upstream
- #1910245 should add a test for HTML entities in the generated XML. (hint ´ is invalid XML!)
Issues with Time Zones
- tv_grab_dk_dr DST issues
- tv_grab_il DST issues
- tv_grab_it DST issues
- tv_grab_pt_meo DST issues
- tv_grab_uk_bleb DST issues, floating start>stop leads to wrong date calculation and time offsets
Memory Leaks??
- #2612996 tv_grab_na_dtv dumps core on windows as .exe, grows quite as perl
Cleanup List
Feel free to take anything from the list
- #1880681 the bug was solved (not a bug), the suggestion for Supplementary Files is turning one can of worms into another...
- tv_grab_huro has no maintainer?
- #2748362 site changes: holes in the collected programs
- #2837668 site changes: unexpected hash references
- #2858285 close it, was "no channels found", the grabber does not fail completely anymore (see status)
- #2910015 close it, was "no programs on channel 1", test_grabbers tests with that channel succesful
Cleanup SourceForge Project
- remove group/status/category examples from the tracker (might check for other unused stuff while there)
Check for Breakage caused by LWP::Simple
- silent uncompression
- silent code page conversion
- silent proxy handling
Maybe it's best to move most uses over to our own Get_nice.
Potential Data Sources
Candidates for wrapping into Static File Grabbers
- _cz_arcao: XMLTV export from arcao.com. Provides explicit time offsets.
- _dk_ontv: XMLTV export from ontv.dk.
- _eu_phazer: XMLTV service from tvprofil.net aka Phazer XMLTV Service. Notice that they provide timestamps in their local time as floating time which is intepreted as UTC...
-
_fr_kazer: XMLTV service from kazer.org.done - _it_ambrosa: XMLTV export from ambrosa.net. Explicit about non-commercial use only.
- _ru_teleguide: XMLTV export from teleguide.info. Provides explicit time offsets.
Configuration API
- [1] possible extensions/clarifications from a consumers POV
- list in the supplementary files mapping DVB/ATSC id to grabber/channel. Then let --list-channels & co. enrich channel list with related ids. MythTV's Browser Based Setup might be a consumer for this to allow automatic mapping of channels in the guide to channels on the video source.
Data Sinks
- Check [2] and see if all are mentioned here
Best Practices
Consumers of XMLTV Data
- be prepared that xmltv ids really might be similar to FQDN (255 characters max.) the longest I've seen in the wild is 69 characters (_es_laguiatv)
Random Pieces of Information
You might receive the same transport stream on multiple frequencies
TS 101 211 - DVB Guidelines on implementation and usage of Service Information (SI)
NOTE 1: The cell_id cannot be used to identify a service. The combination of service_id and original_network_id remains a unique identification of a service.
It is recommended to make all receivable multiplexes with the same transport_stream_id but with different cell_ids available to the user, and only when a service (not a transport stream) is available through multiple multiplexes to select a preferred multiplex based on e.g. reception quality.
Any reference resolution from a transport_stream_id or a service_id (e.g. from a linkage_descriptor transport_stream_id/service_id pair) to a multiplex/frequency requires consideration to handle the potential multiplicity
Note that in networks deploying the service_availability_descriptor, the unique identification of a transport stream by the tuple (transport_stream_id, original_network_id), can often be sensibly replaced by identification through the triplet (transport_stream_id, original_network_id, cell_id).