#313 Flaw in the Supplement model

none
closed-rejected
nobody
General (10)
5
2014-04-07
2008-01-27
Anonymous
No

I've marked this against tv_grab_uk_rt but in reality it affects all grabbers using the supplement stuff.

Recently the format of channel_ids files were updated for tv_grab_uk_rt breaking all older grabber versions. These grabbers could have continued to work using a cached version of the channel_ids but the new ids file was forced upon them by the supplement module. (Lost recordings, very unhappy family).

I'm proposing that supplement is changed before the release of the next version of xmltv so that supplement files are versioned. It might mean maintainers have a little extra work (maintaining two or more channel_ids etc) but that the chances of breaking older installs is reduced.

Discussion

  • Nobody/Anonymous

    Logged In: NO

    well, I think if the channel-id file changes (or any config file actually), the grabber should be able to deal with the old format, at least for a while.

    If that can't happen, maybe the grabber can detect the new format and use the last known good file.

     
  • Nick Morrott

    Nick Morrott - 2008-01-28

    Logged In: YES
    user_id=1602878
    Originator: NO

    Let me apologise for your lost recordings. Before 0.5.50 was released, I deliberately updated the tv_grab_uk_rt grabber so that it would not fail if extra fields were added to the channel_ids file, which I have since done to support timeshifted and part-time channels. However, at that time I did not add code to gracefully work around duplicated Radio Times IDs, which the new channel support requires.

    When I added support for these two new channel types into the current CVS version of the grabber and updated the supplement version of channel_ids, I did not re-order the list of channels in channel_ids. This caused the 0.5.50 release (the only release to date that uses supplement.xmltv.org) to fail if a requested channel also had a new timeshifted or part-time channel associated with it.

    I have since reordered the channel_ids file so that the current 0.5.50 release should continue to work properly. Records for channels that the grabber does not know how to handle are overwritten with 'good' channel settings during configuration and grabbing, and should continue to allow tv_grab_uk_rt to work exactly as before. There will be some warnings to STDERR about unsupported/duplicated channels/IDs, but this should not stop the grabber from working.

    Setting the XMLTV_SUPPLEMENT environment variable to point to the local installed/source channel_ids file (for example 'export XMLTV_SUPPLEMENT=/usr/src/xmltv/blib/share/') was discussed on the mailing list when these problems were reported. This allows the grabber to handle a bad or missing supplement file, but should not be required since the reordering of the channel entries in channel_ids.

    Please let me know if you are still experiencing problems using the Bug Tracker or xmltv-users list.

     
  • Nick Morrott

    Nick Morrott - 2008-01-28
    • labels: 1003249 -->
     
  • Nick Morrott

    Nick Morrott - 2008-08-26
    • labels: --> General
     
  • Andy Balaam

    Andy Balaam - 2009-02-14

    I agree with the original poster that XMLTV really should deal with the fact that lots of older installations will be in place. I am using xmltv 0.5.51 here, because that is what comes with my distro (Ubuntu 8.04). I've had to install XMLTV from source to make it work again, which is not trivial.

    Many users of my application FreeGuide have had the same problem. A simple solution would simply be to change the URL when the file format changes, and leave the old file on the server so that older grabbers are unaffected.

     
  • Nick Morrott

    Nick Morrott - 2009-02-14

    Andy,

    XMLTV 0.5.51 should be fine, as the changes to channel_ids were made around 0.5.50 (explained earlier in the thread).

    Do not confuse the fact that the Radio Times (listings provider for tv_grab_uk_rt) have made changes to *their* source files (which has broken older versions of the grabber), with changes made within tv_grab_uk_rt that may break pre-0.5.50 XMLTV installations.

    I have not been made aware of any further problems since the issue with adding extra fields to the channel_ids file.

    Please provide details of the problems you are having with your 0.5.51 install and I'll look into it. Versions of XMLTV >= 0.5.52 will handle the changes made by the Radio Times automatically. Does Ubuntu not have any newer releases of XMLTV to install?

    Nick

     
  • Andy Balaam

    Andy Balaam - 2009-02-17

    The error I and some of my users were seeing was definitely in version 0.5.51. The error message was "Bad channel entry seen in RT channels.dat".

    There's a bit more detail in the FreeGuide FAQ: http://www.artificialworlds.net/freeguide/FAQ/BadEntrySeenInRTChannels

    Apologies if I've been blaming xmltv site changes when it was changes to the RT site causing the problem.

    Ubuntu 8.04 is the long-term support version, and is nearly a year old. The official repos only have XMLTV 0.5.51.

    I imagine the newer Ubuntu 8.10 has a newer XMLTV.

     
  • Geoff

    Geoff - 2014-04-06
    • status: open --> closed-rejected
    • Group: --> v1.0 (example)
     
  • Geoff

    Geoff - 2014-04-06

    The OP suggested that supplement files be "versioned" (whatever that means)

    It is up to the grabber author to ensure backward compatability in the supplement files, or, where this is not possible, take appropriate action e.g. maintain separate supplement files. It is already possible to store a 'version number' within a supplement file or to keep separate files (e.g. with different filenames), so no change is required to Supplement.

    w.r.t. tv_grab_uk_rt versions discussed above, this is OT for the title of this bug report - if this is still an issue then please raise a grabber-specific report for it.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks