Revision as of 12:33, 31 July 2014 by Dekarl (Talk | contribs)
Jump to: navigation, search


Known Issues with Character Encoding

Issues with Time Zones

Memory Leaks??

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 Provides explicit time offsets.
  • _dk_ontv: XMLTV export from
  • _eu_phazer: XMLTV service from 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 done
  • _it_ambrosa: XMLTV export from Explicit about non-commercial use only.
  • _ru_teleguide: XMLTV export from 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).

Proper TV Metadata Schema Bits and Pieces (Hi TVBrainz)

The set of titles (series/season/episode) should be marked as being a true alternate or just a typo/search hint. Some titles are international (used for all languages without localization) titles - showing a poster of the international is better then defaulting to a specific locale.

Personal tools