Known bugs with zapping, don't report them
------------------------------------------
- == Annoying
* == Bug
! == Killer bug
------------------------------------------
 
	- In capture mode window resizing flickers.
	* Wrong aspect when video window opens:
	  bugzilla.gnome.org #108237.
	! bttv 0.9.5 seems to crash the X server whenever
	  XvPutImage is called (field ANY not handled?).
	  Gerd notified, promised fix in 0.9.6.
	* v4l/v4l2 fbuf params must be validated in case
	  setup_fb failed, but were initialized before.
	  Try modifying XF86Config, then restart the X session.
	  (Not a safety/security matter, just wrong bpl/bpp.)
	* resize menu key accel doesn't work?
	* Need to handle BadAtom errors resulting from Xv out
	  of video memory (or no v4l device?). Currently gdk
	  just aborts the app.
	* Need better no-overlay-present handling.
	* Some routine starting --no-xv overlay clamps against
	  info->caps.min when the window is smaller, and
	  seems to forget to clip the overhang.
	* Capture won't work under PPC (endianess)
	* Look for endianness problems.
	* vbi eats too much CPU, investigate.
	~ Zapzilla: Calls fetch_page more often than necessary,
	  investigate.
	* Zapzilla: what's v4lx doing on standard change?
	  Changing the video standard breaks vbi decoding.
	* check on_trigger_clicked
	* Overlay (no XVideo) under E is broken, shading the window
	  isn't correctly detected.
	* Do not assert on ESD timeout
	* Bug in save window geometry, reported by Pawel.
	* Auto-overlays search result pages.
	* config.h is also full of hardcoded paths.
	* Tooltips don't work as expected.
	* Spinslider minimum sizes.
	* Bad reception breaks vbi decoding: i/o error.
	* Channel editor: up/down scroll-to doesn't work right,
	  although this may be a gtk bug. Perhaps related:
	  gtk-app-devel-list digest, Vol 1 #1367,
	  Subject: scrolling windows
	* There's a bug in XF86 4.2.99 and prob. earlier, redirecting
	  controls to tveng1/2.c will fix this. They didn't consider
	  audio.mode changes semantics on read/write in
	  xc/programs/Xserver/hw/xfree86/drivers/v4l/v4l.c:
    } else if (attribute == xvMute ||
	       attribute == xvVolume) {
	ioctl(V4L_FD,VIDIOCGAUDIO,&pPPriv->audio);
	if (attribute == xvMute) {
	    if (value)
		pPPriv->audio.flags |= VIDEO_AUDIO_MUTE;
	    else
		pPPriv->audio.flags &= ~VIDEO_AUDIO_MUTE;
	} else if (attribute == xvVolume) {
	    if (pPPriv->audio.flags & VIDEO_AUDIO_VOLUME)
		pPPriv->audio.volume = xv_to_v4l(value);
	} else {
	    ret = BadValue;
	}
	if (ret != BadValue)
	    if (-1 == ioctl(V4L_FD,VIDIOCSAUDIO,&pPPriv->audio))
		perror("ioctl VIDIOCSAUDIO");
          Another possible bug, the encoding is not reset
	  on open? Though apparently not catched when Zapping
	  opens the v4l/2/5 interface too (try remove the modules
	  in tveng.c).
	* Closing the main window while recording blocks.
	  Backtrace:
	  on_exit2_activate() [now quit_cmd()]
	  UpdateCoords()
	  zmisc_switch_mode(TVENG_NO_CAPTURE, main_info)
	    shuts down capturing before calling
	    plugin_close to stop recording, not good.
	  muted = tveng_get_mute(info)
	  TVLOCK
	  Lock history:
	  <capture thread>
	  TVLOCK   in tveng_mutex_lock 545034 usec
	  TVLOCK   in tveng_read_frame 545069 <--------+ note
	  <main thread>				       |
	  TVLOCK   in tveng_get_mute 559419 <- blocks  |
	  <capture thread>			       |
	  UNTVLOCK in tveng_read_frame 575256 <--------+
	  TVLOCK   in tveng_get_timestamp 575334
	  UNTVLOCK in tveng_get_timestamp 575365
	  UNTVLOCK in tveng_mutex_unlock 575393 <-+ unlocked
	  TVLOCK   in tveng_mutex_lock 575463   <-+
	    lock/unlock does not reschedule when
            another thread waits?
	  TVLOCK   in tveng_read_frame 575498
	  UNTVLOCK in tveng_read_frame 624955
	  TVLOCK   in tveng_get_timestamp 625037
	  UNTVLOCK in tveng_get_timestamp 625068
	  UNTVLOCK in tveng_mutex_unlock 625097
	  TVLOCK   in tveng_mutex_lock 625163
	  TVLOCK   in tveng_read_frame 625197
	   :
