VdrHardySpec

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

The Debian VDR team has been doing great work keeping up with the vdr-1.5 development series. It has a number of great new features, including DVB subtitle support which previously needed a plugin to work. E-tobi.net has a lot more plugins than Debian, so we'll evaluate what would be nice to have in Ubuntu, and push the changes to Debian if possible.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Use Cases

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

  • We need to decide if 1.5.x is stable enough for hardy. Debian guys are waiting for at least an upstream roadmap until it is ready for unstable.
  • Metapackage which pulls in a useful set of default packages
    • hardware related plugins: (need to test they work without hardware attached)
      • -remote
        • by default this is currently configured with -i autodetect, which may try and steal the keyboard event interface if no other remotes are attached. Remotes are very useful though, so we should find a way to do this.
        -lcdproc, maybe with iMON patch
        • this may be hard to detect in the plugin-finder script, unless it is possible to find out from lcdproc if a display is configured and present
    • software plugins:
      • -dvd -epgsearch -osdteletext -subtitles (DVB-subtitles, needed by at least the Finns) -ttxtsubs? Some channels need this, but rare cases I guess (Discovery*) -adzap? -burn
        • -how to integrate ProjectX? (needs proper java..)
        -maybe text2skin? the default themes are fairly ugly
        • -yes, and maybe decide on a default theme other than the current one
        -channellogos
  • More patches enabled in the main vdr package
    • menu hook
    • liemikuutio?
      • - Simple recordings sorting by Walter@VDRPortal - Alternate rename recordings by Ralf Mueller - Menu selection by Peter Dittmann - Recording length by Tobias Faust
    • subtitles
  • Automate initial channel setup with debconf
    • depend on dvb-utils and use a country and hardware debconf question to run the correct one of tzap/czap/szap with the appropriate starter config files from /usr/share/doc/dvb-utils/examples/scan
  • Ask the user if they want to enable VDR (rather than having
    • /etc/default/vdr default to ENABLED=0 and not produce a user-visible error)

Metapackage

Since we need to be very careful about which plugins we select by default, we may wish to consider a pre-install tool which scans the system hardware and asks some sensible questions to make recommendations about which plugins to install. It could even spawn gnome-app-install or synaptic with the resulting package set.

  • DVB Devices:
    • It appears to be reasonable on Ubuntu to assume that if there are no dvb devices present in /dev/dvb on boot there are none on the system. (USB dvb devices exist, but vdr has no concept of adding/removing DVB devices while it is running, so we don't need to care about that)
    Remote devices:
    • Detecting these could be hard where they are not USB devices. LIRC presumably provides no mechanism to easily detect/dump connected devices. Perhaps looking for configured devices would be more saner, effectively pushing the problem onto LIRC packages. -maybe check out mythbuntu-lirc-generator
    LCD Devices:
    • Detecting these is almost certainly absurdly hard, because they are statically configured in LCDProc

Realistic Goals

  • Enable more patches in vdr package
  • Simple metapackage which pulls in recommended plugins (not hardware ones)
  • Pull in more packages from e-tobi that haven't filtered through debian yet

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.


CategorySpec

VdrHardySpec (last edited 2008-08-06 16:26:54 by localhost)