Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 3 years ago

#9223 closed defect (Fixed)

Sluggish menu when watching a recording

Reported by: glemsom@… Owned by: markk
Priority: minor Milestone: 0.24.1
Component: MythTV - Video Playback Version: 0.24-fixes
Severity: medium Keywords: sluggish menu
Cc: Ticket locked: no

Description

I've recently upgraded to MythTV 0.24 on my mediecenter.
When I watch a recording (or LiveTV for that matter), all menues are quite sluggish.
For example try doing these steps:
1: Watch a recording.
2: Hit M to brung up the menu.
3: Shuffle between the different elements in the menu.

Though, on everywhere else the menu is quite fast.
I did not have the same issue with 0.23-fixes.

System details:
Render VDPAU advanced 2x (For HD Temporal 2x)
CPU: E8400 @ 3.00GHz
GFX: GeForce? 9600 GT

I've tried different themes, and tried non-vdpau renders. But I still have the same result. The CPU isn't really doing much when watching a recording - and constantly shuffling in the menu does not raise the CPU load.

Attachments (8)

before_frontend_start.txt (23.1 KB) - added by mythtv@… 3 years ago.
Browsing menus, no problems
frontend_problems.txt (39.1 KB) - added by mythtv@… 3 years ago.
Frontend having problems backtrace
crash_messy_exit_no_playback.txt (5.4 KB) - added by mythtv@… 3 years ago.
Possibly relevant: crash on exit, even when no playback has been invoked. EXC_BAD_ACCESS
backtrace_frontend_waiting_for_pause.txt (13.4 KB) - added by john.sturgeon@… 3 years ago.
Backtrace on frontend during attempt to pause
frontend_log.txt (21.2 KB) - added by john.sturgeon@… 3 years ago.
frontend log file during issue
frontend_verbose_playback_before_pressing_pause.txt (42.1 KB) - added by john.sturgeon@… 3 years ago.
Frontend VERBOSE log file during issue
frontend_backtrace_before_pressing_pause.txt (12.7 KB) - added by john.sturgeon@… 3 years ago.
Frontend backtrace captured *before* pressing pause
frontend_backtrace_after_pressing_pause.txt (9.7 KB) - added by john.sturgeon@… 3 years ago.
Frontend backtrace *after* pressing pause

Download all attachments as: .zip

Change History (46)

comment:1 Changed 3 years ago by glemsom@…

update:
I just found that LiveTV has the exact same bug too.
Both program navigation, and all menu navigation is sluggish when using LiveTV too.

comment:2 Changed 3 years ago by robertm

  • Owner set to markk
  • Status changed from new to assigned

FWIW I do not experience this. I suspect it's a byproduct of everything being in the UI thread now, but will let you make the determination of whether this can be fixed for these folks, Mark.

comment:3 Changed 3 years ago by peterska@…

I also experience this with the Mac OS X build running on a Mac Mini with Mac OS X 10.6.5 and using the Apple remote or keyboard. On the same machine using XBMC or Boxee the menus are smooth and fast.

comment:4 Changed 3 years ago by robertm

  • Ticket locked set

peterska, please read the ticket howto. Me too adds nothing. XBMC and Boxee have *nothing* to do with myth, that's like comparing apples and speedboats.

comment:5 Changed 3 years ago by markk

  • Milestone changed from unknown to 0.24.1
  • Status changed from assigned to infoneeded
  • Ticket locked unset

Can you please update to the latest fixes/0.24 and see whether this has been fixed or improved. You need at least revisions SHA: cfd7b7877b5dc8b25dd2

comment:6 Changed 3 years ago by david@…

I have just built the latest fixes but still have the problem.
Not 100% sure if it built the correct version theough:
svn info
Path: .
URL: http://code.mythtv.org/svn/branches/release-0-24-fixes/mythtv
Repository Root: http://code.mythtv.org/svn
Repository UUID: 7dbf422c-18fa-0310-86e9-fd20926502f2
Revision: 27420
Node Kind: directory
Schedule: normal
Last Changed Author: markk
Last Changed Rev: 27419
Last Changed Date: 2010-12-02 15:10:13 +0000 (Thu, 02 Dec 2010)

comment:7 Changed 3 years ago by david@…

sorry I should have formatted that better

svn info
Path: .
URL: http://code.mythtv.org/svn/branches/release-0-24-fixes/mythtv
Repository Root: http://code.mythtv.org/svn
Repository UUID: 7dbf422c-18fa-0310-86e9-fd20926502f2
Revision: 27420
Node Kind: directory
Schedule: normal
Last Changed Author: markk
Last Changed Rev: 27419
Last Changed Date: 2010-12-02 15:10:13 +0000 (Thu, 02 Dec 2010)

comment:8 Changed 3 years ago by robertm

MythTV is no longer built from SVN. See:

http://code.mythtv.org/trac/

On checking out and building from git. Your version is several weeks old.

comment:9 Changed 3 years ago by Peter Skarpetis <peterska@…>

I tried this today with the latest git version and the problem remains. I tested in on Mac OS X 10.6.5 using a current generation Mac mini and an Apple Remote. The keys on the Apple remote have to be held down for a second for them to register otherwise the apple remote events seem to get lost. In normal menus the response is instant.

And here is the output from a couple of git commands so you can see what I built.
[lime:/data/src/myththtv-0.24/src/mythtv] $ git status
# On branch fixes/0.24

git log

commit c81a3d77184738671bfd03f87f27e619189843c3
Author: Michael Dean <mdean@…>
Date: Fri Dec 17 08:55:59 2010 +0800

Add edit marks to MythCenter?-wide OSD editbar

commit 7ed83c31d266b971c97c5f12bf4801a8135893bf
Author: Doug Haber <>
Date: Fri Dec 17 08:32:37 2010 +0800

Backport SHA: a635a7b288d8e1456970 from master to fixes/0.24


Fix a segmentation fault in preview generation.

comment:10 Changed 3 years ago by markk

This is almost certainly now fixed in trunk following SHA c8825513647b9b95b1c3

If there are no additional complications, I'll backport to fixes/0.24 in a few days (and fwiw, if anyone wants to test on 0.24, the diff should apply cleanly).

comment:11 Changed 3 years ago by markk

  • Component changed from MythTV - General to MythTV - Video Playback
  • Resolution set to Fixed
  • Status changed from infoneeded to closed

Fixed in SHA a328d996b94f62814cf0

comment:12 Changed 3 years ago by david@…

could somone please update the builds at
http://mythtvformacosx.sourceforge.net/

comment:13 follow-up: Changed 3 years ago by Peter Skarpetis <peterska@…>

I tried the new build on Mac OS X with myth 0.24 and as soon as your press a key on the keyboard you get the spinning beach ball of death. This fix makes the Mac version unuseable.

comment:14 in reply to: ↑ 13 Changed 3 years ago by stridger@…

Replying to Peter Skarpetis <peterska@…>:

I tried the new build on Mac OS X with myth 0.24 and as soon as your press a key on the keyboard you get the spinning beach ball of death. This fix makes the Mac version unuseable.

I agree. The sluggishness has now been inflated so much that it is completely unusable. It takes more than 2 minutes for the OSD to show up.

comment:15 Changed 3 years ago by stridger@…

  • Resolution Fixed deleted
  • Status changed from closed to new

comment:16 Changed 3 years ago by markk

So - is anyone actually going to add something useful now that it's been re-opened?

logs, version info, package source etc ?

For what it's worth, working perfectly on my MacBook? with OS X 10.6

comment:17 Changed 3 years ago by stridger@…

Sorry, haven't realised that this is working for some. I've compiled from Git from the fixes/0.24 branch and checked that your patch was in. It starts TV perfectly fine and it runs fine, but any further action is almost impossible (happens after 1-2 minutes). I'll see if I can get some logs today.

Thanks for looking into this, and sorry for not being helpful.

comment:18 Changed 3 years ago by stridger@…

I'm on a Mac Mini with 10.6 btw. 0.23 worked fine.

comment:19 Changed 3 years ago by stridger@…

Ok, here is the Log that I was able to get. There doesnt seem to be any information during the time when the machine is unresponsive. The Bus error at the end seems unrelated as I can use mythtv fine after it finally exits livetv. The bus error is only there when I fully exit the frontend.

2011-01-16 16:23:23.804 MythCoreContext: Connecting to backend server: 10.29.0.10:6543 (try 1 of 1)
2011-01-16 16:23:23.806 Using protocol version 63
2011-01-16 16:23:28.052 TV: Attempting to change from None to WatchingLiveTV
2011-01-16 16:23:28.052 MythCoreContext: Connecting to backend server: 10.29.0.10:6543 (try 1 of 1)
2011-01-16 16:23:28.054 Using protocol version 63
2011-01-16 16:23:28.077 Spawning LiveTV Recorder -- begin
2011-01-16 16:23:28.652 Spawning LiveTV Recorder -- end
2011-01-16 16:23:28.700 We have a playbackURL(myth://10.29.0.10:6543/1001_20110116162328.mpg) & cardtype(DUMMY)
2011-01-16 16:23:28.700 We have a RingBuffer
2011-01-16 16:23:29.258 VideoOutputQuartz::VProf: rend(quartz-blit) osd(softblend) deint(onefield,linearblend) filt()
2011-01-16 16:23:30.398 OSD: Base theme size: 1280x720
2011-01-16 16:23:30.398 OSD: Scaling factors: 0.5625x0.8
2011-01-16 16:23:30.500 MythFontProperties, Error: Failed to load 'Liberation Sans', got 'Arial' instead
			Location: /Users/mediacenter/build/mythtv/0.24/MythFrontend.app/Contents/Resources/share/mythtv/themes/Terra/osd.xml @ 115
			Name: 'timefont'	Type: 'fontdef'
2011-01-16 16:23:30.513 MythFontProperties, Error: Failed to load 'Liberation Sans', got 'Arial' instead
			Location: /Users/mediacenter/build/mythtv/0.24/MythFrontend.app/Contents/Resources/share/mythtv/themes/Terra/osd.xml @ 239
			Name: 'timefont'	Type: 'fontdef'
2011-01-16 16:23:30.530 OSD: Base theme size: 1280x720
2011-01-16 16:23:30.530 OSD: Scaling factors: 0.5625x0.8
2011-01-16 16:23:30.555 Player(0): Video timing method: USleep with busy wait
2011-01-16 16:23:30.556 TV: Changing from None to WatchingLiveTV
2011-01-16 16:23:30.556 TV: State is LiveTV & mctx == ctx
2011-01-16 16:23:30.560 TV: UpdateOSDInput done
2011-01-16 16:23:30.560 TV: UpdateLCD done
2011-01-16 16:23:30.560 TV: ITVRestart done
2011-01-16 16:23:30.750 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:30.905 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.047 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.190 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.333 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.478 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.628 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.778 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:31.925 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.069 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.217 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.369 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.519 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.666 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.809 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:32.959 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:33.109 MythUIHelper, Error: LoadScaleImage(/home/mythtv/.mythtv/channels/bbc_one_oxford.jpg)Unable to find image file
2011-01-16 16:23:33.163 VideoOutput: Created YV12 OSD.
2011-01-16 16:23:38.744 Player(0): DecoderGetFrame() called with NULL decoder.
2011-01-16 16:23:38.826 VideoOutputQuartz::VProf: rend(quartz-blit) osd(softblend) deint(onefield,linearblend) filt()
2011-01-16 16:23:38.864 AFD: Opened codec 0xb13800, id(MPEG2VIDEO) type(Video)
2011-01-16 16:23:38.864 AFD: codec MP2 has 2 channels
2011-01-16 16:23:38.864 AFD: Opened codec 0xb0c000, id(MP2) type(Audio)
2011-01-16 16:23:38.865 AFD: codec MP2 has 1 channels
2011-01-16 16:23:38.865 AFD: Opened codec 0xb0c400, id(MP2) type(Audio)
2011-01-16 16:23:38.865 AFD: Opened codec 0xb0c800, id(DVB_SUBTITLE) type(Subtitle)
2011-01-16 16:23:39.098 AO: Opening audio device 'CoreAudio:' ch 2(2) sr 48000 sf signed 16 bit reenc 0
2011-01-16 16:23:40.036 AudioPlayer: Enabling Audio
2011-01-16 16:24:52.801 TV: Attempting to change from WatchingLiveTV to None
2011-01-16 16:24:53.792 TV: Changing from WatchingLiveTV to None
2011-01-16 16:24:53.806 TV: Attempting to change from None to None
2011-01-16 16:24:53.832 TV Warning: GetPlayerReadLock(0,tv_play.cpp,7717) returning NULL size(0)
Bus error

If I can provide any further information, please let me know.

comment:20 Changed 3 years ago by stridger@…

Can you please fix your channel icons as a first step.  In the past, telling MythTV you have a channel icon that you don't have has had the effect of making some parts of MythTV extremely slow.  I don't know if that's still the case, but you really need to have a properly-configured system before you can tell what's happening.

Yes, sorry. When I've seen the error, I've cleared the icon on the server, but that had no effect unfortunately apart from not showing the error anymore. I'm not entirely sure why the icon wants to go into that directory on the client in the first place, since this is where it is on the server. It's nothing special about my system, I setup the server, got the icons through mythtv-setup and then connected the Mac as a frontend and the errors showed up. I suppose it is a limitation of some sort. In either case its unrelated to the original problem.

I keep trying different things, since I heard that it works fine on a Macbook with 10.6, but so far I have only been successful with downgrading to 0.23.1 .

Thanks!

comment:21 Changed 3 years ago by markk

I'm working on the premise that this is a threading issue. The OS X Qt version in use is clearly operating in a different way internally to the *nix version (and differently to the Qt version I'm using on my Macbook, which is a version of Qt 4.7 compiled with native Cocoa support).

So, I'm going to need as much detail as you can give me with the output of:-

mythfrontend --version

mythfrontend -v playback

mythfrontend -v all

Ideally, for the last 2, can you try and identify/annotate in the log where the keypress happens. Keep it simple - start the frontend, start playing a recording, let it settle for a few seconds and then press one key (and one key only).

Even more useful would be full backtraces from interrupting the frontend while it's stuck (i.e. run it in gdb and interrupt it or use something like QtCreator?/XCode).

comment:22 Changed 3 years ago by Craig Treleaven <ctreleaven@…>

Tried the runs as requested with a fresh version of Myth (built today, Jan 19, 2011). See:

http://home.cogeco.ca/~4dabay/Myth9223/

Myth9223WCT.zip contains MythFrontend's version info, the log with '-v playback' and even the output from osx-packager.pl detailing the build.

MythFrontend_20110119_all.log.zip is the (20 MB) log with '-v all'.

For both logs, I started MFE, navigated to a short recording, started playback, waited a few seconds, pressed 'i' for Info and waited. The OSD eventually appeared after about 2 minutes and then disappeared as normal. (A couple of commercial skips are present in the recording. They appeared to skip normally.) I then pressed Esc 2 or 3 times trying to exit playback. The recording played for another 6-7 minutes and appeared to freeze at the end of the recording. The SPOD (spinning pizza of death) was visible after the first key-press throughout. I used 'killall MythFrontend', eventually.

This is on a Mac Mini Core Duo under MacOS X 10.5.8.

Craig

comment:23 Changed 3 years ago by markk

  • Status changed from new to infoneeded_new

Craig - thanks for the logs. Unfortunately I can't see anything useful in them and I still can't reproduce the issue here.

So I'm either going to need someone to produce some backtraces gathered while the frontend app is in the 'unresponsive' state or I need some packages that are in use and that are producing the issue - preferably of known origin with known source version (i.e. vanilla, up-to-date fixes/0.24). I have tried the packages from the MythTV for Mac OSX sourceforge site but they crash on startup here.

regards, Mark

comment:24 Changed 3 years ago by Craig Treleaven <ctreleaven@…>

Mark,
thanks for looking. I'm going to be away for about a week and don't expect to have a chance to learn gdb in the time I have left. Hopefully someone else can jump in on this...

Craig

comment:25 Changed 3 years ago by mythtv@…

Funny Craig should say that ;-)....I am attaching two backtraces (thread apply all bt full) though not from 24-fixes [v0.25pre-907-g9a7ad70-dirty]. One backtrace is while browsing the menus (no playback in progress). The second backtrace is a few seconds after pressing "P". @markk is this what you had in mind? --(mythtv) (at) (boonstra_dot_org)

Changed 3 years ago by mythtv@…

Browsing menus, no problems

Changed 3 years ago by mythtv@…

Frontend having problems backtrace

Changed 3 years ago by mythtv@…

Possibly relevant: crash on exit, even when no playback has been invoked. EXC_BAD_ACCESS

Changed 3 years ago by john.sturgeon@…

Backtrace on frontend during attempt to pause

comment:26 Changed 3 years ago by john.sturgeon@…

The above attachment (backtrace_frontend_waiting_for_pause.txt) was a backtrace that I captured when I started MythFrontend, waited until the OSD faded, then pressed pause. The cursor was a spinning beach ball at the time I captured the backtrace.

Then next attachment (frontend_log.txt) is the log that I got from mythfrontend during the issue.

Changed 3 years ago by john.sturgeon@…

frontend log file during issue

Changed 3 years ago by john.sturgeon@…

Frontend VERBOSE log file during issue

Changed 3 years ago by john.sturgeon@…

Frontend backtrace captured *before* pressing pause

Changed 3 years ago by john.sturgeon@…

Frontend backtrace *after* pressing pause

comment:27 Changed 3 years ago by john.sturgeon@…

I've attached three more files, the first is a more verbose log file during playback, the next two are backtraces captured before and after I pressed 'P'.

One thing to note is that there were no additional log file entries when I pressed 'P'.. I had the spinning beach ball simply during playback so I doubt that MythTV ever saw my keystroke...

On another note, I have not been able to get a successful debug build, so I'll post to mythtv-dev with my issues to see if I can get more information.

comment:28 Changed 3 years ago by dgatwood@…

Pure backtraces are probably not what you want. Samples are generally much more helpful at tracking down these sorts of problems. To take a sample, run Terminal and type

sample PID 10 10

to sample process ID "PID" for 10 seconds, sampling every 10 milliseconds. (Type "man sample" for more info.)

Also, MythTVForMacOSX tracker ID 3165719 is also tracking these SPODs over on sf.net. I'm seeing this on both of my MythTV boxes (one current Mini, one ancient MacBook?). The Mini is particularly bad because in addition to complete loss of control, the video is just a white screen.

I've rolled back to the November 12th build of 0.24, which does *not* exhibit this hanging problem (haven't tried on the Mini yet). So basically, this regressed some time between mid-November and mid-January. Hope that helps narrow things down a little.

If a sample of the last public build would be helpful, you can find one at:

http://www.gatwood.net/junk/MythFrontend_35911.MWzwF1.sample.txt

BTW, the keypress is a red herring. You folks may well know all the things I'm about to say, so if you do, know that this isn't intended to be talking down to you guys or anything. :-)

Mac OS X shows the spinning wheel of death (a.k.a. spinning pizza of death, a.k.a. SPOD) when an application's event queue fills up and the window server can no longer deliver new events. It continues to try every few seconds until the app responds, at which point the cursor no longer SPODs when hovering over the application.

Basically, the key event just happens to be the first event that gets the queue too full in certain cases. If you command-tab out of the app and wait about thirty seconds, you'll see Mythfrontend go into a SPOD state all by itself. This spod state can only be caused by one thing: the app isn't servicing events. I can only think of three possible reasons why this can occur:

  1. The run loop was stopped for some reason. It kind of looks like this may have occurred here.... I'm not seeing CFRunLoopRun in any of the samples while the app is playing, and that's not a good sign. :-)
  2. The event sources were removed from the run loop for some reason.
  3. You are doing work in your main thread that blocks, thus preventing the main thread from returning to CFRunLoopRun or CFRunLoopRunSpecific or whatever the QT equivalent is.

Even when it is working correctly, I've seen Mythfrontend's main thread do things it shouldn't be doing (blocking database queries, for example) from the main thread. When this happens, it is no longer returning program control up the stack to the QT run loop code, which means that no thread is actually handling events that get delivered to the application from the rest of the OS. Hence, keyboard events never arrive, window server "are you there" messages never get answered, and so on. In effect, the application is cut off from the OS and all user control.

You should never call any sleep variant function (sleep, usleep, nanosleep, etc.) in your main (UI) thread, nor should you ever do anything that could cause indefinite blocking (e.g. waiting on a lock that could be held by another thread for a long period of time). This means, among other things, that you should not be making synchronous database calls from anywhere in your GUI thread (the current code is *notorious* for this), nor any synchronous network calls, nor synchronous disk reads or writes, nor anything else that can potentially block for seconds at a time....

You should instead be doing these things asynchronously on a separate thread, with the helper thread posting an event to the run loop when the work is done, causing the run loop to wake up and call a continuation function or whatever). Similarly, when you need to wait a while in the main thread, you should set a timer to wake up the run loop and call a continuation function after a particular period of time, schedule the timer on the run loop, then start it and return so that the main run loop can run. It looks like the player portion is instead tearing down the run loop entirely and then running draw operations in a loop with timers and never draining the event queue. That's bad. :-)

BTW, this is not a Mac-specific design pattern. You should be doing things the way I'm describing on every platform, not just Mac OS X. Blocking the main thread is also verboten on Android, iOS, and Windows. And Xlib and GLib work the same way (though I suppose you could hack around it in X11 by calling XNextEvent() from various places in your code—blech). This is why whenever the network goes away, Mythfrontend basically hangs for half a minute or more while requests time out.

The crash report shown below (caused by doing a command-tab out of MythTV during the initial grey screen) shows roughly what your main thread backtrace should look like.

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.osx-bundler.MythFrontend  	0x0001c5f6 QString::~QString() + 6
1   org.osx-bundler.MythFrontend  	0x000c9778 ComboBoxSetting::~ComboBoxSetting() + 104
2   org.osx-bundler.MythFrontend  	0x000c9b13 GlobalComboBox::~GlobalComboBox() + 83
3   QtCore                        	0x8cbdc508 QObject::event(QEvent*) + 1080
4   QtGui                         	0x8cdc3f7c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 188
5   QtGui                         	0x8cdc84ed QApplication::notify(QObject*, QEvent*) + 1341
6   QtCore                        	0x8caf516c QCoreApplication::notifyInternal(QObject*, QEvent*) + 108
7   QtCore                        	0x8cbd09a6 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 694
8   QtGui                         	0x8cd7e03e QEventDispatcherMacPrivate::postedEventsSourcePerformCallback(void*) + 78
9   com.apple.CoreFoundation      	0x0069d4cb __CFRunLoopDoSources0 + 1563
10  com.apple.CoreFoundation      	0x0069af8f __CFRunLoopRun + 1071
11  com.apple.CoreFoundation      	0x0069a464 CFRunLoopRunSpecific + 452
12  com.apple.CoreFoundation      	0x0069a291 CFRunLoopRunInMode + 97
13  com.apple.HIToolbox           	0x04ebb004 RunCurrentEventLoopInMode + 392
14  com.apple.HIToolbox           	0x04ebacf7 ReceiveNextEventCommon + 158
15  com.apple.HIToolbox           	0x05043255 ReceiveNextEvent + 83
16  QtGui                         	0x8cd7da7f QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 303
17  QtCore                        	0x8cbcf321 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 65
18  QtCore                        	0x8cbcf65a QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 170
19  QtCore                        	0x8cbd0c86 QCoreApplication::exec() + 182
20  org.osx-bundler.MythFrontend  	0x0001a92e main + 27038
21  org.osx-bundler.MythFrontend  	0x0000c459 _start + 208
22  org.osx-bundler.MythFrontend  	0x0000c388 start + 40

Note that you see Mythfrontend's start, then _start, then main, then a bunch of things up to CFRunLoopRun, *then* code specific to the app. When the player is running, I'm instead seeing this:


     32 main
        32 BusyWaitVideoSync::WaitForFrame(int)
          32 usleep
            32 nanosleep
              32 mach_wait_until

among other things. That's almost certainly the problem right there. Note that CFRunLoopRun is not running during all of this. No CFRunLoopRun, no run loop. No run loop, no event handling. No event handling, no keyboard control. And I'm getting a SPOD even without any keypresses.

Hope that helps.

comment:29 follow-up: Changed 3 years ago by dgatwood@…

Ah. Looks like I was too quick to assume that this was the same issue as in the later builds. Now that I've rolled back to the November build, I'm seeing the horribly sluggish menu performance. With the January build, playback system is completely uncontrollable. These might or might not be related issues.

comment:30 in reply to: ↑ 29 Changed 3 years ago by markk

Replying to dgatwood@…:

Ah. Looks like I was too quick to assume that this was the same issue as in the later builds. Now that I've rolled back to the November build, I'm seeing the horribly sluggish menu performance. With the January build, playback system is completely uncontrollable. These might or might not be related issues.

I'm pretty sure it's the same issue, just manifesting itself in a slightly different way (or more/less extreme at least).

Anyway, thanks for your comments. They've helped clarify my own thoughts and have largely confirmed my suspicions. Unfortunately there probably is no easy and or quick fix.

With the OSD re-write (that went into the 0.24 release), the threading model for video playback was changed. Previously there were separate threads for both video playback and decoding. With the OSD using libmythui, and hence QWidgets, it needed to operate within the main thread and hence the extra video playback thread was removed (it also prevented some nasty X related crashes).

It's fair to say we're still picking out some of the unexpected side effects of that change.

There are still various actions that can and do block for too long but in terms of steady state video playback without user interaction, there are 2 areas that will obviously block for significant periods - deinterlacing and video sync.

The effects of deinterlacing are easy enough to eliminate for test purposes by disabling deinterlacing :)

Video sync is trickier but a quick hack into BusyWaitVideoSync::WaitForFrame? and breaking out the usleep into smaller chunks with a call to qApp->processEvents() (or indeed some form of loop with qApp->processEvents() and a continuous check of CalcDelay?()) would probably be interesting/informative.

FYI, when video is being played, the main loop is in tv_play.cpp, line 298. Essentially that processes application events and then prepares and displays one frame.

There are other quicker fixes that can probably go in around keypress handling in the TV class but I'm quite sure they're not the root cause here.

comment:31 follow-up: Changed 3 years ago by me@…

markk - I noted here that you weren't having the problems; probably due to a different version of the Qt libraries. Is there therefore a workaround involving using the alternative Qt libs; does anyone have a build against these that we could try out and at least get something working?

comment:32 in reply to: ↑ 31 Changed 3 years ago by markk

Replying to me@…:

markk - I noted here that you weren't having the problems; probably due to a different version of the Qt libraries. Is there therefore a workaround involving using the alternative Qt libs; does anyone have a build against these that we could try out and at least get something working?

For reference, my trunk build is against Qt 4.7.0 but configured to build with cocoa rather than carbon. I forget why I went down that route but it does introduce other issues - there is no quartz support and hence you have to use opengl for video - but... opengl video is currently broken unless you add a few hacks (which introduce issues of there own). The Qt version issue has got me thinking though.

comment:33 Changed 3 years ago by markk

Thanks to John and Brian, I now have a couple of fixes/0.24 binaries that display the issue.

Having re-read dgatwood's analysis and comments above, looked at the commit that introduced the issue (or moved it from painfully sluggish to totally unresponsive a328d996b94f62814cf065e60311d973283ec6c8) and considered the Qt version differences, I think the UI thread blocking issues are not the issue here.

What is probably relevant is how Qt is handling the event loop internally, which I imagine may well be different between cocoa and carbon builds. With the cocoa build, the event loop is clearly being processed as expected and for carbon - not. Hence no CFRunLoop references as dgatwood noted.

So, in the commit I've referenced above, the only piece that would appear to change the behaviour of the main event loop is the addition of hasPendingEvents() check. The Qt source for QEventDispatcher_mac is chock full of #ifdef QT_MAC_USE_COCOA, so trying to unpick the Qt internals isn't going to be fruitful.

But by way of a quick and easy test, can someone try removing the hasPendingEvents() check in tv_play (there's only one use) and see if that helps. It may well simply revert to the previous sluggish behaviour but at least that will be progress of sorts.

comment:34 follow-up: Changed 3 years ago by alex@…

Hi I tried what you suggested (remove line if (qApp->hasPendingEvents()) from tv_play.cpp) and it works like a charm

Thank you so much for your insights

$ /Applications/MythFrontend.app/Contents/MacOS/MythFrontend --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.25pre-1144-g69aeff3-dirty
MythTV Branch    : master
Network Protocol : 64
Library API      : 0.25.20110208-1
QT Version       : 4.6.0
Options compiled in:
 release use_hidesyms darwin_da using_corevideo using_backend using_bindings_php using_darwin using_frontend using_hdhomerun using_iptv using_lirc using_mheg using_opengl_video using_qtwebkit using_quartz_video using_appleremote using_bindings_php using_darwin_da using_mythtranscode using_opengl using_ffmpeg_threads using_live using_mheg

$ /Applications/MythTV/MythBackend.app/Contents/MacOS/MythBackend --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.25pre-1144-g69aeff3-dirty
MythTV Branch    : master
Network Protocol : 64
Library API      : 0.25.20110208-1
QT Version       : 4.6.0
Options compiled in:
 release use_hidesyms darwin_da using_corevideo using_backend using_bindings_php using_darwin using_frontend using_hdhomerun using_iptv using_lirc using_mheg using_opengl_video using_qtwebkit using_quartz_video using_appleremote using_bindings_php using_darwin_da using_mythtranscode using_opengl using_ffmpeg_threads using_live using_mheg

comment:35 in reply to: ↑ 34 Changed 3 years ago by markk

Replying to alex@…:

Hi I tried what you suggested (remove line if (qApp->hasPendingEvents()) from tv_play.cpp) and it works like a charm

Thanks for the update. I've removed the offending line in both master and fixes/0.24. If anyone else can confirm it fixes the issue for them, I'll close the ticket - and then open a beer:)

comment:36 Changed 3 years ago by peterska@…

I can confirm that it works on both my MacMini? and Mac Pro with Qt 4.7.1 and OS X 10.6.6

comment:37 Changed 3 years ago by stridger@…

I can also confirm that this works flawlessly now (no lag at all) on 10.6.6 with Qt 4.6.1 . Overall 0.24 seems to perform much better on OSX now than it used to on 0.23.1 . Thank you all for following this up and markk for finding a solution! This can definitely be closed and I'll buy you that beer to open if you send me a paypal address :) (couldn't find any donation page).

comment:38 Changed 3 years ago by markk

  • Resolution set to Fixed
  • Status changed from infoneeded_new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.