[mythtv] RE: [mythtv-commits] mythtv commits

2005-06-21 Thread Anduin Withers
 Also if you do not compile
 both the frontend and backend, mythtv-setup will not be compiled.

1 - mythtv.pro uses mythfrontend instead of using_frontend
2 - Also it doesn't depend on settings.pro (where CONFIG gets CCONFIG)
making even a switch to using_frontend no good.

The result is that you don't end up with mythtv-setup being built or
installed.

-- 
Anduin Withers


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:mythtv-commits-
 [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Monday, June 20, 2005 11:45 AM
 To: mythtv-commits@mythtv.org
 Subject: [mythtv-commits] mythtv commits
 
 --
 --
 Changes committed by danielk on Mon Jun 20 15:44:52 2005
 
 Added Files:
in mythtv/libs/libmythtv:
 tv.cpp
 Modified Files:
in mythtv:
 configure mythtv.pro
in mythtv/libs/libmythtv:
 NuppelVideoRecorder.cpp NuppelVideoRecorder.h
 channeleditor.cpp filter.h libmythtv.pro
 scheduledrecording.cpp signalmonitor.cpp tv_play.cpp
 tv_rec.cpp videoout_xv.cpp videoout_xv.h videosource.cpp
in mythtv/programs:
 programs.pro
 Log Message:
 
 You must re-run ./configure (with the same options as normal).
 
 This adds 3 options to ./configure
  --disable-v4l
  --disable-frontend
  --disable-backend
 
 And, of course, the matching --enable options.
 
 If you disable the frontend the backend can not create pixmaps for
 a frontend for priviews, so it should be considered as something
 useful only for porting the backend. Also if you do not compile
 both the frontend and backend, mythtv-setup will not be compiled.
 Disabling Video4Linux should be enough for compiling on MacOS X,
 but on MacOS X the backend is disabled by default.
 
 This touches a bunch of files, but it's mostly just for
 USING_FRONTEND/BACKEND/V4L defines. The exception is that I added
 a tv.cpp, because StateToString() is used by both tv_rec.cpp and
 tv_play.cpp, and I didn't want to duplicate it in tv_rec.cpp and
 tv_play.cpp nor did I want to make it static in tv.h.
 
 The basic aim here is to make it possible for us to test frontend
 only compilation so that Nigel doesn't have to do all the work on
 keeping the MacOS X port working. And the secondary aim (i.e. why
 do we have v4l and backend options) is to facilitate porting the
 backend to MaxOS X.
 
 --
 --

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-06-20 Thread Daniel Kristjansson
On Mon, 2005-06-20 at 15:45 +, [EMAIL PROTECTED] wrote:
 
 Changes committed by danielk on Mon Jun 20 15:44:52 2005


 You must re-run ./configure (with the same options as normal).


I just wanted to draw everyone's attention to this part of the
commit message. You may also wish to do a make distclean.

The commit makes frontend, backend, and v4l support optional. The
aim is to make it easier to maintain and extend the MacOS X port,
see the commit message for details.

-- Daniel


___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-06-17 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:
 --
 --
 Changes committed by danielk on Fri Jun 17 13:03:52 2005
 
 Added Files:
in mythtv/libs/libmythtv/mpeg:
 dvbdescriptors.cpp dvbdescriptors.h mpegdescriptors.cpp
 mpegdescriptors.h scanstreamdata.cpp scanstreamdata.h
Modified Files: in mythtv/libs/libmythtv:
 hdtvrecorder.cpp libmythtv.pro
in mythtv/libs/libmythtv/mpeg:
 atscdescriptors.cpp atscdescriptors.h atscstreamdata.cpp
 atscstreamdata.h atsctables.cpp atsctables.h dvbstreamdata.cpp
 dvbstreamdata.h dvbtables.cpp dvbtables.h mpegstreamdata.cpp
 mpegstreamdata.h mpegtables.cpp mpegtables.h tspacket.h
 Log Message:
 
 Cleanup of the mpeg table parser + some new features/tables.
 

Did you forget to commit something? I get this compile error:

g++ -c -pipe -march=athlon -Wall -W -g `freetype-config --cflags`
-D_REENTRANT -DPIC -fPIC  -DMMX -Di386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-DPREFIX=\/usr/local\ -DUSING_XV -DUSING_IVTV -DUSING_DVB -DUSING_DVB_EIT
-DUSING_OSS -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_NO_DEBUG
-I/usr/lib/qt-3.3/mkspecs/default -I. -I/usr/local/include
-I../../../dvb-kernel/linux/include -I../.. -I../libmyth -I.. -Idvbdev
-Impeg -I../libavcodec -I../libmythmpeg2 -I/usr/lib/qt-3.3/include -o
dtvsignalmonitor.o dtvsignalmonitor.cpp
In file included from mpeg/dvbtables.h:8,
 from dtvsignalmonitor.cpp:5:
mpeg/dvbdescriptors.h: In constructor
`AdaptationFieldDataDescriptor::AdaptationFieldDataDescriptor(const unsigned
char*)':
mpeg/dvbdescriptors.h:155: error: `Adaptation_field_data' is not a member of
`DescriptorID'
mpeg/dvbdescriptors.h: In constructor
`TimeShiftedEventDescriptor::TimeShiftedEventDescriptor(const unsigned
char*)':
mpeg/dvbdescriptors.h:1204: error: `dvb_time_shifted_event' is not a member
of `DescriptorID'
mpeg/dvbdescriptors.h: In constructor
`TimeShiftedServiceDescriptor::TimeShiftedServiceDescriptor(const unsigned
char*)':
mpeg/dvbdescriptors.h:1220: error: `time_shifted_service' is not a member of
`DescriptorID'
make[2]: *** [dtvsignalmonitor.o] Error 1

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-06-17 Thread Anduin Withers
 Modified Files:
in mythtv/libs/libmythtv:
 dtvsignalmonitor.cpp dtvsignalmonitor.h dvbsignalmonitor.cpp
 dvbsignalmonitor.h pchdtvsignalmonitor.cpp
 pchdtvsignalmonitor.h scanwizard.cpp signalmonitor.cpp
 signalmonitor.h

Seems to require changes in libs/libmythtv/mpeg/mpegdescriptors.h that
weren't checked in.

-- 
Anduin Withers


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:mythtv-commits-
 [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Friday, June 17, 2005 10:15 AM
 To: mythtv-commits@mythtv.org
 Subject: [mythtv-commits] mythtv commits
 
 --
 --
 Changes committed by danielk on Fri Jun 17 14:10:32 2005
 
 Modified Files:
in mythtv/libs/libmythtv:
 dtvsignalmonitor.cpp dtvsignalmonitor.h dvbsignalmonitor.cpp
 dvbsignalmonitor.h pchdtvsignalmonitor.cpp
 pchdtvsignalmonitor.h scanwizard.cpp signalmonitor.cpp
 signalmonitor.h
 Log Message:
 
 Some updates to the signal monitors.
 
 SignalMonitor has two new functions, IsSupported(), and Init().
 IsSupported returns true if signal monitoring is supported for
 a specific card type. Currently this returns true for DVB and ATSC
 card types, but analog could be added if John Pullan's analogscan
 stuff is put into a signal monitor class. Init creates the appropriate
 signal monitor class when given a card type, DB card number, and a
 channel class.
 
 I've also given the signal monitors QObject names, to make debugging
 signals easier.
 
 And the DTVSignalMonitor will accept a ScanStreamData in addition
 to ATSC and DVB stream data classes.
 
 --
 --

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-06-17 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:
 --
 --
 Changes committed by danielk on Fri Jun 17 17:24:33 2005
 
 Modified Files:
in mythtv/libs/libmythtv:
 channel.cpp channel.h channelbase.cpp channelbase.h
 dbcheck.cpp dvbchannel.cpp dvbchannel.h dvbtypes.cpp
 dvbtypes.h firewirechannel.h
 Log Message:
 
 These changes are to support two improvements faster DTV channel
 changing and a more generic channel scanning class. There is a
 database update, the pidcache table is added.
 

Now there is another compile error:

g++ -c -pipe -march=athlon -Wall -W -g `freetype-config --cflags`
-D_REENTRANT -DPIC -fPIC  -DMMX -Di386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-DPREFIX=\/usr/local\ -DUSING_XV -DUSING_IVTV -DUSING_DVB -DUSING_DVB_EIT
-DUSING_OSS -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_NO_DEBUG
-I/usr/lib/qt-3.3/mkspecs/default -I. -I/usr/local/include
-I../../../dvb-kernel/linux/include -I../.. -I../libmyth -I.. -Idvbdev
-Impeg -I../libavcodec -I../libmythmpeg2 -I/usr/lib/qt-3.3/include -o
dvbchannel.o dvbchannel.cpp
dvbchannel.cpp: In member function `virtual bool
DVBChannel::SetChannelByString(const QString)':
dvbchannel.cpp:209: error: `FE_ATSC' undeclared (first use this function)
dvbchannel.cpp:209: error: (Each undeclared identifier is reported only once
for each function it appears in.)

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits

2005-06-17 Thread John Pullan
try this :

On 17/06/05, Torbjrn Jansson [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]  wrote:
  --
  --
  Changes committed by danielk on Fri Jun 17 17:24:33 2005
 
  Modified Files:
 in mythtv/libs/libmythtv:
  channel.cpp channel.h channelbase.cpp channelbase.h
  dbcheck.cpp dvbchannel.cpp dvbchannel.h dvbtypes.cpp
  dvbtypes.h firewirechannel.h
  Log Message:
 
  These changes are to support two improvements faster DTV channel
  changing and a more generic channel scanning class. There is a
  database update, the pidcache table is added.
 
 
 Now there is another compile error:
 
 g++ -c -pipe -march=athlon -Wall -W -g `freetype-config --cflags`
 -D_REENTRANT -DPIC -fPIC  -DMMX -Di386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
 -DPREFIX=\/usr/local\ -DUSING_XV -DUSING_IVTV -DUSING_DVB -DUSING_DVB_EIT
 -DUSING_OSS -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_NO_DEBUG
 -I/usr/lib/qt-3.3/mkspecs/default -I. -I/usr/local/include
 -I../../../dvb-kernel/linux/include -I../.. -I../libmyth -I.. -Idvbdev
 -Impeg -I../libavcodec -I../libmythmpeg2 -I/usr/lib/qt-3.3/include -o
 dvbchannel.o dvbchannel.cpp
 dvbchannel.cpp: In member function `virtual bool
 DVBChannel::SetChannelByString(const QString)':
 dvbchannel.cpp:209: error: `FE_ATSC' undeclared (first use this function)
 dvbchannel.cpp:209: error: (Each undeclared identifier is reported only once
 for each function it appears in.)
 
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 


-- 
John
Index: dvbchannel.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/dvbchannel.cpp,v
retrieving revision 1.37
diff -u -r1.37 dvbchannel.cpp
--- dvbchannel.cpp  17 Jun 2005 17:24:33 -  1.37
+++ dvbchannel.cpp  17 Jun 2005 19:52:31 -
@@ -206,8 +206,10 @@
 if (curchannelname == chan  !force_channel_change)
 return true;
 
+#if (DVB_API_VERSION_MINOR == 1)
 if (FE_ATSC == info.type)
 SetCachedATSCInfo();
+#endif
 
 force_channel_change = false;
 
@@ -240,8 +242,10 @@
 
 inputChannel[currentcapchannel] = curchannelname;
 
+#if (DVB_API_VERSION_MINOR == 1)
 if (FE_ATSC == info.type)
 SetCachedATSCInfo(chan);
+#endif
 
 return true;
 }
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits

2005-06-17 Thread Daniel Kristjansson
On Fri, 2005-06-17 at 20:53 +0100, John Pullan wrote:
 On 17/06/05, Torbjrn Jansson [EMAIL PROTECTED] wrote:
  Now there is another compile error:
snip
 try this :
snip

I've applied the fix.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits (analog scan breaks build?)

2005-06-15 Thread Steven

I get this compiling cvs :
In file included from moc_analogscan.cpp:11:
analogscan.h:110: error: 'pthread_mutex_t' is used as a type, but is not
  defined as a type.
analogscan.h:112: error: 'pthread_t' is used as a type, but is not 
defined as a

  type.
analogscan.h:114: error: 'pthread_t' is used as a type, but is not 
defined as a

  type.

Steven

[EMAIL PROTECTED] wrote:



Changes committed by taylor on Tue Jun 14 22:00:42 2005

Added Files:
  in mythtv/libs/libmythtv:
   analogscan.cpp analogscan.h dvbconfparser.cpp dvbconfparser.h 
Modified Files:

  in mythtv/libs/libmythtv:
   channeleditor.cpp dbcheck.cpp dvbtransporteditor.cpp 
   dvbtypes.cpp dvbtypes.h libmythtv.pro scanwizard.cpp 
   scanwizard.h siparser.cpp siscan.cpp siscan.h videosource.cpp 
   videosource.h 
Log Message:

John Pullans massive ScanWizard patch.  Also adds in an Analog Scan that I am 
unable to test.

Keith Irwins patch to make TS Recording mode default for DVB, and add 0x80 type for OpenCable 
Mpeg2 streams.


I also removed the infamous delete code that has been causing many many issues with DVB Scaning and 
updating.




 




___
mythtv-commits mailing list
mythtv-commits@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
 



___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (analog scan breaks build?)

2005-06-15 Thread John Pullan
try bunging a #inlcude pthread.h at the top of analogscan.h

On 15/06/05, Steven [EMAIL PROTECTED] wrote:
 I get this compiling cvs :
 In file included from moc_analogscan.cpp:11:
 analogscan.h:110: error: 'pthread_mutex_t' is used as a type, but is not
defined as a type.
 analogscan.h:112: error: 'pthread_t' is used as a type, but is not
 defined as a
type.
 analogscan.h:114: error: 'pthread_t' is used as a type, but is not
 defined as a
type.
 
 Steven
 
 [EMAIL PROTECTED] wrote:
 
 
 Changes committed by taylor on Tue Jun 14 22:00:42 2005
 
 Added Files:
in mythtv/libs/libmythtv:
 analogscan.cpp analogscan.h dvbconfparser.cpp dvbconfparser.h
 Modified Files:
in mythtv/libs/libmythtv:
 channeleditor.cpp dbcheck.cpp dvbtransporteditor.cpp
 dvbtypes.cpp dvbtypes.h libmythtv.pro scanwizard.cpp
 scanwizard.h siparser.cpp siscan.cpp siscan.h videosource.cpp
 videosource.h
 Log Message:
 John Pullans massive ScanWizard patch.  Also adds in an Analog Scan that I 
 am unable to test.
 
 Keith Irwins patch to make TS Recording mode default for DVB, and add 0x80 
 type for OpenCable
 Mpeg2 streams.
 
 I also removed the infamous delete code that has been causing many many 
 issues with DVB Scaning and
 updating.
 
 
 
 
 
 
 
 ___
 mythtv-commits mailing list
 mythtv-commits@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
 
 
 
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 


-- 
John
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits (FTO)

2005-06-13 Thread Dean Ricker
I will be on FTO on the 13th through 17th. If there is an issue please contact 
Scott Hayes.
Thanks,
DR

 mythtv-dev 06/13/05 09:15 


Changes committed by jdonavan on Mon Jun 13 15:13:23 2005

Modified Files:
   in mythplugins/mythcontrols/mythcontrols:
actionid.h actionset.cpp actionset.h keybindings.cpp 
keybindings.h main.cpp mythcontrols.cpp 
Log Message:
Save on exit patch from Micah



___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-25 Thread Isaac Richards
On Wednesday 25 May 2005 11:35 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by ijr on Thu May 26 03:32:37 2005

 Modified Files:
in mythtv/programs/mythbackend:
 encoderlink.cpp encoderlink.h mainserver.cpp mainserver.h
 playbacksock.cpp playbacksock.h server.h
 Log Message:
 refcount the playbacksock objects, too.  Should fix other random issues
 with the backend dying.

Just wanted to note:  I didn't test this with slave backends (don't have one 
setup at the moment), so if someone who has one could confirm that things 
still run properly, I'd appreciate it.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-24 Thread Harvard Pan
Nigel,

After your check-in, I get this on my system when I try to compile:

filter_linearblend.c: In function `linearBlendFilter':
filter_linearblend.c:326: warning: empty body in an if-statement
filter_linearblend.c: In function `new_filter':
filter_linearblend.c:358: error: `linearBlendMMX' undeclared (first use in this function)
filter_linearblend.c:358: error: (Each undeclared identifier is reported only once
filter_linearblend.c:358: error: for each function it appears in.)
filter_linearblend.c:360: error: `linearBlend3DNow' undeclared (first use in this function)

The reason is that I am on a x86_64 system, which doesn't have i386
defined, but I do have MMX defined. The definition of those functions
are inside of a #ifdef i386, but the use of the function is within
#ifdef MMX. I would suggest changing the #ifdef statement in line 356
of filter_linearblend.c from:


#ifdef MMX


to


#if defined(MMX)  defined (i386)


Thanks,
Harvard
On 5/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Changes committed by nigel on Tue May 24 01:25:48 2005
Added Files: in mythtv/filters:filter-avcodec.pro filter-common.pro mm_arch.hModified Files: in mythtv/filters/adjust:
adjust.pro filter_adjust.c in mythtv/filters/bobdeint:bobdeint.pro in mythtv/filters/convert:
convert.pro in mythtv/filters/crop:crop.pro filter_crop.c in mythtv/filters/denoise3d:denoise3d.pro filter_denoise3d.c
 in mythtv/filters/force:force.pro in mythtv/filters/invert:invert.pro in mythtv/filters/kerneldeint:filter_kerneldeint.c 
kerneldeint.pro in mythtv/filters/linearblend:filter_linearblend.c linearblend.pro in mythtv/filters/onefield:
onefield.pro in mythtv/filters/postprocess:postprocess.pro in mythtv/filters/quickdnr:filter_quickdnr.c quickdnr.pro
Log Message:1 - Abstraction of common stuff from all the .pro files2 - Removal of dummy functions that are not needed on non-MMX3 - Determine Altivec acceleration at runtime (currently linearblend only)
4 - Tidy comments after #endifs (remove, or make C style in .c src)___mythtv-commits mailing list
mythtv-commits@mythtv.orghttp://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-05-21 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:

 Log Message:
 Old teletext page selection patch from Martin Moeller.
 Defer deletes of playback socks by at least 30 seconds.  Lots
 of overkill, but should possibly fix (or at least help)
 issues stemming from QSocket needing to run the event loop.
 

Is this a fix/help for the problem where some commands for no apparent
reason don't get any reply from the backend and causes the sender to just
sit there and wait?

That's a problem i have with the windows filters anyway.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-05-21 Thread Torbjörn Jansson
Torbjörn Jansson mailto:[EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]  wrote:
 
 Log Message:
 Old teletext page selection patch from Martin Moeller.
 Defer deletes of playback socks by at least 30 seconds.  Lots
 of overkill, but should possibly fix (or at least help)
 issues stemming from QSocket needing to run the event loop.
 
 
 Is this a fix/help for the problem where some commands for no
 apparent reason don't get any reply from the backend and
 causes the sender to just sit there and wait?
 
 That's a problem i have with the windows filters anyway.

I forgot, when i get this problem and wait, maybe 30 minutes or so i get
this in the backend log:

QSocketDevice::writeBlock: Invalid socket
about 200 lines like the one above left out
2005-05-21 19:31:40.571 WriteBlock zerocnt timeout
QSocketNotifier: invalid socket 33 and type 'Read', disabling...
2005-05-21 19:31:40.597 unknown socket
2005-05-21 19:31:40.609 unknown socket

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-21 Thread Isaac Richards
On Saturday 21 May 2005 02:14 pm, Torbjörn Jansson wrote:
 [EMAIL PROTECTED]  wrote:
  Log Message:
  Old teletext page selection patch from Martin Moeller.
  Defer deletes of playback socks by at least 30 seconds.  Lots
  of overkill, but should possibly fix (or at least help)
  issues stemming from QSocket needing to run the event loop.

 Is this a fix/help for the problem where some commands for no apparent
 reason don't get any reply from the backend and causes the sender to just
 sit there and wait?

 That's a problem i have with the windows filters anyway.

Nope.  Fix for a thread getting its socket deleted out from under it.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


RE: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-21 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:
 On Saturday 21 May 2005 02:14 pm, Torbjörn Jansson wrote:
 [EMAIL PROTECTED]  wrote:
 Log Message:
 Old teletext page selection patch from Martin Moeller.
 Defer deletes of playback socks by at least 30 seconds.  Lots
 of overkill, but should possibly fix (or at least help)
 issues stemming from QSocket needing to run the event loop.
 
 Is this a fix/help for the problem where some commands for no
 apparent reason don't get any reply from the backend and causes the
 sender to just sit there and wait? 
 
 That's a problem i have with the windows filters anyway.
 
 Nope.  Fix for a thread getting its socket deleted out from under it.
 
 Isaac

Ok, guess i'll have to continue trying to debug this problem then.
Maybe i can try running the backend under gdb and when i don't get any reply
break and examine the back trace and see what's going on.

When this problem happends the frontend just hangs too when doing things
that requier it to communicate with the backend.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-20 Thread Martin Moeller
Fredag den 20. maj 2005 09:25 skrev [EMAIL PROTECTED]:
 ---
- Changes committed by ijr on Fri May 20 07:22:37 2005

 Modified Files:
in mythtv:
 keys.txt
in mythtv/libs/libmythtv:
 NuppelVideoPlayer.cpp guidegrid.cpp tv_play.cpp
in mythtv/programs/mythbackend:
 mainserver.cpp mainserver.h
 Log Message:
 Old teletext page selection patch from Martin Moeller.
 Defer deletes of playback socks by at least 30 seconds.  Lots of overkill,
 but should possibly fix (or at least help) issues stemming from QSocket
 needing to run the event loop.


Thank you, thank you, thank you :)

/Martin.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)

2005-05-17 Thread Stuart Morgan
On Mon 16 May 2005 20:07, Taylor Jacob wrote:
 Quoting Stuart Morgan [EMAIL PROTECTED]:
  On Mon 16 May 2005 18:56, Wendy Seltzer wrote:
   This or the previous commit on the DVB code seems to kick in even
   when a sub-channel is temporarily off-air, and even when I haven't
   requested a re-scan.  Plus, it's overwriting the existing channel set
   and losing the xmltvid.
 
  I've had the same problem.
 
  Upgrading to the latest CVS resulted in half the channels being
  overwritten. Chanids changed lost resulting in broken schedules and
  xmltvids/icon paths were lost. Major pain to re-enter that data and run
  update queries on the data to incorrect chanids - although I accept that
  is the hazard of running CVS code.

 If Mythfilldatabase corrected these would that solve the problem?

If the channel data wasn't overwritten that might solve the problem.

I can't see how Mythfilldatabase would be able to correct the chanids, let 
alone the lost xmltvids and other channel settings. Mythfilldatabase isn't 
run all the time either - so broken schedules would mean missed recordings 
until the next run of Mythfilldatabase 24/48 hours or 7 days later!

I don't know the inner workings of Mythfilldatabase though - perhaps I'm 
wrong. I'm certainly not the best person to ask :)

Right now I've seen no further loss of channel information since the upgrade 
problems. All of the channels on Multiplex 1 were overwritten and one channel 
from Multiplex 2 (UK). Possibly there were changes between the information in 
the database for these channels and that being broadcast at the time of the 
upgrade. If every time there is a small change in broadcast information 
channels data will be overwritten then this is going to cause havoc.
-- 
Stuart Morgan
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-17 Thread Isaac Richards
On Tuesday 17 May 2005 07:05 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by nigel on Tue May 17 23:01:43 2005

 Modified Files:
in mythtv/libs/libmythtv:
 NuppelVideoRecorder.cpp
 Log Message:
 If users are disabling OSS, the sys/soundcard include is still used?

 ---

There really shouldn't be an explicit user-controllable disable-oss option.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-17 Thread Nigel Pearson
   in mythtv/libs/libmythtv:
NuppelVideoRecorder.cpp
Log Message:
If users are disabling OSS, the sys/soundcard include is still used?
-- 
-
There really shouldn't be an explicit user-controllable disable-oss  
option.

There may be merit in terms of disabling primitive
audio in a compiled binary, but I sort of agree - from the
client point of view we can just select a different audio
output method in the settings.
The problem I created is interesting, in that the audio
ioctls in NVR and mainserver.cpp only have single implementations,
but all the other audio stuff has OSS, ALSA, JACK, et c.
I wonder if those other APIs have different/better stuff
that could be used in AudioInit(), doAudioThread() and the
remote ringbuffer plumbing?
--
Nigel Pearson, [EMAIL PROTECTED] | People say I'm strange, does it
Telstra BID, Sydney, Australia   |make me a stranger?
Office: 8255 4222Fax:  8255 3153  |  My best friend was born
Mobile: 0408 664435  Home: 9792 6998  | in a manger-DC Talk
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)

2005-05-16 Thread Wendy Seltzer
This or the previous commit on the DVB code seems to kick in even 
when a sub-channel is temporarily off-air, and even when I haven't 
requested a re-scan.  Plus, it's overwriting the existing channel set 
and losing the xmltvid.

Specifically, my PBS affiliate (KQED) broadcasts 4 SD channels during 
the day and 2 HD at night.  If I tune to one at night, I lose the 
other 3 from the channels table, and even though I've numbered them 
901-905, I wind up with those dropped and new channels 91 and 92 
added.  (If I tune during the day, I wind up with 91-95.)  This seems 
like a bug, since I still want to be able to schedule recordings for 
the times 92-95 are on-air.

Pre-weekend code scanned ATSC channels and retained them without problems.
--Wendy
At 5:05 PM + 5/15/05, [EMAIL PROTECTED] wrote:

Changes committed by taylor on Sun May 15 17:02:30 2005
Modified Files:
   in mythtv/libs/libmythtv:
siscan.cpp siscan.h
Log Message:
Change to remove non-existant channels when Service tables are 
processed instead of leaving them
intact..

--
--
Wendy Seltzer -- [EMAIL PROTECTED] || [EMAIL PROTECTED]
Electronic Frontier Foundation
Berkman Center for Internet  Society at Harvard Law School
http://cyber.law.harvard.edu/seltzer.html
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)

2005-05-16 Thread Taylor Jacob
Quoting Wendy Seltzer [EMAIL PROTECTED]:

 This or the previous commit on the DVB code seems to kick in even
 when a sub-channel is temporarily off-air, and even when I haven't
 requested a re-scan.  Plus, it's overwriting the existing channel set
 and losing the xmltvid.

 Specifically, my PBS affiliate (KQED) broadcasts 4 SD channels during
 the day and 2 HD at night.  If I tune to one at night, I lose the
 other 3 from the channels table, and even though I've numbered them
 901-905, I wind up with those dropped and new channels 91 and 92
 added.  (If I tune during the day, I wind up with 91-95.)  This seems
 like a bug, since I still want to be able to schedule recordings for
 the times 92-95 are on-air.

 Pre-weekend code scanned ATSC channels and retained them without problems.

Are you saying that the VCT that KQED is sending changes at night when they
change their programming?  They are supposed to list all channels they have
constantly and just mark them as off the air, not change the program listings
twice a day..   Can you dump your TVCTs for this station using dvbsnoop (or
send me the -v siparser output [the text channel found is what im mostly
looking for]) during the day and night?  If this is the case you may need to
give them a call.. The myth code is supposed to re-build your channel lists
using the VCT whenever it changes, otherwise you really are taking no advantage
of digital tv, but I don't believe the VCTs are supposed to be implimented like
you are describing..

As far as the numbering issue I can see why that is a problem with this fix as
many people have chosen to re-number their channels.. I had the situation where
the serviceid changed but hte channel numbers stayed the same and my channels
table got screwed up and this seemed like the way to fix it.. I will see if I
can change this so it will leave custom numbering schemes alone..

As far as the XMLTV ids vanishing I am working on fixing this now, but I don't
think I will have it taken care of as I am heading to Arizona tomorrow and
won't be back until sunday..

Taylor
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)

2005-05-16 Thread Stuart Morgan
On Mon 16 May 2005 18:56, Wendy Seltzer wrote:
 This or the previous commit on the DVB code seems to kick in even
 when a sub-channel is temporarily off-air, and even when I haven't
 requested a re-scan.  Plus, it's overwriting the existing channel set
 and losing the xmltvid.

I've had the same problem.

Upgrading to the latest CVS resulted in half the channels being overwritten. 
Chanids changed lost resulting in broken schedules and xmltvids/icon paths 
were lost. Major pain to re-enter that data and run update queries on the 
data to incorrect chanids - although I accept that is the hazard of running 
CVS code.
-- 
Stuart Morgan
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)

2005-05-16 Thread Taylor Jacob
Quoting Stuart Morgan [EMAIL PROTECTED]:

 On Mon 16 May 2005 18:56, Wendy Seltzer wrote:
  This or the previous commit on the DVB code seems to kick in even
  when a sub-channel is temporarily off-air, and even when I haven't
  requested a re-scan.  Plus, it's overwriting the existing channel set
  and losing the xmltvid.

 I've had the same problem.

 Upgrading to the latest CVS resulted in half the channels being overwritten.
 Chanids changed lost resulting in broken schedules and xmltvids/icon paths
 were lost. Major pain to re-enter that data and run update queries on the
 data to incorrect chanids - although I accept that is the hazard of running
 CVS code.

If Mythfilldatabase corrected these would that solve the problem?

Taylor
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:
 --
 --
 Changes committed by taylor on Sun May 15 17:02:30 2005
 
 Modified Files:
in mythtv/libs/libmythtv:
 siscan.cpp siscan.h
 Log Message:
 Change to remove non-existant channels when Service tables
 are processed instead of leaving them
 intact..
 

This or something else in the recent commits must have broken something,
because i get:

siscan.cpp:81: error: `VSB_8' was not declared in this scope
siscan.cpp:83: error: `VSB_8' was not declared in this scope
siscan.cpp:85: error: `VSB_8' was not declared in this scope
make[2]: *** [siscan.o] Error 1

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


RE: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread Torbjörn Jansson
 This or something else in the recent commits must have broken
 something, because i get:
 
 siscan.cpp:81: error: `VSB_8' was not declared in this scope
 siscan.cpp:83: error: `VSB_8' was not declared in this scope
 siscan.cpp:85: error: `VSB_8' was not declared in this scope
 make[2]: *** [siscan.o] Error 1
 

My fault, i was using the wrong dvb include dir, i had one from cvs
linux-dvb 2.4 kernel and one from 2.6 and in the 2.4 VSB_8 is not defined.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread cythrault
On 5/15/05, Torbjörn Jansson [EMAIL PROTECTED] wrote:
  This or something else in the recent commits must have broken
  something, because i get:
 
  siscan.cpp:81: error: `VSB_8' was not declared in this scope
  siscan.cpp:83: error: `VSB_8' was not declared in this scope
  siscan.cpp:85: error: `VSB_8' was not declared in this scope
  make[2]: *** [siscan.o] Error 1
 
 
 My fault, i was using the wrong dvb include dir, i had one from cvs
 linux-dvb 2.4 kernel and one from 2.6 and in the 2.4 VSB_8 is not defined.

I use linux-2.6.10/include and I get the same error. Should I upgrade my kernel?

-- 
cyth
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


RE: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread Torbjörn Jansson
[EMAIL PROTECTED]  wrote:
 On 5/15/05, Torbjörn Jansson
 [EMAIL PROTECTED] wrote:
 This or something else in the recent commits must have broken
 something, because i get: 
 
 siscan.cpp:81: error: `VSB_8' was not declared in this scope
 siscan.cpp:83: error: `VSB_8' was not declared in this scope
 siscan.cpp:85: error: `VSB_8' was not declared in this scope
 make[2]: *** [siscan.o] Error 1
 
 
 My fault, i was using the wrong dvb include dir, i had one from cvs
 linux-dvb 2.4 kernel and one from 2.6 and in the 2.4 VSB_8 is not
 defined. 
 
 I use linux-2.6.10/include and I get the same error. Should I upgrade
 my kernel? 

That's not necessary.
The 2.6.10 include files doesn't contain the nessesary values (struct
fe_modulation or something like that)
Checkout the drivers from linux-dvb cvs, the 2.6 one, and point mythtv
config program to that directory instead.
That will work.

If you want to make sure you are using the right include files, just look
for a frontend.h file that contains VSB_8.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


RE: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread Taylor Jacob
Quoting Torbjörn Jansson [EMAIL PROTECTED]:
  This or something else in the recent commits must have broken
  something, because i get:
 
  siscan.cpp:81: error: `VSB_8' was not declared in this scope
  siscan.cpp:83: error: `VSB_8' was not declared in this scope
  siscan.cpp:85: error: `VSB_8' was not declared in this scope
  make[2]: *** [siscan.o] Error 1

Just fixed this.  Everywhere the 3.1 API is necessary (ATSC Stuff) there is
supposed to be a DVB_MINOR_VERISON #define, and there wasn't one in
siscan.cpp.. Should be fixed now.. Let me know if there are any other errors
with kernels  2.6.11..

Taylor
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits

2005-05-15 Thread Neale Swinnerton
i'm getting this with 2.6.10 kernel.



In member function `QString DVBTuning::modulation() const':
dvbtypes.cpp:130: error: 'const union
dvb_frontend_parameters::anonymous' has
   no member named 'vsb'
dvbtypes.cpp: In member function `bool DVBTuning::parseATSC(const QString,
   QString)':
dvbtypes.cpp:175: error: `t' undeclared (first use this function)
dvbtypes.cpp:175: error: (Each undeclared identifier is reported only
once for
   each function it appears in.)


vsb is new in 2.6.11, I don't know what the equivalent is in 2.6.10. I
think the 't' undeclared error is just a typo

Neale.


 Quoting Torbjörn Jansson [EMAIL PROTECTED]:
 
This or something else in the recent commits must have broken
something, because i get:

siscan.cpp:81: error: `VSB_8' was not declared in this scope
siscan.cpp:83: error: `VSB_8' was not declared in this scope
siscan.cpp:85: error: `VSB_8' was not declared in this scope
make[2]: *** [siscan.o] Error 1
 
 
 Just fixed this.  Everywhere the 3.1 API is necessary (ATSC Stuff) there is
 supposed to be a DVB_MINOR_VERISON #define, and there wasn't one in
 siscan.cpp.. Should be fixed now.. Let me know if there are any other errors
 with kernels  2.6.11..
 
 Taylor
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits (dvb scan patch related)

2005-05-15 Thread Taylor Jacob
Quoting Neale Swinnerton [EMAIL PROTECTED]:

 i'm getting this with 2.6.10 kernel.



 In member function `QString DVBTuning::modulation() const':
 dvbtypes.cpp:130: error: 'const union
 dvb_frontend_parameters::anonymous' has
no member named 'vsb'
 dvbtypes.cpp: In member function `bool DVBTuning::parseATSC(const QString,
QString)':
 dvbtypes.cpp:175: error: `t' undeclared (first use this function)
 dvbtypes.cpp:175: error: (Each undeclared identifier is reported only
 once for
each function it appears in.)


 vsb is new in 2.6.11, I don't know what the equivalent is in 2.6.10. I
 think the 't' undeclared error is just a typo

Try now.. I just made a change that should let it compile with 2.6.10..

Taylor
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] RE: [mythtv-commits] mythtv commits (dvb scan patch related)

2005-05-15 Thread Neale Swinnerton

you're still referencing 't'.

Here's my patch, that I did before you replied...This compiles.

Neale.


Taylor Jacob wrote:
 Quoting Neale Swinnerton [EMAIL PROTECTED]:
 
 
i'm getting this with 2.6.10 kernel.



In member function `QString DVBTuning::modulation() const':
dvbtypes.cpp:130: error: 'const union
dvb_frontend_parameters::anonymous' has
   no member named 'vsb'
dvbtypes.cpp: In member function `bool DVBTuning::parseATSC(const QString,
   QString)':
dvbtypes.cpp:175: error: `t' undeclared (first use this function)
dvbtypes.cpp:175: error: (Each undeclared identifier is reported only
once for
   each function it appears in.)


vsb is new in 2.6.11, I don't know what the equivalent is in 2.6.10. I
think the 't' undeclared error is just a typo
 
 
 Try now.. I just made a change that should let it compile with 2.6.10..
 
 Taylor
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 
Index: libs/libmythtv/dvbtypes.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/dvbtypes.cpp,v
retrieving revision 1.1
diff -u -w -r1.1 dvbtypes.cpp
--- libs/libmythtv/dvbtypes.cpp	15 May 2005 16:39:29 -	1.1
+++ libs/libmythtv/dvbtypes.cpp	15 May 2005 23:42:58 -
@@ -127,6 +127,7 @@
 
 QString DVBTuning::modulation() const
 {
+#if (DVB_API_VERSION_MINOR == 1)
 switch(params.u.vsb.modulation)
 {
 case QPSK:
@@ -141,16 +142,17 @@
 return qam_128;
 case QAM_256:
 return qam_256;
-#if (DVB_API_VERSION_MINOR == 1)
 case VSB_8:
 return 8vsb;
 case VSB_16:
 return 16vsb;
-#endif
 case QAM_AUTO:
 default:
 return auto;
 }
+#else
+return auto;
+#endif
 }
 
 bool DVBTuning::parseATSC(const QString frequency, const QString modulation)
@@ -172,7 +174,6 @@
 #else
(void)frequency;
(void)modulation;
-   (void)t;
 #endif
 return true;
 }
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-14 Thread Bruce Markey
Isaac Richards wrote:
On Thursday 12 May 2005 10:30 pm, [EMAIL PROTECTED] wrote:
---
- Changes committed by bjm on Thu May 12 20:51:49 2005
Modified Files:
  in mythtv/libs/libmythtv:
   RingBuffer.cpp
Log Message:
Don't spin the read ahead thread when the buffer is already full. A little
more aggressive when the buffer is nearly empty.

Might want to play with getting rid of the read-ahead thread entirely for 
local content, and only use it for streamed stuff.  If something like the 
'extra audio buffering' code from avformatdecoder.cpp was in 
nuppeldecoder.cpp, it probably wouldn't be necessary anymore.
I'll take a look at it. Might not be much of a performance win
and if there is any chance of a burst of motion out running the
filesystem read ahead then it may not be a good thing. Keeping
the 2.5MB buffer is cheap and takes the fs characteristics almost
completely out of the equation.
--  bjm
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-14 Thread Isaac Richards
On Saturday 14 May 2005 01:37 pm, Bruce Markey wrote:
 I'll take a look at it. Might not be much of a performance win
 and if there is any chance of a burst of motion out running the
 filesystem read ahead then it may not be a good thing. Keeping
 the 2.5MB buffer is cheap and takes the fs characteristics almost
 completely out of the equation.

Yeah, but it is an extra thread, with all the extra locking, wait conditions, 
etc.  Simplification's good. =)

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits (mythmusic FFTW breaks build?)

2005-05-14 Thread Steven
I've tried switching to the new fftw 3.0.1 but that doesn't fix things. 
This is what I get :

g++ -c -pipe -Wall -W -fomit-frame-pointer -I/usr/include/SDL 
-D_REENTRANT -D_REENTRANT -DPIC -fPIC  -D_GNU_SOURCE -DPREFIX=\/usr\ 
-D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_PLUGIN 
-DQT_SHARED -I/usr/lib/qt/mkspecs/default -I. -I/usr/include 
-I/usr/kde/3.3/include -I/usr/include -I/usr/include/cdda 
-I/usr/lib/qt/include -I/usr/X11R6/include -o visualize.o visualize.cpp
visualize.cpp: In constructor `Spectrum::Spectrum()':
visualize.cpp:57: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:58: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:59: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:60: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp: In constructor `Gears::Gears(QWidget*, const char*)':
visualize.cpp:610: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:611: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:612: error: invalid conversion from `void*' to `fftw_real*'
visualize.cpp:613: error: invalid conversion from `void*' to `fftw_real*'
make[2]: *** [visualize.o] Error 1


[EMAIL PROTECTED] schreef:

Changes committed by danielk on Fri May 13 16:36:30 2005
Modified Files:
  in mythplugins/mythmusic/mythmusic:
   inlines.h visualize.cpp visualize.h 
  in mythplugins:
   configure 
Log Message:

Ported mythmusic to FFTW v 3.0, modified configure to enable FFTW3
if present.
I'm not sure if I got the amplitude funtion right in visualize.cpp.
I cribbed the FFTW v 2.0 ones, but it appears to conflate the 
high and low frequencies. It may have something to do with the
the rfftw_one returning an array of floats, while the new fftw_execute
returns an array of complexes. But according to the 2.0 docs the 
rfftw_one function really returns complex values typecast as floats,
in which case the 2.0 magnitude function is more broken than the 3.0
magnitude fucntion.

Someone who knows what this code is supposed to do should look at this.
At this point it compiles, links, and appears to do the right
thing in the visualizations to my untrained eyes.
PS The arrays were not properly aligned before, I now allocate the
arrays with av_malloc, so that FFTW can use SIMD instructions.
The FFTW could be further sped up by using floats instead of doubles,
using the SEE int32_to_float instructions when available, by using
the  halfcomplex-format DFT instead of the full FFT, and/or by saving
and restoring the FFTW Wisdom to speed up startup time.
* FFTW Wisdom is determined by executing several different FFT
algorithms until the best one is found for the current array
alignments, array sizes, processor architecture, etc. It doesn't
take long on my 2.8Ghz machine, but...

 

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (mythmusic FFTW breaks build?)

2005-05-14 Thread Daniel Kristjansson
On Sat, 2005-05-14 at 19:49 +0200, Steven wrote:
 I've tried switching to the new fftw 3.0.1 but that doesn't fix things. 
 This is what I get :

You need to rerun the plugins' ./configure after upgrading the library.

PS I've checked in a fix for the fftw 2.x compile problem.

-- Daniel



___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-12 Thread Bruce Markey
[EMAIL PROTECTED] wrote:

Changes committed by ijr on Thu May 12 17:27:31 2005
Modified Files:
   in mythtv:
README 
Log Message:
Making sure the commits list still works..


This got through but none since :-(.


Revision 1.469  - (view) (download) (as text) (annotate) - [select for diffs]
Thu May 12 21:12:34 2005 UTC (108 minutes, 52 seconds ago) by danielk
Branch: MAIN
Changes since 1.468: +5 -6 lines
Diff to previous 1.468
Partial fix for some of the problems when editing an MPEG stream with
XVideo or XvMC.
XLnt!
The change in NuppelVideoPlayer.cpp prevents an out out order frame from
being displayed between the time a seek is done and the time
UpdatePauseFrame() is executed.
Verified fix.
Adding ClearAfterSeek() to videout_xv allows us to discard frames earlier
when using XvMC and seeking. This should speed up seeking quite a bit.
However there are still a couple problems.
  First, for some reason when bobdeint is enabled Show is called once
  with the wrong parameters after a seek or pause, causing a pop
  for regular XVideo output.
This was a big problem when bob first went in. I looked up the work
around from rev 1.363 on Sep 2, 2004 and did the same sort of thing
again. Seems to work but it would be nice to find the root cause and
a proper solution.
--  bjm
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-12 Thread Isaac Richards
On Thursday 12 May 2005 07:17 pm, Bruce Markey wrote:
 [EMAIL PROTECTED] wrote:
  -
 --- Changes committed by ijr on Thu May 12 17:27:31 2005
 
  Modified Files:
 in mythtv:
  README
  Log Message:
  Making sure the commits list still works..
 
  -
 ---

 This got through but none since :-(.

Looks like something ate the cron job that was supposed to be mailing things 
out..  Should trigger in a minute or so, I hope..

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-12 Thread Isaac Richards
On Thursday 12 May 2005 10:30 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by bjm on Thu May 12 20:51:49 2005

 Modified Files:
in mythtv/libs/libmythtv:
 RingBuffer.cpp
 Log Message:
 Don't spin the read ahead thread when the buffer is already full. A little
 more aggressive when the buffer is nearly empty.

Might want to play with getting rid of the read-ahead thread entirely for 
local content, and only use it for streamed stuff.  If something like the 
'extra audio buffering' code from avformatdecoder.cpp was in 
nuppeldecoder.cpp, it probably wouldn't be necessary anymore.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-11 Thread Herman Kuiper
Clean up the article text by removing HTML elements we can't display
properly and honoring p and br
Maybe combine this one with my patch on strippings tags from program info?
Herman
-
Herman Kuiper - m: [EMAIL PROTECTED] - w: http://www.frontier.nl
Beech Ave 162 - 1119 PS  Schiphol-Rijk - t/f: 020-6589034/6142816
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits [Client stuff for doing visualizations over rtsp.]

2005-05-05 Thread Simon Kenyon
On Thursday 05 May 2005 14:20, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by thor on Thu May  5 14:19:59 2005

 Added Files:
in mfe/mfe/visualize:
 inlines.h stereoscope.cpp stereoscope.h visual.cpp visual.h
 visualnode.cpp visualnode.h
 Modified Files:
in mfe/mfe:
 mfe-ui.xml mfe.pro mfedialog.cpp mfedialog.h
 Log Message:

 Client stuff for doing visualizations over rtsp.

 It is now possible to play music using the mfe where:

 1. The visualization is on one host (where the mfe is)
 2. The decoding is on another host (where the mfd is)
 3. The speakers are on a still different host (another mfd)
 4. The content is on still yet another host (another mfd/iTunes/etc.)
 5. Other mfe viz's and or speakers on even more hosts can be sync'd

 Hmmm, sometimes mpg123 seems easier  :-)

i see you are working on visualisations
goom (my visualisation of choice in mythmusic) is well out of sync with the 
original source. would you consider syncing up with it as part of your plans. 
the latest goom has some nice features (being able to specifiy the math used 
to generate the images in an interpreted language).
--
simon
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-05 Thread Daniel Kristjansson
On Wed, 2005-05-04 at 16:15 -0700, Bruce Markey wrote:
 Daniel Kristjansson wrote:
 The one anomaly was the TVout from a GeForce4 MX 420 was correct
 for all negative values and positive values up to 3%. At four
 percent or higher, the fields were off by one scan line causing
 doubled horizontal edges. This was not the case for TVout from
 a 5200 or monitor output so I believe this was an anomaly of
 that card/driver rather than a miscalculation.
Hmmm, I'm using a GeForce 4 MX. I just added a fix for this
that does overscan compensation when the overscan is greater
than or equal to 5%. It does get one scan line off, but then
never gets worse (like it did before). But if this is a 
GeForce 4 MX problem only then we should detect this and only
do this compensation in this one case.

Do people generally use an overscan = 5%?

 Here is the output from a 1400x1050 monitor. 640x480 GUI with
 fullscreen playback and vertical overscan at +6% . The values
 appear to be correct including xv_dest_y_incr=2 to account for
 the scaling.
Sounds good.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits [Client stuff for doing visualizations over rtsp.]

2005-05-05 Thread thor
On Thursday 05 May 2005 12:57 pm, Simon Kenyon wrote:

  It is now possible to play music using the mfe where:
 
  1. The visualization is on one host (where the mfe is)
  2. The decoding is on another host (where the mfd is)
  3. The speakers are on a still different host (another mfd)
  4. The content is on still yet another host (another mfd/iTunes/etc.)
  5. Other mfe viz's and or speakers on even more hosts can be sync'd
 

 Almost forgot, kick the whole thing off from a web browser on even still yet 
another host.


 i see you are working on visualisations
 goom (my visualisation of choice in mythmusic) is well out of sync with the
 original source. would you consider syncing up with it as part of your
 plans. the latest goom has some nice features (being able to specifiy the
 math used to generate the images in an interpreted language).

 I'll take a quick look, but can't promise anything. I have about a bazillion 
things on the mfd/mfe todo list, and polishing visualizations (as opposed to 
make them possible) is not high on the list  :-)

- thor
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-05 Thread Bruce Markey
Daniel Kristjansson wrote:
On Wed, 2005-05-04 at 16:15 -0700, Bruce Markey wrote:
Daniel Kristjansson wrote:
The one anomaly was the TVout from a GeForce4 MX 420 was correct
for all negative values and positive values up to 3%. At four
percent or higher, the fields were off by one scan line causing
doubled horizontal edges. This was not the case for TVout from
a 5200 or monitor output so I believe this was an anomaly of
that card/driver rather than a miscalculation.
Hmmm, I'm using a GeForce 4 MX. I just added a fix for this
that does overscan compensation when the overscan is greater
than or equal to 5%. It does get one scan line off, but then
never gets worse (like it did before). But if this is a 
GeForce 4 MX problem only then we should detect this and only
do this compensation in this one case.
For me, the cutoff is at 4%. 3% doesn't have this problem.
Do people generally use an overscan = 5%?
Good question and in theory, the answer should be no. The TV image
is supposed to extend beyond the edge of the screen. The 'action
safe' area is 5% in from the edge and anything the viewer needs
see see to understand what's going on should fall inside those
bounds. The 'title safe' area is 10% in from the edge for text
that needs to be read.
If the X display area is set to fit the edges of the screen exactly,
the image should not have to be overscanned by more than 5% to cut
off the ragged edges and the empty space below a crawl for example
and to look normal. More than 5% would start to cutoff parts of the
image that need to be seen.
I used 6% for the test case to be sure the uncentered image would
be obvious but 2% or 3% would be more typical values.
--  bjm
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Bruce Markey
[EMAIL PROTECTED] wrote:

Changes committed by ijr on Wed May  4 06:15:55 2005
Modified Files:
   in mythtv/libs/libmythtv:
videobuffers.cpp videoout_xv.cpp 
...
Fix bug #281 (bob frames misaligned.  y offset from calc_bob was way off).
Verified fix. Thanks.
--  bjm
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Tj
Bruce Markey wrote:
Verified fix. Thanks.
Just about to send this before I see ur mail.
Does your thumbnails in mythweb work properly? Delete all .png files in 
your video recordings and mythtv image_buffers directory to force it to 
regenerate.. On my system the green bars are gone, but the pixelation is 
still there.


___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Isaac Richards
On Wednesday 04 May 2005 10:54 am, Daniel Kristjansson wrote:
 On Wed, 2005-05-04 at 06:20 +, [EMAIL PROTECTED] wrote:
  -
 --- Changes committed by ijr on Wed May  4 06:15:55 2005
 
  Modified Files:
 in mythtv/libs/libmythtv:
  videobuffers.cpp videoout_xv.cpp
  Log Message:
  Fix bug #280 (green screen caused by uninitialized video buffers)
  Fix bug #281 (bob frames misaligned.  y offset from calc_bob was way
  off).

 This appears to seriously break XvMC bobdeint for me. I'm now getting
 one normal field and the other displaced upward half a frame height.

Yup.  I didn't bother fixing it last night because xvmc playback was broken 
before the change as well.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Isaac Richards
On Wednesday 04 May 2005 12:17 pm, Isaac Richards wrote:
 Yup.  I didn't bother fixing it last night because xvmc playback was broken
 before the change as well.

I can't even play SD material properly with xvmc anymore.  Looks like the big 
X11 locks in the opengl vsync code are interferring with the locks in the 
xvmc playback.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Daniel Kristjansson
On Wed, 2005-05-04 at 13:25 -0400, Isaac Richards wrote:
 On Wednesday 04 May 2005 12:17 pm, Isaac Richards wrote:
  Yup.  I didn't bother fixing it last night because xvmc playback was broken
  before the change as well.
 
 I can't even play SD material properly with xvmc anymore.  Looks like the big 
 X11 locks in the opengl vsync code are interferring with the locks in the 
 xvmc playback.

@ around 559? this bit?
X11L;
r = glXMakeCurrent(m_display, m_drawable, m_context);
r = glXGetVideoSyncSGI(count);
X11U;

From what J. Donovan Stanley told me, at least glXGetVideoSyncSGI()
probably does not need to be in the lock. We also probably don't need
to call glXMakeCurrent all the time, no other code is attaching a
different OGL context to our drawable...

BTW I'm working on a bob fix that doesn't break XvMC, I'll probably send
a patch tonight if my testing goes well.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-05-04 Thread Daniel Kristjansson
On Wed, 2005-05-04 at 14:17 -0400, Daniel Kristjansson wrote:

 BTW I'm working on a bob fix that doesn't break XvMC, I'll probably send
 a patch tonight if my testing goes well.

Attached is a patch that fixes bob displacement for overscan
with XVideo, while letting XvMC still work when there is no
overscan.

It appears the nVidia closed source drivers no longer
require a bob displacement, as of v66.29. Of course, this
is a blessing and a curse, the automatic displacement
means we don't need a displacement normally, but it does
not work at all when we do over/under scan.

I've tried the obvious of applying displacement only in the
overscan or underscan cases, and also the less obvious of
calculating the normal displacement and over/under scan
displacement then applying the difference. Neither worked.

Anyway, I'd like to know if the patch is a regression
for anyone before applying it.

-- Daniel
Index: libs/libmythtv/videoout_xv.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/videoout_xv.cpp,v
retrieving revision 1.138
diff -u -r1.138 videoout_xv.cpp
--- libs/libmythtv/videoout_xv.cpp	4 May 2005 14:47:57 -	1.138
+++ libs/libmythtv/videoout_xv.cpp	4 May 2005 19:33:51 -
@@ -1848,34 +1848,65 @@
 }
 
 static void calc_bob(FrameScanType scan, int imgh, int disphoff,
-int imgy, int dispyoff,
-int frame_height, int top_field_first,
-int field, int src_y, int dest_y)
+ int imgy, int dispyoff,
+ int frame_height, int top_field_first,
+ int field, int src_y, int dest_y,
+ int xv_src_y_incr, int xv_dest_y_incr)
 {
 int dst_half_line_in_src = 0, dest_y_incr = 0, src_y_incr = 0;
+field = 3;
+src_y = imgy;
+dest_y = dispyoff;
+xv_src_y_incr = 0;
 // a negative offset y gives us bobbing, so adjust...
 if (dispyoff  0)
 {
 dest_y_incr = -dispyoff;
-src_y_incr = (int) (dest_y_incr * imgh * 0.5 / disphoff);
+src_y_incr = (int) (dest_y_incr * imgh / disphoff);
+xv_src_y_incr -= (int) (0.5 * dest_y_incr * imgh / disphoff);
 }
 
 if ((scan == kScan_Interlaced  top_field_first == 1) ||
 (scan == kScan_Intr2ndField  top_field_first == 0))
 {
 field = 1;
-src_y = imgy / 2;
+xv_src_y_incr = - imgy / 2;
 }
 else if ((scan == kScan_Interlaced  top_field_first == 0) ||
  (scan == kScan_Intr2ndField  top_field_first == 1))
 {
 field = 2;
-src_y = (frame_height + imgy) / 2;
-dst_half_line_in_src = (int) round(((float)disphoff)/imgh - 0.001f);
+xv_src_y_incr += (frame_height - imgy) / 2;
+
+dst_half_line_in_src =
+max((int) rounddouble)disphoff)/imgh) - 0.1), 0);
 }
+//if (frame_heightimgh  2==field)
+xv_dest_y_incr = dst_half_line_in_src;
+//else
+//dest_y += dst_half_line_in_src;
 
 src_y += src_y_incr;
-dest_y += dst_half_line_in_src + dest_y_incr;
+dest_y += dest_y_incr;
+
+// DEBUG
+#if 1
+static int last_dest_y_field[3] = { -1000, -1000, -1000, };
+int last_dest_y = last_dest_y_field[field];
+
+if (last_dest_y != dest_y)
+{
+cerr### Field field ###endl;
+cerr src_y: src_yendl;
+cerrdest_y: dest_yendl;
+cerr xv_src_y_incr: xv_src_y_increndl;
+cerrxv_dest_y_incr: xv_dest_y_increndl;
+cerr  disphoff: disphoffendl;
+cerr  imgh: imghendl;
+cerrendl;
+}
+last_dest_y_field[field] = dest_y;
+#endif
 }
 
 void VideoOutputXv::ShowXvMC(FrameScanType scan)
@@ -1907,11 +1938,12 @@
 
 // calculate bobbing params
 int field = 3, src_y = imgy, dest_y = dispyoff;
+int xv_src_y_incr = 0, xv_dest_y_incr = 0;
 if (m_deinterlacing)
 {
 calc_bob(scan, imgh, disphoff, imgy, dispyoff,
  frame-height, frame-top_field_first,
- field, src_y, dest_y);
+ field, src_y, dest_y, xv_src_y_incr, xv_dest_y_incr);
 }
 if (hasVLDAcceleration())
 {   // don't do bob-adjustment for VLD drivers
@@ -1972,12 +2004,14 @@
 return;
 }
 
-int field = 3, src_y = imgy, dest_y = dispyoff;
+int field = 3, src_y = imgy, dest_y = dispyoff, xv_src_y_incr = 0, xv_dest_y_incr = 0;
 if (m_deinterlacing  (m_deintfiltername == bobdeint))
 {
 calc_bob(scan, imgh, disphoff, imgy, dispyoff,
  frame-height, frame-top_field_first,
- field, src_y, dest_y);
+ field, src_y, dest_y, xv_src_y_incr, xv_dest_y_incr);
+src_y += xv_src_y_incr;
+dest_y += xv_dest_y_incr;
 }
 
 vbuffers.UnlockFrame(frame, ShowXVideo);
@@ -2021,8 +2055,8 @@
  */
 void VideoOutputXv::DrawUnusedRects(bool sync)
 {
-// boboff assumes the smallest 

Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-30 Thread Andrew Mahone
I'm seeing the same.  If you look at the generated moc_settings.cpp,
the #ifdef USING_XVMC has been stripped, so that the generated code
for XvMCHostCheckBox attempts to compile regardless of the define. 
This breaks, because the #ifdef still exists around class definition
settings.h, and the compiler chokes on all of these references to an
undefined class.

I'm not sure what the correct fix for this is.  For a work-around, I
killed the XvMCHostCheckBox members from the generated
moc_settings.cpp, which got me as far as finishing libmyth.  I'm still
waiting for the rest to finish, so I'm not sure if similar issues will
bite me anywhere else.

On 4/23/05, Bruce Markey [EMAIL PROTECTED] wrote:
oopsmissingXvMCHostCheckboxjunk
-- 
Andrew Mahone
andrew DOT mahone AT gmail DOT com
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-24 Thread Ian Dall
Daniel Kristjansson writes:
  On Sat, 2005-04-23 at 02:05 +, [EMAIL PROTECTED] wrote:
   
   Changes committed by danielk on Sat Apr 23 02:04:33 2005
  snip
   Log Message:
   
   NOTE: I recommend a make distclean...
  
  I just wanted to add that I expect there to be a few problems as this
  gets wider testing.
  
  Bring it on.

This is a big improvement on all fronts. OSD flicker seems to be gone, and so 
far I haven't seen any problems with skipping forward/back.

However, switching between SD and HD channels in Live TV browse mode
triggered this SIGABRT:

[...]
[mpegvideo_xvmc @ 0xb7772888]ac-tex damaged at 0 32
[mpegvideo_xvmc @ 0xb7772888]ac-tex damaged at 0 33
[mpegvideo_xvmc @ 0xb7772888]ac-tex damaged at 0 34
[mpegvideo_xvmc @ 0xb7772888]invalid mb type in I Frame at 0 35
*** glibc detected *** double free or corruption: 0x08d56270 ***
 
Program received signal SIGABRT, Aborted.
[Switching to Thread -1289409616 (LWP 21240)]
0xe402 in __kernel_vsyscall ()
(gdb) bt
#0  0xe402 in __kernel_vsyscall ()
#1  0x4647b955 in raise () from /lib/tls/libc.so.6
#2  0x4647d319 in abort () from /lib/tls/libc.so.6
#3  0x464b4a1b in malloc_printerr () from /lib/tls/libc.so.6
#4  0x464b54ba in free () from /lib/tls/libc.so.6
#5  0xb75d77d8 in av_free (ptr=0x0) at mem.c:123
#6  0xb780d4b0 in av_destruct_packet (pkt=0x8e88580) at utils.c:172
#7  0xb7bbaabb in av_free_packet (pkt=0x8e88580) at avformat.h:71
#8  0xb7bc3ad4 in AvFormatDecoder::GetFrame (this=0xb1f60008, onlyvideo=0)
at avformatdecoder.cpp:1741
#9  0xb7a94dcf in NuppelVideoPlayer::GetFrame (this=0x81c5720, onlyvideo=0,
unsafe=false) at NuppelVideoPlayer.cpp:899
#10 0xb7a9b0c3 in NuppelVideoPlayer::StartPlaying (this=0x81c5720)
at NuppelVideoPlayer.cpp:2100
#11 0xb7b4aeeb in SpawnDecode (param=0x81c5720) at tv_play.cpp:210
#12 0x466881d5 in start_thread () from /lib/tls/libpthread.so.0
#13 0x465192da in clone () from /lib/tls/libc.so.6
(gdb)


I'm not sure of the status of support for HD, but a SIGABRT is not good!

Ian
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-24 Thread Daniel Kristjansson
On Sun, 2005-04-24 at 17:14 +0930, Ian Dall wrote:

 However, switching between SD and HD channels in Live TV browse mode
 triggered this SIGABRT:

Does this happen only on the switch to HD, or also on the switch to SD?

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-24 Thread Ian Dall
Daniel Kristjansson writes:
  On Sun, 2005-04-24 at 17:14 +0930, Ian Dall wrote:
  
   However, switching between SD and HD channels in Live TV browse mode
   triggered this SIGABRT:
  
  Does this happen only on the switch to HD, or also on the switch to SD?

Channel switching in general seems to be a bit dodgy (it takes a long
time and often lead to hangs as well as SIGABRT crashes). But the switch
to or from HD seems to ALWAYS lead to problems.

Ian
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-23 Thread Ivor Hewitt
On Saturday 23 Apr 2005 03:23, Daniel Kristjansson wrote:
 On Sat, 2005-04-23 at 02:05 +, [EMAIL PROTECTED] wrote:
  -
 --- Changes committed by danielk on Sat Apr 23 02:04:33 2005

 snip

  Log Message:
 
  NOTE: I recommend a make distclean...

 I just wanted to add that I expect there to be a few problems as this
 gets wider testing.

 Bring it on.

Magic.
I'll give it a hammering over the weekend haven't had a chance to test 
some of the more recent patches. Got distracted fixing the unichrome 
driver I can't multi-task one project at a time.

Now this is in, I'll post the matching colour osd patch. (got it working in 
the end - for some reason sometimes the osd object contained a null pointer. 
no idea why yet, but it was much more likely to happen with the colour patch)

Ivor.
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMCmerge)

2005-04-23 Thread John Pullan
On 23/04/05, Mark Spieth [EMAIL PROTECTED] wrote:
 just noticed a compile problem with XVMC disabled and daniels new stuff
 not sure about this qt issue but it seems as if the
 #ifdef USING_XVMC
 class XvMCHostCheckBox : virtual public HostCheckBox
 ...
 #endif
 is not being replicated through the moc_settings.cpp generation.
 any ideas? or does this class have to be extracted into another file say
 xvmc_settings.h and then conditionalised in the make system?
 cheers
 mark
 
Should this control even be in settings.* ? shouldn't it be more local
to where its' needed, it does seem very specific ?

-- 
John
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-23 Thread Doug Larrick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Kristjansson wrote:
 I just wanted to add that I expect there to be a few problems as this
 gets wider testing.
 
 Bring it on.

Hi Daniel,

This looks good for Xv.  No problems so far in my testing.

Things are not so good for XvMC for me.

The biggest problem I'm having is that it seems the video card (nVidia
MX-440, driver 7174) is not reset properly sometimes, because I'll go to
play a recording (any recording) and get just the blue screen with a
burst of sound every second or so.  Log file (--verbose playback) for a
playback when that's happeining is attached (novideo.log).  When it's in
that state, Xv shows just a blue screen as well, so it's probably
related to whatever driver bug triggers that problem.  But I can't even
run through my entire list of test clips  w/o triggering this using
XvMC, so something's up there.

Most of my HD recordings are choppy (prebuffering pause every second or
so).  I wonder if this is related to my monitor running at 60.0 Hz
rather than 59.94 (even though straight Xv is working fine)?  Anyway,
one of them spits out a bunch of messages like AddInheritence past
ENOT in used or in done. ALAAAdLd.  Log file (--verbose playback)
for that recording is attached (abc-in-hd.log).  You can find that
recording at http://jekyl.no-ip.org/abc-in-hd.mpg .  This is 115MB, and
I'm on a cable modem, so I'd appreciate folks not pulling it unnecessarily.

- -Doug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCalcCf1/38+/zqMERAlaAAJ9Z/1iJ9DEoU7RFZIrJYUJIB8z/pQCfcP/j
2B6JogasfJgwujbc/Q9yTiA=
=Jzwg
-END PGP SIGNATURE-
$ mythfrontend --verbose playback
Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
QSettings::sync: filename is null/empty
2005-04-23 09:51:33.837 New DB connection, total: 1
Total desktop width=1600, height=1200, numscreens=1
2005-04-23 09:51:33.844 Running in a window
2005-04-23 09:51:33.847 Using screen 0, 1516x1128 at 36,24
2005-04-23 09:51:33.851 mythfrontend version: 0.18.20050409-1 www.mythtv.org
2005-04-23 09:51:33.851 Enabled verbose msgs : important general playback
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
2005-04-23 09:51:34.019 max_width: 1600 max_height: 1200
2005-04-23 09:51:34.086 Switching to square mode (Titivillus)
mythtv: could not connect to socket
mythtv: No such file or directory
lirc_in2005-04-23 09:51:34.300 Joystick disabled.
it failed for mythtv, see preceding messages
2005-04-23 09:51:34.356 Registering Internal as a media playback plugin.
Error loading image file: /usr/share/mythtv/themes/default/NOTHING.png
2005-04-23 09:51:37.218 Default
2005-04-23 09:51:37.421 Connecting to backend server: 127.0.0.1:6543 (try 1 of 5)
2005-04-23 09:51:37.431 Using protocol version 15
2005-04-23 09:51:37.439 MainServer::HandleAnnounce Playback
2005-04-23 09:51:37.440 adding: deckard as a client (events: 0)
2005-04-23 09:51:37.630 MainServer::HandleAnnounce Playback
2005-04-23 09:51:37.630 adding: deckard as a client (events: 1)
QSettings::sync: filename is null/empty
2005-04-23 09:51:40.294 New DB connection, total: 2
adding pes stream at pid 0x11 with type 2
adding pes stream at pid 0x14 with type 129
2005-04-23 09:51:40.375 AVFD: Opening Stream #0: codec id 2
2005-04-23 09:51:40.376 detectInterlace(Detect Scan, Detect Scan, 29.97, 1088) -Interlaced Scan
2005-04-23 09:51:40.377 Interlaced: Interlaced Scan  video_height: 1088  fps: 29.97
2005-04-23 09:51:40.377 AVFD: Looking for decoder for 2
2005-04-23 09:51:40.378 AVFD: Opening Stream #1: codec id 86020
2005-04-23 09:51:40.378 AVFD: Looking for decoder for 86020
2005-04-23 09:51:40.380 Estimated bitrate = 19284
2005-04-23 09:51:40.384 Position map filled from DB to: 69
2005-04-23 09:51:40.384 SyncPositionMap prerecorded, from DB: 70 entries
2005-04-23 09:51:40.384 SyncPositionMap, new totframes: 1035, new length: 34, posMap size: 70
2005-04-23 09:51:40.384 Position map found
2005-04-23 09:51:40.384 AvFormatDecoder: Successfully opened decoder for file: /home/mythtv/recordings/1005_2004092000_2004092001.nuv. novideo(0)
2005-04-23 09:51:40.407 Opening audio device 'default'.
2005-04-23 09:51:40.425 VideoOutputXv()
2005-04-23 09:51:40.432 Over/underscan. V: 0, H: 0, XOff: 0, YOff: 0
2005-04-23 09:51:40.440 XvMC version: 1.0
2005-04-23 09:51:40.447 @ j=0 Looking for flag[s]: XvInputMask
2005-04-23 09:51:40.447 Adaptor: 0 has flag[s]: XvInputMask XvImageMask
2005-04-23 09:51:40.447 XvMCSurfaceTypes::find(w 1920, h 1, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p= 105, 1050 =p, port, surfNum)
2005-04-23 09:51:40.451 Trying XvMC port 105
2005-04-23 09:51:40.453 Adaptor: 1 has flag[s]: XvInputMask XvImageMask
2005-04-23 09:51:40.454 XvMCSurfaceTypes::find(w 1920, h 1, chroma 1, vld 1, idct 

Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 10:09 -0400, Doug Larrick wrote:

 Things are not so good for XvMC for me.
 
 The biggest problem I'm having is that it seems the video card (nVidia
 MX-440, driver 7174) is not reset properly sometimes, because I'll go to
 play a recording (any recording) and get just the blue screen with a
 burst of sound every second or so.  Log file (--verbose playback) for a
 playback when that's happeining is attached (novideo.log).

Those AddInheritence messages indicate that a frame was added to
the available queue before the frames depending on it had released
by avlib so that we knew about them. 


 When it's in
 that state, Xv shows just a blue screen as well, so it's probably
 related to whatever driver bug triggers that problem.  But I can't even
 run through my entire list of test clips  w/o triggering this using
 XvMC, so something's up there.

I'll be committing a patch, probably sometime this afternoon, to
fix a problem in XVideo teardown that Issac discovered last night.
This may be causing your problem. Let me know if it fixes/doesn't
fix the problem.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMCmerge)

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 14:44 +0100, John Pullan wrote:
 On 23/04/05, Mark Spieth [EMAIL PROTECTED] wrote:
  just noticed a compile problem with XVMC disabled and daniels new stuff
  not sure about this qt issue but it seems as if the
  #ifdef USING_XVMC
  class XvMCHostCheckBox : virtual public HostCheckBox
 Should this control even be in settings.* ? shouldn't it be more local
 to where its' needed, it does seem very specific ?

It's actually not needed at all.

I'm compiling a more generic solution right now... 
In 10 more minutes or so I'll test :)

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Bruce Markey
[EMAIL PROTECTED] wrote:

Changes committed by danielk on Sat Apr 23 02:04:33 2005
Modified Files:
   in mythtv/libs/libmyth:
DisplayRes.cpp DisplayRes.h settings.h 
   in mythtv/libs/libmythtv:
NuppelVideoPlayer.cpp NuppelVideoPlayer.h avformatdecoder.cpp 
avformatdecoder.h decoderbase.h libmythtv.pro tv_play.cpp 
videobuffers.cpp videobuffers.h videoout_directfb.cpp 
videoout_directfb.h videoout_dx.cpp videoout_dx.h 
videoout_null.cpp videoout_null.h videoout_quartz.cpp 
videoout_quartz.h videoout_xv.cpp videoout_xv.h 
videooutbase.cpp videooutbase.h 
   in mythtv/programs/mythfrontend:
globalsettings.cpp 
Removed Files:
   in mythtv/libs/libmythtv:
videoout_xvmc.cpp videoout_xvmc.h 
Log Message:

NOTE: I recommend a make distclean...
This is the fabled XV/XvMC merge patch. Of course, it does a 
little more than that.
cd libmyth  make -f Makefile
/home/bjm/m/test/mythtv/libs/libmyth
make[2]: Entering directory `/home/bjm/m/test/mythtv/libs/libmyth'
g++ -c -pipe -march=pentiumpro -mmmx -Wall -W -O3 -Wall -Wno-switch -fomit-frame-pointer 
-D_REENTRANT -DPIC -fPIC  -DMMX -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64-DPREFIX=\/usr/local\ -DUSING_OSS -DUSE_ALSA 
-DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -I/usr/share/qt3/mkspecs/default -I. 
-I/usr/local/include -I../libmythsamplerate -I../libmythsoundtouch -I../.. 
-I/usr/include/qt3 -o moc_settings.o moc_settings.cpp
moc_settings.cpp:1827: error: syntax error before `::' token
moc_settings.cpp:1832: error: syntax error before `::' token
moc_settings.cpp:1833: error: `XvMCHostCheckBox' was not declared in this scope
moc_settings.cpp:1833: error: parse error before `::' token
moc_settings.cpp:1836: error: syntax error before `::' token
moc_settings.cpp:1844: error: syntax error before `::' token
moc_settings.cpp:1855: error: syntax error before `::' token
moc_settings.cpp:1867: error: ISO C++ forbids declaration of `metaObj' with no
  type
moc_settings.cpp:1875: error: invalid conversion from `QMetaObject*' to `int'
moc_settings.cpp:1876: error: syntax error before `.' token
moc_settings.cpp:1880: error: syntax error before `::' token
moc_settings.cpp:1887: error: syntax error before `::' token
moc_settings.cpp:1897: error: syntax error before `::' token
moc_settings.cpp:1903: error: syntax error before `::' token
moc_settings.cpp:1908: error: syntax error before `::' token
moc_settings.cpp:1833: warning: `QMetaObjectCleanUp
  cleanUp_XvMCHostCheckBox(...)' declared `static' but never defined
make[2]: *** [moc_settings.o] Error 1
make[2]: Leaving directory `/home/bjm/m/test/mythtv/libs/libmyth'
make[1]: *** [sub-libmyth] Error 2
make[1]: Leaving directory `/home/bjm/m/test/mythtv/libs'
make: *** [sub-libs] Error 2
: [EMAIL PROTECTED] ;
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Isaac Richards
On Saturday 23 April 2005 12:05 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by danielk on Sat Apr 23 16:03:53 2005

 Modified Files:
in mythtv/libs/libmythtv:
 videobuffers.cpp videobuffers.h videoout_xv.cpp
 Log Message:

 This disables frame locking unless we are doing XvMC output. This
 should help XVideo performance about 5%-10%. If you could marginally
 play something 24 hours ago, you might be able to again...

This is better, but still quite a bit slower than before.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 15:04 -0400, Isaac Richards wrote:
  This disables frame locking unless we are doing XvMC output. This
  should help XVideo performance about 5%-10%. If you could marginally
  play something 24 hours ago, you might be able to again...
 
 This is better, but still quite a bit slower than before.

I'll have to profile then. I'm not sure what is eating up the cycles
if it's not frame locking.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Isaac Richards
On Saturday 23 April 2005 02:15 pm, [EMAIL PROTECTED] wrote:
 This adds three macros to util-x11.cpp, X11L, X11U, and X11S()
 Which lock, and unlock x11_lock, and run enclosed code within
 a X11L and X11U, resp. This should be used around bare X11 calls,
 to serialize all access to the X11 server. No other locks should
 be acquired inside the X11L and X11U construct, or inside a X11S
 macro.

 I've gone though a few classes to implement this locking protocol,
 but I still haven't gone through everything.

This seems to have cleared up my hardlocks + occasional segfault on startup 
when using opengl vsync.  However, there seems to be something slightly off - 
I'm getting occasional video corruption (just a frame or two) when using Xv.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 15:17 -0400, Isaac Richards wrote:

 This seems to have cleared up my hardlocks + occasional segfault on startup 
 when using opengl vsync.
Good.

 However, there seems to be something slightly off - 
 I'm getting occasional video corruption (just a frame or two) when using Xv.
Hmm, try it now, I just added some more locking.

I'm now getting some wackyness in XvMC, that wasn't there this morning.
But it is only in NTSC, not in HDTV playback. It's sometimes showing
two frames at once, and it looks like it is sometimes showing the next
frame early. Perhaps something in vsync got messed up by the locking.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Ivor Hewitt
On Saturday 23 Apr 2005 20:34, Daniel Kristjansson wrote:

 I'm now getting some wackyness in XvMC, that wasn't there this morning.
 But it is only in NTSC, not in HDTV playback. It's sometimes showing
 two frames at once, and it looks like it is sometimes showing the next
 frame early. Perhaps something in vsync got messed up by the locking.

Are you seeing the problem I had where the lower part of the image is mpeg 
blocks from another frame?
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 20:58 +0100, Ivor Hewitt wrote:
 On Saturday 23 Apr 2005 20:34, Daniel Kristjansson wrote:
 
  I'm now getting some wackyness in XvMC, that wasn't there this morning.
  But it is only in NTSC, not in HDTV playback. It's sometimes showing
  two frames at once, and it looks like it is sometimes showing the next
  frame early. Perhaps something in vsync got messed up by the locking.
 
 Are you seeing the problem I had where the lower part of the image is mpeg 
 blocks from another frame?
Yes, but I fixed it by not getting the X11 lock for
glXWaitVideoSyncSGI().

I can't google anything that says this is safe though.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Doug Larrick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Kristjansson wrote:
 Yes, but I fixed it by not getting the X11 lock for
 glXWaitVideoSyncSGI().
 
 I can't google anything that says this is safe though.

IIRC the OpenGL context includes the thread that created it, and it's
only safe to use that context from that thread.  glXMakeCurrent takes
care of serialization.  I'm just talking from recollection though.

- -Doug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCaq0Qf1/38+/zqMERAqKdAJwL6kDR4FbrMZxScdQicxG3zjNNfACfUfHU
NQbZVCmUYgp3ilo9r/ceIEU=
=D6p0
-END PGP SIGNATURE-
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Kyle Rose
 Are you seeing the problem I had where the lower part of the image is mpeg 
 blocks from another frame?

FWIW, I am seeing this now as well.

Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Chris Pinkham
 On Sat, 2005-04-23 at 20:58 +0100, Ivor Hewitt wrote:
  Are you seeing the problem I had where the lower part of the image is mpeg 
  blocks from another frame?

 Yes, but I fixed it by not getting the X11 lock for
 glXWaitVideoSyncSGI().

Just as another point of reference and not another me too, I am seeing
this with CVS from prior to when your big patch was applied.  I don't
think I've seen it in normal playback mode, but it does appear for me
quite often in edit mode.

Do you think the bug you fixed was present even before your patch or
is there possibly something else going on?

-- 
Chris

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread J. Donavan Stanley
Daniel Kristjansson wrote:

I'm now getting some wackyness in XvMC, that wasn't there this morning.
But it is only in NTSC, not in HDTV playback. It's sometimes showing
two frames at once, and it looks like it is sometimes showing the next
frame early. Perhaps something in vsync got messed up by the locking.

  


http://www.jdonavan.net/mythfrontend.log.bz2 is a log of my attempt to
watch live (HD)TV on my dev box.  When first tuning to a station the
video quality is horrid until it settles down a bit.  It's still not
smooth and perfect but at least it's not spastic.  Attempting to change
the channel results in mythfrontend locking up.

Turning off XvMC and enabling libmpeg2 results in perfect smooth video.
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 16:33 -0400, Chris Pinkham wrote:
 Just as another point of reference and not another me too, I am seeing
 this with CVS from prior to when your big patch was applied.  I don't
 think I've seen it in normal playback mode, but it does appear for me
 quite often in edit mode.
 
 Do you think the bug you fixed was present even before your patch or
 is there possibly something else going on?

Something else. This bug was due to the avlib thread being blocked
too long by a long held lock in OpenGLVideoSync::WaitForFrame(),
this lock wasn't there until a few hours ago.

It may be something related though. Perhaps DrawSlices is being
blocked from running by something else in the edit mode?

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Daniel Kristjansson
On Sat, 2005-04-23 at 16:16 -0400, Doug Larrick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Daniel Kristjansson wrote:
  Yes, but I fixed it by not getting the X11 lock for
  glXWaitVideoSyncSGI().
  
  I can't google anything that says this is safe though.
 
 IIRC the OpenGL context includes the thread that created it, and it's
 only safe to use that context from that thread.  glXMakeCurrent takes
 care of serialization.  I'm just talking from recollection though.
 
 - -Doug

I would generally assume this to be the case with OpenGL, it is 
usually happy running in a separate thread from the event/X11
thread. But turning off OpenGL VSync prevents the lockups that
people have been seeing, so something is causing problems in
there.

Perhaps we need some X11S(glXWaitGL()) or X11S(glXWaitX()) calls
to synchronize with X?

-- Daniel


___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-23 Thread Geoffrey Kruse
On Apr 23, 2005, at 12:16 PM, Daniel Kristjansson wrote:
On Sat, 2005-04-23 at 15:04 -0400, Isaac Richards wrote:
This disables frame locking unless we are doing XvMC output. This
should help XVideo performance about 5%-10%. If you could marginally
play something 24 hours ago, you might be able to again...
This is better, but still quite a bit slower than before.
I'll have to profile then. I'm not sure what is eating up the cycles
if it's not frame locking.

I just thought I would also mention I am having trouble with this patch 
on my system using xv.  Before this was applied to cvs I was able to 
watch recordings with about 40% cpu being used.  After this patch, 
there is no free cpu and the playback is choppy.  Seems something is 
using a lot of extra cycles.  Also when fast forwarding, the osd goes 
away and comes back on a regular interval, about every 5 seconds or so. 
 It only appears for about a second and then it is gone for 5.  When 
first staring playback, the screen is blue and stays blue for several 
seconds before the video starts  Please let me know if there is any 
additional info I can provide you to help you troubleshoot these 
issues.  I have attached a log from the frontend, but I didn't see 
anything too useful in there.

Geoff
[EMAIL PROTECTED]:~$ mythfrontend --verbose playback
mythfrontend: cannot connect to X server 
[EMAIL PROTECTED]:~$ export DISPLAY=:0
[EMAIL PROTECTED]:~$ mythfrontend --verbose playback
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/sqldrivers/libqsqlmysql-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
2005-04-23 19:46:04.105 New DB connection, total: 1
Total desktop width=640, height=480, numscreens=1
2005-04-23 19:46:04.176 Using screen 0, 640x480 at 0,0
2005-04-23 19:46:04.187 mythfrontend version: 0.18.20050423-1 www.mythtv.org
2005-04-23 19:46:04.188 Enabled verbose msgs : important general playback
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/imageformats/libqjpeg-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/imageformats/libqmng-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/imageformats/libqjpeg-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/imageformats/libqmng-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
QSettings::sync: filename is null/empty
2005-04-23 19:46:06.321 max_width: 640 max_height: 480
2005-04-23 19:46:06.571 Switching to square mode (Titivillus)
QSettings::sync: filename is null/empty
Conflict in /usr/lib/qt3/plugins/sqldrivers/libqsqlmysql-non-mt.so:
  Plugin uses single threaded Qt library!
QSettings::sync: filename is null/empty
2005-04-23 19:46:07.780 New DB connection, total: 2
2005-04-23 19:46:07.950 Registering Internal as a media playback plugin.
Unable to initialize plugin 'mythbookmarkmanager'.
Unable to initialize plugin 'mythdvd'.
Unable to initialize plugin 'mythmfe'.
Unable to initialize plugin 'mythmovietime'.
Unable to initialize plugin 'mythmusic'.
Unable to initialize plugin 'mythnews'.
Test Popup Version Failed 
Unable to initialize plugin 'mythphone'.
Unable to initialize plugin 'mythvideo'.
Unable to initialize plugin 'mythweather'.
2005-04-23 19:46:10.992 Connecting to backend server: 10.0.1.3:6543 (try 1 of 5)
2005-04-23 19:46:11.000 Using protocol version 15
2005-04-23 19:46:11.066 Mediamonitor: Adding /dev/fd0
2005-04-23 19:46:11.068 Mediamonitor: Adding /dev/cdrom
2005-04-23 19:46:11.069 Starting media monitor.
2005-04-23 19:46:24.502 All Programs
2005-04-23 19:46:33.994 detectInterlace(Detect Scan, Detect Scan, 29.97, 480) 
-Interlaced Scan
2005-04-23 19:46:33.995 Interlaced: Interlaced Scan  video_height: 480  fps: 
29.97
2005-04-23 19:46:34.040 Estimated bitrate = 0
2005-04-23 19:46:34.107 VideoOutputNull()
2005-04-23 19:46:34.190 Image size. dispxoff 0, dispyoff: 0, dispwoff: 0, 
disphoff: 0
2005-04-23 19:46:34.191 Image size. imgx 0, imgy: 0, imgw: 352, imgh: 480
2005-04-23 19:46:34.195 waiting for prebuffer... 0
2005-04-23 19:46:34.331 ~VideoOutputNull()
2005-04-23 19:46:38.514 Disable DPMS
2005-04-23 19:46:38.658 detectInterlace(Detect Scan, Detect Scan, 29.97, 480) 

[mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMCmerge)

2005-04-22 Thread Mark Spieth
just noticed a compile problem with XVMC disabled and daniels new stuff
not sure about this qt issue but it seems as if the
#ifdef USING_XVMC
class XvMCHostCheckBox : virtual public HostCheckBox
...
#endif
is not being replicated through the moc_settings.cpp generation.
any ideas? or does this class have to be extracted into another file say
xvmc_settings.h and then conditionalised in the make system?
cheers
mark

g++ -c -pipe -march=pentium3 -DVBI_NC -Wall -W -O3 -Wall -Wno-switch -fomit-
frame-pointer -g -D_REENTRANT -DPIC -fPIC  -DNEWSCRYPT -DVBI_NC -DMMX -DUSIN
G_IVTV -DUSING_DVB -DUSING_DVB_EIT -DUSING_XRANDR -D_GNU_SOURCE -D_FILE_OFFS
ET_BITS=64 -DPREFIX=\/usr\ -DUSING_OSS -DUSE_ALSA -DUSE_JOYSTICK_MENU -DUS
E_LIRC -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -I/usr/share/qt3/mkspec
s/default -I. -I/usr/include -I/usr/include -I../libmythsamplerate -I../libm
ythsoundtouch -I../.. -I/usr/include/qt3 -o moc_settings.o moc_settings.cpp
moc_settings.cpp:1827: error: syntax error before `::' token
moc_settings.cpp:1832: error: syntax error before `::' token
moc_settings.cpp:1833: error: `XvMCHostCheckBox' was not declared in this
scope
moc_settings.cpp:1833: error: parse error before `::' token
moc_settings.cpp:1836: error: syntax error before `::' token
moc_settings.cpp:1844: error: syntax error before `::' token
moc_settings.cpp:1855: error: syntax error before `::' token
moc_settings.cpp:1867: error: ISO C++ forbids declaration of `metaObj' with
no
   type
moc_settings.cpp:1875: error: invalid conversion from `QMetaObject*' to
`int'
moc_settings.cpp:1876: error: syntax error before `.' token
moc_settings.cpp:1880: error: syntax error before `::' token
moc_settings.cpp:1887: error: syntax error before `::' token
moc_settings.cpp:1897: error: syntax error before `::' token
moc_settings.cpp:1903: error: syntax error before `::' token
moc_settings.cpp:1908: error: syntax error before `::' token
moc_settings.cpp:1833: warning: `QMetaObjectCleanUp
   cleanUp_XvMCHostCheckBox(...)' declared `static' but never defined

- Original Message - 
From: Daniel Kristjansson [EMAIL PROTECTED]
To: Development of mythtv mythtv-dev@mythtv.org
Sent: Saturday, April 23, 2005 12:23 PM
Subject: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output
XV/XvMCmerge)


 On Sat, 2005-04-23 at 02:05 +, [EMAIL PROTECTED] wrote:

 --
--
  Changes committed by danielk on Sat Apr 23 02:04:33 2005
 snip
  Log Message:
 
  NOTE: I recommend a make distclean...

 I just wanted to add that I expect there to be a few problems as this
 gets wider testing.

 Bring it on.


 And, also I want to thank some patch testers...
   Andy Polling, Ivor Hewitt, Robert Johnston, Angel Li,
   John Roberts, Will Dorman, and Josh Logan.

 I know there are more of you, but I got more e-mail from some of
 these testers then I got from my SO in the last two weeks. ;-)

 -- Daniel








___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Risto Treksler
On Wednesday 20 April 2005 08:39 pm, Chris Pinkham wrote:
 Better grab a cup of coffee if you plan on reading this. :)

yeah, that's what i should have said :)

actually, nevermind a cup
better bring the whole pot over

 They are both wrong
 in saying that the next block appears to be a commercial block
 because there is nothing that indicates that, we haven't even looked at
 the score for the block.  The only thing we're basing the fact that
 the next block is part of a commercial break or not is the length.

true

 Something more correct is probably:

 QString(Ignoring blocks starting at frame %1 
 with length %2, length is under minimum 
 comm block length of %3 seconds.)
 .arg(curBlock)
 .arg(fbp-start - breakStart)
 .arg(commDetectMinCommBreakLength));


this looks fine
it makes a lot of sense when viewing the debug output


- Revert the change (temporarily for now) that made strict mode
  require blank frames to be totally blank so frames with logos on them
  but otherwise blank would not be detected as so in strict mode.
 The reason I reverted this temporarily is because myself and others have
 been seeing worse flagging since this went in.  I have had several people
 tell me that the flagging is worse for them in 0.18 than it was in 0.17
 and after I put this patch in, my flagging got worse as well. 

ok, i'll take your word for it
for me it got so good that i could actually turn autoskip on
for the first time without regretting it and turning it back off
:))

 It partially 
 has to do with the stations you record.  I record a lot of shows off of CBS

Agreed,
CBS is probably the only station that worked better overall (b4 the patch)

 here in the U.S. and CBS has an annoying habit of wanting me to see their
 logo as much as possible, so they display it on every blank frame and then
 turn it off when the commercial starts. 

aha!
so b4 marking otherwise blank frames with logos in them as blank.
it should be possible to check the some frames before and after them,
to make sure that a logo IS NOT in it 
for example check
(60th  65th  70th frame before) || (60th  65th  70th frame after) 
the blank frame with a logo in it.

i know this is all done in a frame by frame loop, so something more creative 
is needed. 

one could simply mark frames as BLANK or as BLANK_WITH_LOGO on the first pass. 
and later reflag BLANK_WITH_LOGO  as BLANK if that BLANK_WITH_LOGO  has 
frames with _no logo_ either shortly before it or shortly after it.

here's another bonus - this way you can kind of determine whether this is the 
start or the end of a break

who would have thought that leaving the logo up could in some way lead to more 
accurate detection :)

 I'm not 100% sure if this strictness is necessary if logo detection is
 working well enough, but I know 100% for sure that it breaks commercial
 detection with strict turned ON for lots of people here in the U.S. that
 record shows off certain stations.

i agree that it breaks,(fails to detect entire commercials) for some stations
but it does make it a lot better(100% correct) for a lot more stations
because it eliminates false positives for them.

i guess it  depends on whether most your shows use true blanks or not
I thought not using true blanks was an extreme rarity, and i was wrong :(

 I've hesitated in the past to add user-configurable settings to control
  the flagging criteria, but am thinking that this is one that I want to
 add.

i saw it go in, thanks
i saw that it's still an undocumented one, which sounds right,
because this setting is only necessary until a better way to handle
blanks with logos can be conjured up.

 I know, better is subjuective

 Right, that's the thing, you see the recordings you make, but since I've
 been working on this code for a couple years now and people know that,
 someone (or someones) usually let me know if it's taken a turn for the
 worse.  I'm not opposed to putting it back in, but I think it will be as
 an option as you also propose later in your post.

i guess i was overly optimistic
once i saw what a difference it made for me

 Here's some objective stats from 50 recordings on my drive (long):
 --for the 10% shows that leave it up at the start of a commercial--
 -it still detects 100% correctly 99% of the time
  since the end is all that matters for a skip
-it just won't auto skip
-you have to hit 'z'(once or twice)

 'Twice' means it wasn't 100%. :)

sometimes it's been 'twice'
because i have been too lazy to increase the number of seconds that you can be 
away from the beginning of a commercial, and still have the  z key skip to 
the end of the commercial

 I don't understand how you could have 100% accurate detection if the
 stations really leave the logo up?  

this is if they leave it up for the start of a commercial
but have true blanks for end of the commercial

 Since the blocks are based off of 

[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Daniel Kristjansson
On Thu, 2005-04-21 at 22:40 +, [EMAIL PROTECTED] wrote:
 
 Changes committed by danielk on Thu Apr 21 22:38:03 2005
 
 Modified Files:
in mythplugins/mythweb/themes/Default:
 theme.php 
 Log Message:
 
 Derek Atkins' no break space patch. This replaces some regular spaces
 with non-breaking spaces in the category menu, preventing a menu item
 from spanning multiple lines. -- dtk

Just wanted to correct this, it was Petter Gundersen's patch,
not Derek Atkins' patch that I applied.

-- 
Daniel Kristjansson [EMAIL PROTECTED]

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Isaac Richards
On Thursday 21 April 2005 06:10 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by danielk on Thu Apr 21 22:09:04 2005

 Modified Files:
in mythtv/libs/libmyth:
 mythdialogs.cpp
in mythtv/programs/mythfrontend:
 globalsettings.cpp
 Log Message:

 This adds Neil Whelchel [EMAIL PROTECTED] User Functions
 functionality. I cleaned it up a bit and allowed for four functions
 in the UI rather than two. -- dtk

 ---

I don't really see the need to reimplement irxevent, window manager 
keybindings, etc.

Isaac

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Isaac Richards
On Thursday 21 April 2005 08:01 pm, Daniel Kristjansson wrote:
 Which convinced me. It is a fairly small bit of code.

 Also a lot of people are using minimal window managers, or not
 using window managers at all with MythTV.

 This lets you set up a user function once for both keyboard and
 remote control use.

 Finally, by setting this within MythTV it is easier to tell
 people how to do it.

 Anyway, if you want me to back it out, no problem.

I was pretty sure I had already rejected the patch once. =)  There's just 
plenty of better ways externally to myth to handle something like this, and 
there's too much stuff in the settings UI already.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Neil Whelchel
On Thu, 21 Apr 2005, Isaac Richards wrote:

 On Thursday 21 April 2005 06:10 pm, [EMAIL PROTECTED] wrote:
  ---
 - Changes committed by danielk on Thu Apr 21 22:09:04 2005
 
  Modified Files:
 in mythtv/libs/libmyth:
  mythdialogs.cpp
 in mythtv/programs/mythfrontend:
  globalsettings.cpp
  Log Message:
 
  This adds Neil Whelchel [EMAIL PROTECTED] User Functions
  functionality. I cleaned it up a bit and allowed for four functions
  in the UI rather than two. -- dtk
 
  ---

 I don't really see the need to reimplement irxevent, window manager
 keybindings, etc.

 Isaac

 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hello,
I disagree..
As I said in one of my previous messages, there are a few of out here that
do not use lirc. Some of us use a remote like the Firefly or the X10, or
something that directly sends key press events, so this makes it a bit
tough to use irxevent or something similar.
Also, I am running mythtv completely embedded from ROM (the front end), so
there is really not much room for a window manager, not to mention that on
a dedicated unit (not embedded), I have always had better success by
ditching the wm, so this route is not for everyone either.
So, where is the project going anyway.. Is this aiming to be an app
that runs on a desktop machine along with other programs, or is it heading
for the ability to be used as a stand alone media system (possibly
embedded), as well as a desktop application.
If the answer is the latter, Mythtv needs to have everything within the
gui to configure a machine from zero, and I might point out that I have
patched it to do as much at the moment. (All it needed was a way to
configure where it mounts the shared media directory and the Ethernet
configuration, and I can do every bit of front end configuration that I
will ever need to do to make an embedded frontend.)

So, if the goal is to make Myth into a desktop application, sure leave it
out, long with a dozen other configuration options that can be adjusted
with other outside applications... Then make a plugin that has all of the
rest of the configuration stuff to make it into a stand alone application
for those of us that want to embed. ;)

Just a few thoughts...
 -Neil Whelchel-
First Light Internet Services
760 366-0145
- We don't do Window$, that's what the janitor is for -

Bubble Memory, n.:
A derogatory term, usually referring to a person's
intelligence.  See also vacuum tube.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Isaac Richards
On Thursday 21 April 2005 10:06 pm, Neil Whelchel wrote:
 Hello,
 I disagree..
 As I said in one of my previous messages, there are a few of out here that
 do not use lirc. Some of us use a remote like the Firefly or the X10, or
 something that directly sends key press events, so this makes it a bit
 tough to use irxevent or something similar.

So write another program that listens for events.  It's not hard.

 Also, I am running mythtv completely embedded from ROM (the front end), so
 there is really not much room for a window manager, not to mention that on
 a dedicated unit (not embedded), I have always had better success by
 ditching the wm, so this route is not for everyone either.

A window manager is required for full operation of myth.  If you're not using 
one, you've got bugs.  irxevent's tiny - there's no reason to believe that a 
similar app for whatever input device you wanted would be any larger.

 So, where is the project going anyway.. Is this aiming to be an app
 that runs on a desktop machine along with other programs, or is it heading
 for the ability to be used as a stand alone media system (possibly
 embedded), as well as a desktop application.

A standalone media system doesn't need to reimplement every single app under 
the sun inside of it.  And if it _were_ completely stanalone, you'd not need 
to run external applications from a keypress, hmm?

 If the answer is the latter, Mythtv needs to have everything within the
 gui to configure a machine from zero, and I might point out that I have
 patched it to do as much at the moment. (All it needed was a way to
 configure where it mounts the shared media directory and the Ethernet
 configuration, and I can do every bit of front end configuration that I
 will ever need to do to make an embedded frontend.)

Or within a separate UI that's part of the OS install.

This patch isn't going in to Myth.  Neither is a shell, or gcc, or the kernel.  
Stuff that's better implemented elsewhere, is, well, better implemented 
elsewhere.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Neil Whelchel
On Thu, 21 Apr 2005, Isaac Richards wrote:

 A standalone media system doesn't need to reimplement every single app under
 the sun inside of it.  And if it _were_ completely stanalone, you'd not need
 to run external applications from a keypress, hmm?

Very good point, one I have dealt with myself, and yes, it is was
completely standalone, I agree (which is the goal in my case, a very good
argument to not include the patch), however the patch is an 'attempt' to
deal with some custom configurations such as Crestron. To be more
specific, the roms will be built always with Myth, and optionally with
one other application from a choice of many. And the real point here is
that I need the outside app to NOT run when viewing TV.
How about meeting this one in the middle, simply bind a couple of keys to
execute fixed named files (can be a link to what is needed).


  If the answer is the latter, Mythtv needs to have everything within the
  gui to configure a machine from zero, and I might point out that I have
  patched it to do as much at the moment. (All it needed was a way to
  configure where it mounts the shared media directory and the Ethernet
  configuration, and I can do every bit of front end configuration that I
  will ever need to do to make an embedded frontend.)

 Or within a separate UI that's part of the OS install.

True, however if there is no OS install, in the case of an ebedded system,
you still need a way to set the IP configuration and the path the the
fileserver. Sure, you could do this with an external app, (bind a key to
it with any of our discussed methods), but it is not very clean, as it is
now not in the configuration menu. Maybe there should be an app that
watches for the availability of the fileserver, and open a configuration
app over the top of Myth if there is a failure, but there is not much that
has to be added to Myth to make it workable.


 This patch isn't going in to Myth.  Neither is a shell, or gcc, or the kernel.
 Stuff that's better implemented elsewhere, is, well, better implemented
 elsewhere.

I respect your opinion, however I think that you should consider a
configuration module for those of us that wish to do all of the
(embedded) system configuration from within Myth using a remote control.
If so, I will get busy on one...

BTW... The embedded system I am using is an NEC plasma TV. I managed to
get Myth running on the signal processor board (Arm 9 based). (I hope this
explains my limited hardware resources and lack of a GUI OS install) ;)

-Neil Whelchel-
First Light Internet Services
760 366-0145
- We don't do Window$, that's what the janitor is for -

Bubble Memory, n.:
A derogatory term, usually referring to a person's
intelligence.  See also vacuum tube.

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Damion de Soto
Also, I am running mythtv completely embedded from ROM (the front end), so
there is really not much room for a window manager, not to mention that on
a dedicated unit (not embedded), I have always had better success by
ditching the wm, so this route is not for everyone either.

A window manager is required for full operation of myth.  If you're not using 
one, you've got bugs.  
Why is this?
I was wondering this a few weeks ago, when i discovered it was
my window manager that was causing me troubles trying to get
myth to start ogle to watch DVDs (fvwm2 wasn't centering ogle's window on the screen, 
and I could see the mythtv border along one edge).

I don't know any of the technicalities of it, but it would seem
better to me to just let mythtv run full screen directly without requiring
a window manager, no?

--
~~~
Damion de Soto - Software Engineer  email: [EMAIL PROTECTED]
SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809
 | Custom Embedded Solutions  fax: +61 7 3891 3630
 | and Security Appliancesweb: http://www.snapgear.com
~~~
 ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread MagicITX
On 4/21/05, Damion de Soto [EMAIL PROTECTED] wrote:
 Also, I am running mythtv completely embedded from ROM (the front end), so
 there is really not much room for a window manager, not to mention that on
 a dedicated unit (not embedded), I have always had better success by
 ditching the wm, so this route is not for everyone either.
 
 
  A window manager is required for full operation of myth.  If you're not 
  using
  one, you've got bugs.
 Why is this?
 I was wondering this a few weeks ago, when i discovered it was
 my window manager that was causing me troubles trying to get
 myth to start ogle to watch DVDs (fvwm2 wasn't centering ogle's window on the 
 screen,
 and I could see the mythtv border along one edge).
 
 I don't know any of the technicalities of it, but it would seem
 better to me to just let mythtv run full screen directly without requiring
 a window manager, no?
 
 --
 ~~~
 Damion de Soto - Software Engineer  email: [EMAIL PROTECTED]
 SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809
   | Custom Embedded Solutions  fax: +61 7 3891 3630
   | and Security Appliancesweb: http://www.snapgear.com
 ~~~
   ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---
 
 
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 
 
 

We run ours without a window manager.  Instructions are in Part 6 of
our MythTV tutorial if you're interested.  The only down side we've
found is an occassional key focus problem.

-- 
Tim
www.magicitx.com
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Isaac Richards
On Thursday 21 April 2005 11:54 pm, Damion de Soto wrote:
 Why is this?
 I was wondering this a few weeks ago, when i discovered it was
 my window manager that was causing me troubles trying to get
 myth to start ogle to watch DVDs (fvwm2 wasn't centering ogle's window on
 the screen, and I could see the mythtv border along one edge).

 I don't know any of the technicalities of it, but it would seem
 better to me to just let mythtv run full screen directly without requiring
 a window manager, no?

If you just run mythtv, mythmusic, mythweather, mythnews, mythgallery, (and 
maybe) mythbrowser + mythphone, you're fine without one.  If you use mythdvd 
or mythvideo or mythgame, however, you start launching external applications, 
which means other windows on screen.  This basically requires a window 
manager to take care of key focus issues.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread Isaac Richards
On Thursday 21 April 2005 11:49 pm, Neil Whelchel wrote:
 On Thu, 21 Apr 2005, Isaac Richards wrote:
  A standalone media system doesn't need to reimplement every single app
  under the sun inside of it.  And if it _were_ completely stanalone, you'd
  not need to run external applications from a keypress, hmm?

 Very good point, one I have dealt with myself, and yes, it is was
 completely standalone, I agree (which is the goal in my case, a very good
 argument to not include the patch), however the patch is an 'attempt' to
 deal with some custom configurations such as Crestron. To be more
 specific, the roms will be built always with Myth, and optionally with
 one other application from a choice of many. And the real point here is
 that I need the outside app to NOT run when viewing TV.
 How about meeting this one in the middle, simply bind a couple of keys to
 execute fixed named files (can be a link to what is needed).

No.  That's rather hacky - why isn't the outside app integrated into at least 
the menu?  Actually, I think you may be able to do most everything you want 
wrt the key binding thing with a separate plugin (your system config one, 
perhaps) + a couple generic jumppoints that could be configured to do 
whatever.  That's something I could live with - simple, uses already present 
functionality, no changes to the core, etc.

   If the answer is the latter, Mythtv needs to have everything within the
   gui to configure a machine from zero, and I might point out that I have
   patched it to do as much at the moment. (All it needed was a way to
   configure where it mounts the shared media directory and the Ethernet
   configuration, and I can do every bit of front end configuration that I
   will ever need to do to make an embedded frontend.)
 
  Or within a separate UI that's part of the OS install.

 True, however if there is no OS install, in the case of an ebedded system,
 you still need a way to set the IP configuration and the path the the
 fileserver. Sure, you could do this with an external app, (bind a key to
 it with any of our discussed methods), but it is not very clean, as it is
 now not in the configuration menu. Maybe there should be an app that
 watches for the availability of the fileserver, and open a configuration
 app over the top of Myth if there is a failure, but there is not much that
 has to be added to Myth to make it workable.

I would think that you'd want that info (where to mount, ip address) to be 
always be obtained automatically, without the need to configure anything.

  This patch isn't going in to Myth.  Neither is a shell, or gcc, or the
  kernel. Stuff that's better implemented elsewhere, is, well, better
  implemented elsewhere.

 I respect your opinion, however I think that you should consider a
 configuration module for those of us that wish to do all of the
 (embedded) system configuration from within Myth using a remote control.
 If so, I will get busy on one...

Sure, as long as it's a plugin.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-21 Thread MagicITX
On 4/21/05, Isaac Richards [EMAIL PROTECTED] wrote:
 On Thursday 21 April 2005 11:54 pm, Damion de Soto wrote:
  Why is this?
  I was wondering this a few weeks ago, when i discovered it was
  my window manager that was causing me troubles trying to get
  myth to start ogle to watch DVDs (fvwm2 wasn't centering ogle's window on
  the screen, and I could see the mythtv border along one edge).
 
  I don't know any of the technicalities of it, but it would seem
  better to me to just let mythtv run full screen directly without requiring
  a window manager, no?
 
 If you just run mythtv, mythmusic, mythweather, mythnews, mythgallery, (and
 maybe) mythbrowser + mythphone, you're fine without one.  If you use mythdvd
 or mythvideo or mythgame, however, you start launching external applications,
 which means other windows on screen.  This basically requires a window
 manager to take care of key focus issues.
 
 Isaac
 ___
 mythtv-dev mailing list
 mythtv-dev@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
 

We did have some early trouble with the key focus issue playing dvd's
as you mention.  That went away when we switched to videolan client
for dvd and video playback.  I'm not sure why that made a difference. 
Maybe because of the way vlc splits the control interface from the
video display.  Anyway we seldom have any trouble.

-- 
Tim
www.magicitx.com
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-20 Thread Chris Pinkham
 This patch is not quite correct. The committed patch was:

Thanks.  This is committed now.  I missed the space and thought I was
saving myself some time by just adding the escaped quotes manually
instead of saving your patch to a file and running patch on that. :(

I did it the hard way this time so it should be correct. :)

-- 
Chris

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-20 Thread Risto Treksler


[EMAIL PROTECTED] said:

 
 Changes committed by cpinkham on Wed Apr 20 04:44:05 2005
 * Commmercial Flagging changes:

 - Rearrange some debugging statements.
you changed

block %1 with length %2, which would put 
comm block length under minimum of 
%3 seconds.)

but this is actually correct for that part of the code
trust me, i tested it, there's a reason i worded it that way.

that is part of the bugfix for flagging tiny commercials
that were getting closed off if the length was less than max length
without a checking against min length 

iirc, it has to refer to the length of the previous block, not the next. 

   - Revert the change (temporarily for now) that made strict mode require
 blank frames to be totally blank so frames with logos on them but
 otherwise blank would not be detected as so in strict mode.

:((
I know you said temporarily, 
but requiring blank frames to be totally blank works tons better (imho)


I know, better is subjuective
Here's some objective stats from 50 recordings on my drive (long):

--for the 80% of shows that don't leave the logo up--
-it (0.18 with strict mode) detects 100% correctly 99% of the time!!!

--for the 10% shows that leave it up at the start of a commercial--
-it still detects 100% correctly 99% of the time
 since the end is all that matters for a skip
   -it just won't auto skip 
   -you have to hit 'z'(once or twice)

--for the other 10% of shows that leave it up at the end-- 
-it detects 100% correctly only 5% of the time
-it comes back too early 90% of the time which is good
 (because of the scenechange and logo detection routines)

the over all rate of false positives is --1%--
ie 10% of the time in 10% of shows


On the other hand,
Not requiring blank frames to be totally blank gets lots of false positives

My observed stats:
--for the 80% of shows that don't leave the logo up--
-it (current cvs) detects 100% correctly only 5% of the time!
-it detects 90% correctly 95% of the time

--for the 20% shows that leave it up 
-it still detects 100% correctly only 5% of the time!!!
-it detects 80% correctly 95% of the time

rate of false positives is harder to estimate,
i'd say 20% of the time in 90% of shows, so --18%--


ie according to my empirical observations
(it's pretty sad how much time i spent on this - easily 8 hours)
it's 18 times worse to allow logos on blank frames


There has to be another way to deal with the few shows that leave the logo up.
Breaking comm detection for 90% of the shows, 
because 10% leave the logo up at the end of the commercial, 
doesn't make sense to me.


temporarily, maybe this should have its own setting
instead of depending on the strict setting

something like
blankCanHaveLogo =
  gContext-GetNumSetting(BlankCanHaveLogo, 0);

BUT
===
there's got to be a way to do a check for blank frames that have logos on them
to see if the 60th frame before or after it, also has a logo on it, otherwise
don't mark it as blank.

you see what i mean?

that way only blank frames that really border on commercials get marked as 
blank.




___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-20 Thread Chris Pinkham
Better grab a cup of coffee if you plan on reading this. :)

[EMAIL PROTECTED] said:

 
 Changes committed by cpinkham on Wed Apr 20 04:44:05 2005
 * Commmercial Flagging changes:

 - Rearrange some debugging statements.
you changed

block %1 with length %2, which would put 
comm block length under minimum of 
%3 seconds.)

I changed it from this:

 QString(Ignoring what appears to be commercial 
 block %1 with length %2, which would put 
 comm block length under minimum of 
 %3 seconds.)
 .arg(curBlock)
 .arg(fbp-start - breakStart)
 .arg(commDetectMinCommBreakLength));

To this:

QString(Ignoring what appears to be commercial
 block at frame %1 with length %2, 
length of %3 frames would put comm 
block length under min of %4 seconds.)
.arg(breakStart)
.arg(fbp-start - breakStart)
.arg(fbp-frames)
.arg(commDetectMinCommBreakLength));


Now that I look at it again, I think neither is entirely
accurate.  The 'if' statement that this is part of the 'else' of
is this:

if ((breakStart = 0) 
((fbp-end - breakStart)  (MAX_COMM_BREAK_LENGTH * fps)))
{
if (((fbp-start - breakStart)  (MIN_COMM_BREAK_LENGTH * fps)) || 
(lastEnd == 0))
{

The message is part of the else from that 2nd if.  They are both wrong
in saying that the next block appears to be a commercial block
because there is nothing that indicates that, we haven't even looked at
the score for the block.  The only thing we're basing the fact that
the next block is part of a commercial break or not is the length.

Something more correct is probably:

QString(Ignoring blocks starting at frame %1 
with length %2, length is under minimum 
comm block length of %3 seconds.)
.arg(curBlock)
.arg(fbp-start - breakStart)
.arg(commDetectMinCommBreakLength));

Or something referencing the fact that that the next block would put us
over the max length but without that block we are under the minimum length.

but this is actually correct for that part of the code
trust me, i tested it, there's a reason i worded it that way.

It was the wording saying that the next block appeared to be a commercial
block that threw me and then I neglected to take that part out when I
cut-and-pasted part of that text from another section.

that is part of the bugfix for flagging tiny commercials
that were getting closed off if the length was less than max length
without a checking against min length 

iirc, it has to refer to the length of the previous block, not the next. 

Right, so it should be reworded to reflect the next block is too big to
be a commercial whether it looks like one or not because that is what we're
really checking.

   - Revert the change (temporarily for now) that made strict mode require
 blank frames to be totally blank so frames with logos on them but
 otherwise blank would not be detected as so in strict mode.

:((
I know you said temporarily, 
but requiring blank frames to be totally blank works tons better (imho)

The reason I reverted this temporarily is because myself and others have
been seeing worse flagging since this went in.  I have had several people
tell me that the flagging is worse for them in 0.18 than it was in 0.17
and after I put this patch in, my flagging got worse as well.  It partially
has to do with the stations you record.  I record a lot of shows off of CBS
here in the U.S. and CBS has an annoying habit of wanting me to see their
logo as much as possible, so they display it on every blank frame and then
turn it off when the commercial starts.  As soon as the commercial ends,
and the show is about to begin, the next blank frame has their logo on it.
The WAF went way down and I can't have that. :)  I didn't want to have
people taking a step backwards so I reverted this change temporarily until
something else can be done.

I'm not 100% sure if this strictness is necessary if logo detection is working
well enough, but I know 100% for sure that it breaks commercial detection 
with strict turned ON for lots of people here in the U.S. that record
shows off certain stations.

I've hesitated in the past to add user-configurable settings to control
 the flagging criteria, but am thinking that this is one that I want to add.

I know, better is subjuective

Right, that's the thing, you see the recordings you make, but since I've
been working on this code for a couple years now and people know that, 
someone (or someones) usually let me know if it's taken a turn for the
worse.  I'm not opposed to putting it back in, but I think it will be as
an option as you also propose later in your post.

Here's some objective stats from 50 recordings on my 

[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-19 Thread Robert Tsai
This patch is not quite correct. The committed patch was:

% cvs diff -r1.3 -r1.4 programs/mythbackend/httpstatus.cpp
Index: programs/mythbackend/httpstatus.cpp
===
RCS file: /var/lib/mythcvs/mythtv/programs/mythbackend/httpstatus.cpp,v
retrieving revision 1.3
retrieving revision 1.4
diff -r1.3 -r1.4
577,578c577,578
 statusColor = class=\jobqueued;
 jobColor = class=\jobqueued;
---
 statusColor = class=\jobqueued\;
 jobColor = class=\jobqueued\;

The patch inadvertently omitted another leading space in front of class= (the
current generated HTML is fontclass= instead of font class=. A patch
against current CVS head follows:

Index: programs/mythbackend/httpstatus.cpp
===
RCS file: /var/lib/mythcvs/mythtv/programs/mythbackend/httpstatus.cpp,v
retrieving revision 1.4
diff -u -r1.4 httpstatus.cpp
--- programs/mythbackend/httpstatus.cpp 18 Apr 2005 03:15:03 -  1.4
+++ programs/mythbackend/httpstatus.cpp 20 Apr 2005 01:32:56 -
@@ -574,8 +574,8 @@
 break;

 default:
-statusColor = class=\jobqueued\;
-jobColor = class=\jobqueued\;
+statusColor =  class=\jobqueued\;
+jobColor =  class=\jobqueued\;
 break;
 }

On Mon, Apr 18, 2005 at 03:20:03AM +, [EMAIL PROTECTED] wrote:
 
 Changes committed by cpinkham on Mon Apr 18 03:15:03 2005
 
 Modified Files:
in mythtv/programs/mythbackend:
 httpstatus.cpp 
 Log Message:
 
 
 * Bugfix for html typo in status webpage.  Submitted by Robert Tsai on
   the -dev list.
 
 
 Changes committed by cpinkham on Mon Apr 18 03:17:02 2005
   on branch: release-0-18-fixes
 
 Modified Files:
in mythtv/programs/mythbackend:
 httpstatus.cpp 
 Log Message:
 
 
 * Bugfix for html typo in status webpage.  Submitted by Robert Tsai on
   the -dev list.
 
 

 ___
 mythtv-commits mailing list
 mythtv-commits@mythtv.org
 http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits


--Rob
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-14 Thread Daniel Kristjansson
On Thu, 2005-04-14 at 00:25 -0400, Isaac Richards wrote:
 On Wednesday 13 April 2005 11:45 pm, [EMAIL PROTECTED] wrote:
  ---
 - Changes committed by danielk on Thu Apr 14 03:43:05 2005
  Removes 7 lines of cruft in tv_play.cpp. --dtk
 Hmm.. Are you sure this is ok?  I think the main window resize to max (ie., 
 1920x1080 or whatnot) has to occur before the child window is created, else 
 it can trigger a driver bug that can cut off playback at hd resolutions.

Pretty sure, I think the problem was really with resizing myWindow and
expecting mainWindow to grow. Since the player bounds are at the maximum
size possible, that shouldn't be a problem.

I'll try to contact the original reporter of the bug and get them
to test this solution today. If I don't get a response before you
do the release, I've attached a patch that adds back the mainWindow
resize.
Index: libs/libmythtv/tv_play.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/tv_play.cpp,v
retrieving revision 1.260
diff -u -r1.260 tv_play.cpp
--- libs/libmythtv/tv_play.cpp	14 Apr 2005 03:43:05 -	1.260
+++ libs/libmythtv/tv_play.cpp	14 Apr 2005 12:35:04 -
@@ -363,7 +363,12 @@
 // bit of a hack, but it's ok if the window is too
 // big in fullscreen mode
 if (fullscreen)
+{
 player_bounds.setSize(QSize(maxWidth, maxHeight));
+
+// resize possibly avoids a bug on some systems
+mainWindow-resize(player_bounds.size());
+}
 }
 
 // player window sizing
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Isaac Richards
On Wednesday 13 April 2005 08:50 pm, [EMAIL PROTECTED] wrote:
 ---
- Changes committed by danielk on Thu Apr 14 00:48:17 2005

 Modified Files:
in mythtv/libs/libmythtv:
 tv_play.cpp
 Log Message:

 This adds some work-around code for the fluxbox window manager. You need
 to uncomment an appropriately named define at the top of tv_play for the
 hack to take effect.

I don't think this is acceptable for a release, really.  The old code didn't 
have this problem, so things should either be fixed, or reverted.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Isaac Richards
On Wednesday 13 April 2005 09:52 pm, Isaac Richards wrote:
 On Wednesday 13 April 2005 08:50 pm, [EMAIL PROTECTED] wrote:
  -
 -- - Changes committed by danielk on Thu Apr 14 00:48:17 2005
 
  Modified Files:
 in mythtv/libs/libmythtv:
  tv_play.cpp
  Log Message:
 
  This adds some work-around code for the fluxbox window manager. You need
  to uncomment an appropriately named define at the top of tv_play for the
  hack to take effect.

 I don't think this is acceptable for a release, really.  The old code
 didn't have this problem, so things should either be fixed, or reverted.

Yeah, the code in tv_play doesn't make sense to me.
- You're always resizing/moving the mainWindow, even when it's not necessary.
- a MythDialog is a child of the main window, so it can't have separate flags.
- Why the change in the destructor?
- Why's myWindow being resized multiple times?

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Daniel Kristjansson
On Wed, 2005-04-13 at 21:52 -0400, Isaac Richards wrote:
 On Wednesday 13 April 2005 08:50 pm, [EMAIL PROTECTED] wrote:
  This adds some work-around code for the fluxbox window manager. You need
  to uncomment an appropriately named define at the top of tv_play for the
  hack to take effect.
 I don't think this is acceptable for a release, really.  The old code didn't 
 have this problem, so things should either be fixed, or reverted.

Ok, I'm a little sleep deprived at the moment, but I made a put a better
fix in CVS. Basically the problem is that fluxbox lies to Qt about
window locations when running in borderless mode. In the old code this
only led to an off-by-one error once, and then we placed the window in
the same off-by-one location over and over again. In the new code we
allow the user to move the window and we don't reset that location
everytime they return from watching a video. This is much nicer for
desktop operation, but it also exposes us to the off by one error every
time that we save and restore the window location.

The new hack snaps the MythTV window back to its original location
if it's within 3 pixels of the original location in both the x and y
coordinates.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Isaac Richards
On Wednesday 13 April 2005 10:57 pm, Daniel Kristjansson wrote:
 On Wed, 2005-04-13 at 21:52 -0400, Isaac Richards wrote:
  On Wednesday 13 April 2005 08:50 pm, [EMAIL PROTECTED] wrote:
   This adds some work-around code for the fluxbox window manager. You
   need to uncomment an appropriately named define at the top of tv_play
   for the hack to take effect.
 
  I don't think this is acceptable for a release, really.  The old code
  didn't have this problem, so things should either be fixed, or reverted.

 Ok, I'm a little sleep deprived at the moment, but I made a put a better
 fix in CVS. Basically the problem is that fluxbox lies to Qt about
 window locations when running in borderless mode. In the old code this
 only led to an off-by-one error once, and then we placed the window in
 the same off-by-one location over and over again. In the new code we
 allow the user to move the window and we don't reset that location
 everytime they return from watching a video. This is much nicer for
 desktop operation, but it also exposes us to the off by one error every
 time that we save and restore the window location.

 The new hack snaps the MythTV window back to its original location
 if it's within 3 pixels of the original location in both the x and y
 coordinates.

Ok, that's reasonable for now. =)

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Daniel Kristjansson
On Wed, 2005-04-13 at 22:51 -0400, Isaac Richards wrote:
 On Wednesday 13 April 2005 09:52 pm, Isaac Richards wrote:
  On Wednesday 13 April 2005 08:50 pm, [EMAIL PROTECTED] wrote:
   -
  -- - Changes committed by danielk on Thu Apr 14 00:48:17 2005
  
   Modified Files:
  in mythtv/libs/libmythtv:
   tv_play.cpp
   Log Message:

 - Why the change in the destructor?
Suggested by Qt people as the code that would work in various
environments. Basically window decorations are added after show()
in X so for some window managers you need to call it then move(),
to get something in the right location.

 - You're always resizing/moving the mainWindow, even when it's not necessary.
 - a MythDialog is a child of the main window, so it can't have separate flags.
 - Why's myWindow being resized multiple times?
Cruft? It's hard to tell because I've added much of it to get this to
work on with other people's software stack.

The flags are just sleep deprivation, fluxbox wasn't getting rid of a 1
pixel black window border. I tried the flags because I forgot it was a
child window. I'll make a cleanup pass.

-- Daniel

___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread Isaac Richards
On Wednesday 13 April 2005 11:13 pm, Daniel Kristjansson wrote:
 Suggested by Qt people as the code that would work in various
 environments. Basically window decorations are added after show()
 in X so for some window managers you need to call it then move(),
 to get something in the right location.

The url you referenced in the commit is really only for the _initial_ window 
position.

 I'll make a cleanup pass.

Thanks.

Isaac
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-13 Thread cythrault
On 4/13/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 Changes committed by danielk on Thu Apr 14 02:43:52 2005
 
 Modified Files:
in mythtv/libs/libmythtv:
 tv_play.cpp
 Log Message:
 
 A fix for fluxbox wierdness that does not require a compile time define.

Woo-hoo!

Works fine now. ;)

Thanks

-- 
cyth
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Re: [mythtv] Re: [mythtv-commits] mythtv commits

2005-04-10 Thread Allan Stirling
Daniel Kristjansson wrote:
On Sat, 2005-04-09 at 15:17 -0400, Isaac Richards wrote:
Also, Taylor Jacob's been reporting a deadlock (on the irc channel) with -v 
all turned on, that doesn't happen without the verbose reporting..  He hasn't 
gotten a backtrace that I'm aware of, but... think it may be the mutex lock 
in the verbose macro?
This is possible. If you call a function that depends on another thread 
within
a verbose macro bad things can happen.
I've been wondering this for a while. Why are we not leveraging existing 
logging (syslog) methods? I know the answer is probably yet another 
dependancy, as well as additional overhead. However, it has the 
possibilty of simplifying the code as far as I can see (well, after the 
initial pain, of course)... Just an idea. I'm not sure if or when I'll 
get time to do it, if anyone likes the idea.

Cheers,
Allan.
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


[mythtv] Re: [mythtv-commits] mythtv commits

2005-04-09 Thread Bruce Markey
[EMAIL PROTECTED] wrote:

Changes committed by cpinkham on Sat Apr  9 09:46:31 2005
Modified Files:
   in mythtv/libs/libmythtv:
recordingprofile.cpp 
Log Message:

* Get rid of the Auto Transcode checkbox on the LiveTV recording profiles.
When I schedule recordings, I may use any of the four profiles
including the one with the label Live TV (I use a lower res
with higher bitrate which also works well woth things like sports).
Perhaps what you're after is not honoring the Auto Transcode when
recording to a ringbuffer?
-- bjm
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


  1   2   >