Re: [mythtv] RE: [mythtv-commits] mythtv commits
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits (analog scan breaks build?)
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
Re: [mythtv] RE: [mythtv-commits] mythtv commits
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
[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
Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits (improperly dropping DVB channels)
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)
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)
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
RE: [mythtv] RE: [mythtv-commits] mythtv commits
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
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
[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
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
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)
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)
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
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits (mythmusic FFTW breaks build?)
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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.]
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
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
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
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
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits (Video Output XV/XvMC merge)
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)
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)
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)
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)
-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)
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)
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
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
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
-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
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
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
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
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
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
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)
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
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
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
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
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
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
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
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
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
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
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
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
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
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
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Sat, 2005-04-09 at 09:49 -0700, Bruce Markey wrote: [EMAIL PROTECTED] wrote: Puts MythTV's Visual class in a MythTV namespace so that it does not conflict with X's Visual. Add's MythDeque a specialization of the STL deque class that presents an interface similar to the Qt queue, code using it to follow. Daniel, could you try compiling mythmusic? I think there are still some problems related to this change. Yep, I'm recompiling with a fix in place at the moment. The problem was that I added MythTV visual.h header to output.h but output is being exported to plugins and visual is not. I'll commit soon. -- 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
On Sat, 2005-04-09 at 15:17 -0400, Isaac Richards wrote:
On Saturday 09 April 2005 01:45 pm, [EMAIL PROTECTED] wrote:
---
- Changes committed by danielk on Sat Apr 9 17:44:17 2005
Modified Files:
in mythtv:
configure
Log Message:
Disabled processor specific optimizations for pentiumpro compatible
processors, and instead optimize all of those for the pentiumpro. You can
re-enable processor specific optimizations with the --enable-proc-opt
flag.
Thanks for making this change - I do agree that a option to enable the more
agressive opts should cut down a bit on random problem reports for the
release..
No problem, J. Donovan Stanley wasn't even getting proper backtraces..
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.
int A1()
{
wait_for_thread_B_to_finish();
return val_A;
}
void A2()
{
VERBOSE(VB_IMPORTANT, A1: A1());
}
void B()
{
while(1)
{
//do something
val_A = 1;
VERBOSE(VB_IMPORTANT, val_A: val_A);
wakeup_thread_A;
}
}
The A's are running in one thread and the B in another.
A2 acquires the verbose lock, then waits on B, which
tries to get the verbose lock, but can't. Now we have
a deadlock.
There are three solutions as I see it:
1/ Construct the verbose string completely outside of the verbose lock.
The problem with this is it makes the verbose macro take longer to
execute.
2/ Examine every VERBOSE macro with redirects in it and either check if
it is calling a blocking function, or just transform it to use
QString().arg().arg().. Problem: lots of developer time..
3/ Disable verbose locking in release builds.
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Saturday 09 April 2005 03:30 pm, Daniel Kristjansson wrote: There are three solutions as I see it: 1/ Construct the verbose string completely outside of the verbose lock. The problem with this is it makes the verbose macro take longer to execute. Right, would: ostringstream blah; blah dtime args; mutex.lock(); cout blah endl; mutex.unlock(); Really take that much extra time? 2/ Examine every VERBOSE macro with redirects in it and either check if it is calling a blocking function, or just transform it to use QString().arg().arg().. Problem: lots of developer time.. Lots and lots.. So, not going to happen. =) 3/ Disable verbose locking in release builds. This would work, too. 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
Daniel Kristjansson wrote: On Sat, 2005-04-09 at 09:49 -0700, Bruce Markey wrote: [EMAIL PROTECTED] wrote: Puts MythTV's Visual class in a MythTV namespace so that it does not conflict with X's Visual. Add's MythDeque a specialization of the STL deque class that presents an interface similar to the Qt queue, code using it to follow. Daniel, could you try compiling mythmusic? I think there are still some problems related to this change. Yep, I'm recompiling with a fix in place at the moment. The problem was that I added MythTV visual.h header to output.h but output is being exported to plugins and visual is not. I'll commit soon. 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
On Sat, 2005-04-09 at 15:40 -0400, Isaac Richards wrote: On Saturday 09 April 2005 03:30 pm, Daniel Kristjansson wrote: There are three solutions as I see it: 1/ Construct the verbose string completely outside of the verbose lock. The problem with this is it makes the verbose macro take longer to execute. Right, would: ostringstream blah; blah dtime args; mutex.lock(); cout blah endl; mutex.unlock(); Really take that much extra time? It is noticable, but only if you turn on -v playback 3/ Disable verbose locking in release builds. This would work, too. For now I've checked in a fix that uses ostringstream for release builds, and locked args in debug builds. The assumption is that people don't normally run with -v all on the release build, so the extra overhead isn't noticable. And if you are running a debug build it is easy enough to track down the cause of a VERBOSE deadlock. -- 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
On Fri, 2005-04-08 at 09:07 -0400, Robert Tsai wrote: non-XRANDR builds are broken. My simple patch is below: +#if defined(USING_XRANDR) || defined(CONFIG_DARWIN) const vectorDisplayResScreen scr = GetVideoModes(); if (scr.size()) addChild(new VideoModeSettings()); +#endif /* USING_XRANDR || CONFIG_DARWIN */ Can you give me the output of the gcc instantiation that fails? GetVideoModes() should work whether you have DisplayRes support or not. -- 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
On Fri, Apr 08, 2005 at 01:35:39PM -0400, Daniel Kristjansson wrote: On Fri, 2005-04-08 at 09:07 -0400, Robert Tsai wrote: non-XRANDR builds are broken. My simple patch is below: +#if defined(USING_XRANDR) || defined(CONFIG_DARWIN) const vectorDisplayResScreen scr = GetVideoModes(); if (scr.size()) addChild(new VideoModeSettings()); +#endif /* USING_XRANDR || CONFIG_DARWIN */ Can you give me the output of the gcc instantiation that fails? GetVideoModes() should work whether you have DisplayRes support or not. The compile issue is with the VideoModeSettings (which is protected by #ifdef), not the call to GetVideoModes. I patched around GetVideoModes just because scr was otherwise unused (AFAICT). Anyway: g++ -c -pipe -march=k8 -Wall -W -O3 -Wall -Wno-switch \ -fomit-frame-pointer -D_REENTRANT -DMMX -DUSING_OPENGL_VSYNC \ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DPREFIX=\/usr/local\ \ -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED \ -I/usr/share/qt3/mkspecs/default \ -I. -I../.. -I../../libs/libmythtv -I../../libs \ -I../../libs/libmyth -I/usr/local/include -I/usr/include/qt3 \ -o globalsettings.o globalsettings.cpp globalsettings.cpp: In constructor `AppearanceSettings::AppearanceSettings()': globalsettings.cpp:2994: error: `VideoModeSettings' has not been declared make: *** [globalsettings.o] Error 1 --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
[EMAIL PROTECTED] wrote: Hi, Just to let you know; Since I updated my tree with that patch, recordings are all at 0 bytes. The LOCK occurs without problem. EIT data is parsed and added to the DB... -v all does not show any outstanding errors. Is there anything I can do to to help test this or am I the only one with that issue? Do you have a DEC2000-t or some other device with a hw mpeg decoder? If you do, try enabling the hw decoder option in the setup (under advanced in capture cards IIRC). ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
Hi Jesper, Indeed, I have a nexus-s -- saa7146 based: lspci -v: Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 32, IRQ 28 Memory at fe103000 (32-bit, non-prefetchable) Enabling the switch you suggested, did it. I'm sorry I did not think of it prior to my post. I am not able to look at the quality of the recording until I get home tonight tho. I just want to check. Have I took the right path by sending this info the the dev list? I don't want to offend devs. ;) Thanks! cyth On Tue, 29 Mar 2005 18:12:30 +0200, Jesper Sörensen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hi, Just to let you know; Since I updated my tree with that patch, recordings are all at 0 bytes. The LOCK occurs without problem. EIT data is parsed and added to the DB... -v all does not show any outstanding errors. Is there anything I can do to to help test this or am I the only one with that issue? Do you have a DEC2000-t or some other device with a hw mpeg decoder? If you do, try enabling the hw decoder option in the setup (under advanced in capture cards IIRC). ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Monday 28 March 2005 01:25 pm, David Engel wrote: On Mon, Mar 28, 2005 at 11:16:21AM -0500, Isaac Richards wrote: On Monday 28 March 2005 11:10 am, [EMAIL PROTECTED] wrote: Added more support to prevent overlapping OSDs. Things are mostly hard coded to only allow one OSD to be active at a time. A better long term solution would be to extend the osd.xml format to allow theme designers to specify which OSDs can/can't be active together. But I rather liked how it would work with the older, more transparent OSD themes if you hit the info button and then paused it. :( It'd overlap (with info being on top, due to the layering information in the theme), then info would fade out nicely just leaving the pause stuff. It took quite a bit of time to get that working just right. I use a variation of the Isthmus OSD where status and program_info compter for the same screen area and allowing them both to be active looks ugly. Hence my comment about allowing this via osd.xml. Pick a syntax to allow it, and I'll try to add it. There's already stuff in there to draw in a specific order. That should be enough, if the OSD theme is designed properly. I'd rather think that you should be fixing the theme, instead of disallowing stuff to overlap like this. 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
On Fri, 2005-03-25 at 20:07 -0500, J. Donavan Stanley wrote: [EMAIL PROTECTED] wrote: Changes committed by danielk on Fri Mar 25 04:04:17 2005 Modified Files: in mythtv: configure Log Message: Adds Celeron to list of detected CPU's in ./configure -- dtk Why optimize for Pentium2 instead of Pentium4 in the celeron case? I don't know how you tell a P2 Celeron from a P3 Celeron, or from a P4 Celeron, with that processor string... I left in the trailing CPU, hoping we get some other Celeron reports that clarify the ambiguity. -- 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
Daniel Kristjansson wrote: On Fri, 2005-03-25 at 20:07 -0500, J. Donavan Stanley wrote: [EMAIL PROTECTED] wrote: Changes committed by danielk on Fri Mar 25 04:04:17 2005 Modified Files: in mythtv: configure Log Message: Adds Celeron to list of detected CPU's in ./configure -- dtk Why optimize for Pentium2 instead of Pentium4 in the celeron case? I don't know how you tell a P2 Celeron from a P3 Celeron, or from a P4 Celeron, with that processor string... I left in the trailing CPU, hoping we get some other Celeron reports that clarify the ambiguity. That's the same string I get on my dev box.. Perhaps a check for ghz as well? How many P2 / P3 celerons were in the ghz? ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Fri, 2005-03-25 at 08:51 -0500, Daniel Kristjansson wrote: On Fri, 2005-03-25 at 20:07 -0500, J. Donavan Stanley wrote: Why optimize for Pentium2 instead of Pentium4 in the celeron case? I don't know how you tell a P2 Celeron from a P3 Celeron, or from a P4 Celeron, with that processor string... I left in the trailing CPU, hoping we get some other Celeron reports that clarify the ambiguity. I just checked in an updated Celeron test. If the processor flags are valid, ./configure uses them to determine if the Celeron is a p4, p3, or p2 based CPU. If the flags are not present it still displays the CPU detection warning. -- 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
I'm not sure if you have resolved the celeron issue, but here is /proc/cpuinfo from a PIV-core celeron: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Celeron(R) CPU 2.80GHz stepping: 3 cpu MHz : 349.140 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cidbogomips: 5537.79 On Fri, 2005-25-03 at 09:17 -0500, Daniel Kristjansson wrote: On Fri, 2005-03-25 at 08:51 -0500, Daniel Kristjansson wrote: On Fri, 2005-03-25 at 20:07 -0500, J. Donavan Stanley wrote: Why optimize for Pentium2 instead of Pentium4 in the celeron case? I don't know how you tell a P2 Celeron from a P3 Celeron, or from a P4 Celeron, with that processor string... I left in the trailing CPU, hoping we get some other Celeron reports that clarify the ambiguity. I just checked in an updated Celeron test. If the processor flags are valid, ./configure uses them to determine if the Celeron is a p4, p3, or p2 based CPU. If the flags are not present it still displays the CPU detection warning. -- Daniel ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev -- Micah F. Galizia [EMAIL PROTECTED] The mark of an immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one. --W. Stekel signature.asc Description: This is a digitally signed message part ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Mon, 21 Mar 2005, Isaac Richards wrote: ]On Monday 21 March 2005 01:20 pm, [EMAIL PROTECTED] wrote: ] --- ]- Changes committed by danielk on Mon Mar 21 18:17:44 2005 ] This is the new configure script I've been working on for a while. The ]Two things: There's no uname -p on debian unstable. The DVB stuff in the ]2.6.11 kernel headers and newer works for the include dir location, so that ]check can probably be removed. Someone with debian already convinced me to only use uname -p if it gave me a good value, but I forgot to redirect the error when it is not supported. I didn't know this was fixed in 2.6.11, I've changed this to a warning to use 2.6.11 or later and made the kernel's dvb headers the default. -- 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
On Monday 21 March 2005 02:19 pm, Daniel Thor Kristjansson wrote: Someone with debian already convinced me to only use uname -p if it gave me a good value, but I forgot to redirect the error when it is not supported. I didn't know this was fixed in 2.6.11, I've changed this to a warning to use 2.6.11 or later and made the kernel's dvb headers the default. Thanks. =) I know the dvb includes work with 2.6.12-rc1, as I was trying to get my air2pc working with QAM over the weekend. No luck for me, though - bunch of unc errors on anything it manages to get a lock on. 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
On Jan 30, 2005, at 1:20 PM, Bruce Markey wrote: globalsettings.cpp:1446: error: type `class HostImageSelect' is not a direct or virtual base of `ThemeSelector' Skipped a file in my commit, should work now. Sorry about that. - Jer ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
Jeremiah Morris wrote: On Jan 30, 2005, at 1:20 PM, Bruce Markey wrote: globalsettings.cpp:1446: error: type `class HostImageSelect' is not a direct or virtual base of `ThemeSelector' Skipped a file in my commit, should work now. Sorry about that. Verified. 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
On Thursday 27 January 2005 03:51 pm, Bruce Markey wrote: We are not destroying potentially useful data for no reason other than some clean up which is not time critical. How's it potentially useful? I don't like having completely unused junk in the database. 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
We are not destroying potentially useful data for no reason other than some clean up which is not time critical. How's it potentially useful? Mainly for rolling back, but I can imagine that some DVB countries may not work yet with the new code. The dtv_multiplex table could be populated by a script that scans the unused dvb_channel/pids/sat tables? I don't like having completely unused junk in the database. Agreed, but as long as it is targetted for removal some time in the future, the impact is minimal? -- Nigel Pearson, [EMAIL PROTECTED] | Now the world has gone to bed, Telstra BID, Sydney, Australia | Darkness won't engulf my head, Office: 8255 4222Fax: 8255 3153 | I can see by infrared, Mobile: 0408 664435 Home: 9792 6998 | How I hate the night. -Marvin ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
Nigel Pearson wrote: ... Agreed, but as long as it is targetted for removal some time in the future, the impact is minimal? Not knowing what issues may come up, I think it would be good for the users who try to upgrade to 0.17 to still have access to the data in these tables. If they are stable and go on to CVS after the release then there there should be no issue with dropping the unused tables IMO. -- 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
On Thu, Jan 27, 2005 at 03:23:36PM -0800, Bruce Markey wrote: Nigel Pearson wrote: Agreed, but as long as it is targetted for removal some time in the future, the impact is minimal? Not knowing what issues may come up, I think it would be good for the users who try to upgrade to 0.17 to still have access to the data in these tables. If they are stable and go on to CVS after the release then there there should be no issue with dropping the unused tables IMO. I suggest the guideline that database items be obsolete for at least two releases before they get removed. For example, anything that was last used in 0.15, can't be removed until 0.17 is released. David -- David Engel [EMAIL PROTECTED] ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Thursday 27 January 2005 09:02 pm, David Engel wrote: On Thu, Jan 27, 2005 at 03:23:36PM -0800, Bruce Markey wrote: Nigel Pearson wrote: Agreed, but as long as it is targetted for removal some time in the future, the impact is minimal? Not knowing what issues may come up, I think it would be good for the users who try to upgrade to 0.17 to still have access to the data in these tables. If they are stable and go on to CVS after the release then there there should be no issue with dropping the unused tables IMO. I suggest the guideline that database items be obsolete for at least two releases before they get removed. For example, anything that was last used in 0.15, can't be removed until 0.17 is released. How do you handle data whose meaning changes, though? 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
I suggest the guideline that database items be obsolete for at least two releases before they get removed. For example, anything that was last used in 0.15, can't be removed until 0.17 is released. How do you handle data whose meaning changes, though? In a perfect world, there would be a new table, column, or value to represent the new meaning(s). In the MythTV dev world, I guess we have to hope that developers minimise this? -- Nigel Pearson, [EMAIL PROTECTED] | Reality is that which, Telstra BID, Sydney, Australia | when you stop believing Office: 8255 4222Fax: 8255 3153 | in it, doesn't go away. Mobile: 0408 664435 Home: 9792 6998 | Philip K. Dick - 'Valis' ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Thu, Jan 27, 2005 at 09:17:07PM -0500, Isaac Richards wrote: On Thursday 27 January 2005 09:02 pm, David Engel wrote: I suggest the guideline that database items be obsolete for at least two releases before they get removed. For example, anything that was last used in 0.15, can't be removed until 0.17 is released. How do you handle data whose meaning changes, though? The best you can do is try to make your changes backward compatible. That's not always possible and is why I used guideline instead of rule. As has been said before, the only safe way to be able to downgrade after an upgrade is to backup your database. David -- David Engel [EMAIL PROTECTED] ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits (find daily/weekly)
On Mon, Jan 24, 2005 at 11:59:19PM -0800, Chris Petersen wrote: record.type values of 7 and 8, what I call record and suppress, are used more often, or even exclusively -- is recordoverride deprecated?). recordoverride has been obsolete for quite some time now. this information out? Is there a better way to do this WHOLE thing? Maybe I should just check each show against QUERY_GETALLPENDING? Sounds like that might be the best way to do things, since it leaves all of that checking code in the backend (one place, less chance of mythweb calculating something incorrectly) Use QUERY_GETALLPENDING. Look at how it's done in ProgramList::FromScheduler and ProgramList::FromProgram. David -- David Engel [EMAIL PROTECTED] ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
Isaac Richards [EMAIL PROTECTED] writes: I'd _like_ to keep compatability with 3.1. But this is a major piece of missing functionality that we can't emulate on that version, and if more of the db queries are converted over to prepare/bindValue, then people using 3.1 will have no info to send to the list if a query isn't working.. There's two options here - lose compatability with 3.1, or keep it along with a secondary message (say, 'Your version of Qt is too old to print out a valid error message here. Please upgrade.' or something) in the DBError function. Thoughts? As a Qt-3.1 user I'm willing to live with the secondary message in the DBError. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Sunday 16 January 2005 10:27 am, Jeremiah Morris wrote: On 16 Jan 2005, at 4:55 AM, Ivor Hewitt wrote: I was a little surprised to see the QT3.1 workaround applied to CVS without discussion actually. The last two times it came up, I didn't see any response from the developers either way. When the patch was originally proposed, Isaac said he wanted 3.1 compatibility and asked David Hardeman to change the patch. Because David was issuing several versions of that patch at the time, I assumed that the checkin with executedQuery() was unintentional. Since the last official word I found was pro-3.1, I assumed that was still the policy. I don't really care either way, I just don't want us to claim 3.1 compatibility while we're breaking compilation for 3.1. I'd _like_ to keep compatability with 3.1. But this is a major piece of missing functionality that we can't emulate on that version, and if more of the db queries are converted over to prepare/bindValue, then people using 3.1 will have no info to send to the list if a query isn't working.. There's two options here - lose compatability with 3.1, or keep it along with a secondary message (say, 'Your version of Qt is too old to print out a valid error message here. Please upgrade.' or something) in the DBError function. Thoughts? 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
On 17 Jan 2005, at 5:26 PM, Isaac Richards wrote: But this is a major piece of missing functionality that we can't emulate on that version Wow, that's the part that I couldn't believe until my fourth time or so through the docs. I thought there had to be some less convenient, but still possible, way to get the values back out, but I was wrong. There's two options here - lose compatability with 3.1, or keep it along with a secondary message (say, 'Your version of Qt is too old to print out a valid error message here. Please upgrade.' or something) in the DBError function. Thoughts? A third option would be to create our own subclass that remembers the placeholders and emulates executedQuery. It's possible, but it's a lot of work to cope with a flaw that Trolltech has already fixed. If you wanted 3.1 compatibility badly enough, I'd suggest that route. Since it's already difficult to make sure everything works on 3.1 (recent months have shown that), and nobody has come forward with a good defense for it, I'll have to throw my hat into the leave 3.1 behind ring as well. - Jer ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On Sunday 16 Jan 2005 04:12, Isaac Richards wrote: On Saturday 15 January 2005 09:46 pm, Jeremiah Morris wrote: On 15 Jan 2005, at 9:27 PM, Isaac Richards wrote: These changes are incorrect, please revert them. The error messages would be printed out with the placeholders, instead of with the actual values. Are we dropping Qt 3.1 compatibility then? That's what it means to revert the changes without another fix in place. I'm thinking yes. It's a pain having to support a 2 year old version of a library that none of the developers use. Let the lazy people upgrade. I was a little surprised to see the QT3.1 workaround applied to CVS without discussion actually. Also I don't see the need to keep CVS constantly compatible with QT3.1 either. If someone's running CVS code they ought to be able to spot and fix QT errors. When it becomes time for a release then a decision could be made whether the changes that depended on a newer QT were worth breaking compatibility. -- Ivor Hewitt. http://www.ivor.it - tech | http://www.ivor.org - hedge ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On 15 Jan 2005, at 11:12 PM, Isaac Richards wrote: I'm thinking yes. It's a pain having to support a 2 year old version of a library that none of the developers use. OK. I still think that the executedQuery should go into the DBError routine, instead of being written a dozen times in programinfo.cpp; I'll check in the DBError change (sans 3.1 compatibility) if you agree, or I'll revert the changes if the DBError won't work for some reason. - Jer ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On 16 Jan 2005, at 4:55 AM, Ivor Hewitt wrote: I was a little surprised to see the QT3.1 workaround applied to CVS without discussion actually. The last two times it came up, I didn't see any response from the developers either way. When the patch was originally proposed, Isaac said he wanted 3.1 compatibility and asked David Hardeman to change the patch. Because David was issuing several versions of that patch at the time, I assumed that the checkin with executedQuery() was unintentional. Since the last official word I found was pro-3.1, I assumed that was still the policy. I don't really care either way, I just don't want us to claim 3.1 compatibility while we're breaking compilation for 3.1. http://gossamer-threads.com/lists/mythtv/dev/97940 When it becomes time for a release then a decision could be made whether the changes that depended on a newer QT were worth breaking compatibility. I disagree strongly with this. If the decision is made in favor of compatibility, then we'd potentially be making several unrelated, difficult-to-test (since we rely on 3.1 testers) changes throughout the code just before a release. That's a recipe for disaster in my opinion; I don't want a 0.17.1 release to be necessary for something this avoidable. - Jer ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv] Re: [mythtv-commits] mythtv commits
On 15 Jan 2005, at 9:27 PM, Isaac Richards wrote: These changes are incorrect, please revert them. The error messages would be printed out with the placeholders, instead of with the actual values. Are we dropping Qt 3.1 compatibility then? That's what it means to revert the changes without another fix in place. Regardless of the compatibility issue, those calls make little sense when you look at the DBError signature. It's wanting a QSqlQuery, not a QString as executedQuery returns. The problem is that DBError uses lastQuery instead of executedQuery, and this is the root of the problem. Here's a patch that fixes that, so the proper debugging string is printed in all cases (not just in programinfo.cpp). You can decide if you want the version #ifdef or not. - Jeremiah Index: mythcontext.cpp === RCS file: /var/lib/mythcvs/mythtv/libs/libmyth/mythcontext.cpp,v retrieving revision 1.143 diff -u -r1.143 mythcontext.cpp --- mythcontext.cpp 30 Dec 2004 16:17:22 - 1.143 +++ mythcontext.cpp 16 Jan 2005 02:44:31 - @@ -1219,9 +1219,15 @@ cerr DB Error ( where ): endl; } +#if QT_VERSION = 0x030200 +cerr Query was: endl + query.executedQuery() endl + DBErrorMessage(query.lastError()) endl; +#else cerr Query was: endl query.lastQuery() endl DBErrorMessage(query.lastError()) endl; +#endif } QString MythContext::DBErrorMessage(const QSqlError err) % ___ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
