Bug 87947

Summary:	Mythtv 0.17 and QT 3.3.4 cause Daylight Savings problem
Product:	Gentoo Linux	Reporter:	Anthony J Moulen <ajmoulen>
Component:	Current packages	Assignee:	Television related Applications in Gentoo's Portage <media-tv>
Status:	RESOLVED FIXED
Severity:	normal	CC:	gentoo, joules, sloan
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	QDate Patch pulled from CVS updates Ebuild using patch for qdate. qdate daylight savings time patch without ~ files

Description Anthony J Moulen 2005-04-04 12:17:30 UTC

When daylight savings shifted the time to daylight time Saturday, MythTV incorrectly reflected the start time of programs shifted by one hour.  This problem was caused by a fix to a bug in QT 3.3.4 which broke a work around in MythTV.  CVS has been patched to correct this bug but 0.17 has not.  

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1 Anthony J Moulen 2005-04-04 12:19:13 UTC

Created attachment 55294 [details, diff]
QDate Patch pulled from CVS updates

This is a patch for mythtv-0.17-r1.ebuild attached next.

Comment 2 Anthony J Moulen 2005-04-04 12:20:03 UTC

Created attachment 55295 [details]
Ebuild using patch for qdate.

Ebuild to use the attached patch.

Comment 3 Jerome 2005-04-04 16:37:19 UTC

Created attachment 55318 [details, diff]
qdate daylight savings time patch without ~ files

Same as patch above, but without the backup files (~) created by the editor.

Comment 4 Anthony J Moulen 2005-04-05 05:48:00 UTC

Someone asked how to use this fix, if you already have a bad set of listings you will have to log into mysql and truncate the program table, then rerun mythfilldatabase after you recompile mythtv.  

For instance:
# /etc/init.d/mythbackend stop
# mysql -u mythtv -p 
mysql> use mythconverg;
mysql> truncate table program;
mysql> commit;
mysql> quit
# /etc/init.d/mythbackend start
# mythfilldatabase

Obviously I am skipping interactive prompts such as password.

Comment 5 Doug Goldstein (RETIRED) gentoo-dev

2005-04-05 11:58:10 UTC

Not gonna happen. There's no clean upgrade path for someone just pushing a new -r1 ebuild out. They're going to have to tinker with MySQL tables etc.

0.18 with the fixes will be out in 3 days.

Plus I don't have a dev box for 2 weeks. Windows bound.

Comment 6 Sloan Poe 2005-04-05 19:27:42 UTC

This is great for those of us willing to tinker.  Thanks.

Comment 7 Jeremy Huddleston (RETIRED) gentoo-dev

2005-04-06 03:09:22 UTC

I added -r1 to portage with this patch but left it in package.mask since cardoe wants to wait for 0.18.  You can unmask it with /etc/portage/package.unmask or just wait for 0.18...

Comment 8 Carsten Lohrke (RETIRED) gentoo-dev

2005-05-06 08:37:50 UTC

*** Bug 91698 has been marked as a duplicate of this bug. ***

Comment 9 Robert Forsman 2005-05-06 11:31:42 UTC

Anyone in a Daylight Savings zone who, today, does an "emerge mythtv" (which will give them 0.16 unless they want to unmask some stuff) will get an application that is NON-FUNCTIONAL.  

Can the ebuilds for 0.16 be adjusted to say "I don't work with QT >=3.3.4" ?  When I first encountered this problem I masked qt-3.3.4-r2, but then a recent update installed qt-3.3.4-r3.

Using PORTDIR_OVERLAY I have determined that altering mythtv-0.16.ebuild to say

  DEPEND=">=media-libs/freetype-2.0
          >=media-sound/lame-3.93.1
!         X? ( >=x11-libs/qt-3.1 <x11-libs/qt-3.3.4 )
          directfb? ( dev-libs/DirectFB >=x11-libs/qt-embedded-3.1 )
...

is sufficient to express mythtv's requirements.

Comment 10 Robert Forsman 2005-05-06 12:02:03 UTC

Never mind.  having a <x11-libs/qt-3.3.4 in the DEPENDS does not solve the problem.  Some other fix is needed.