I'm using Qt 5.1 (from here) on a MacBook Pro (OSX 10.8.4).
I have a movie player application consisting of little more than a QMediaPlayer and a QVideoWidget. Video from a local file URL plays fine.
I can connect and monitor the player's mediaStatusChanged and positionChanged signals, and increase the rate at which they're reported with QMediaPlayer::setNotifyInterval to several times per second.
This all seems to work fine except for one annoying thing:
When the player reaches the end of the file, it doesn't change status, it just reports the same position repeatedly. Only (and this is where things get strange) if I resize the window or minimise/maximise it, does it seem to "flush out" the expected status change to QMediaPlayer::EndOfMedia. Even just raising another application to cover the video app seems to flush the status change.
Any suggestions? Bug in QMediaPlayer? Me doing something wrong? Suggestions for workrounds?
Update: Now reported in Qt Jira.
Related
I have MacBook Pro M1 Max, with two monitors, one 34" as the main monitor and one 24" as the side monitor which I use vertically, after upgrading to macOS Ventura this issue started to appear! When
I tried to watch a video on my main monitor when I switched to full screen, it was showing it sideways!
I'm a software developer so I have multiple browsers, I tried on all of them, and sometimes one was rotating but not the other, but after some time, all were rotating!
I tested Youtube, Amazon Prime, HBO on browsers, and then even the Apple TV app, they all show the videos sideways in fullscreen mode!
But it was happening only on the main monitor, not the side one, not the laptop's internal screen!
Interestingly, the image was showing normal if you moved the mouse pointer on that screen, but as soon as you stopped the mouse, the video go back to the rotated state!
One thing I found out about this was that if you restart the OS, the issue goes away, but after a few times of Sleep/Awake circles, sometimes same day but definitely the next day, it'd come back, and I have to restart the laptop again and again!
SOLVED!
It was frustrating! I called Apple support, and first, they offered to restart the OS and boot in Safe Mode and see if this happens in that mode too, I tried and it was happening in Safe Mode too!
Then the next solution was to reinstall the OS, so I backed up the data as a precaution and reinstalled the macOS Ventura, and it worked the issue has gone away!
So I leave the issue and solution here for future reference.
Here is the link to Apple Support for reinstalling the OS:
https://support.apple.com/en-us/HT204904
I am trying to troubleshoot some error that is causing any window on any app to quickly get grayed out for a dussin milliseconds, and at times get grayed out without getting "clicked back" again. I don't know if the issue lies in the cursor since it happens regardless of the current cursor location. It happens at least five times a day, and every time it happens it is very distracting.
I thought this could be caused by the trackpad clicking it out by itself since I've had issues with the trackpad a while back. But that doesn't make any sense since the location of the cursor is unaffected.
I have tried chrome, and other mac apps, but the error has persisted.
I have also tried full-screen mode on youtube (not browser full screen) but the same thing there.
I don't know if this could be relevant, but I have coded python a tiny bit although not more than installing a few packages. Though I coded python after this error started.
I want whatever error that causes app windows to get "grayed out" to be fixed.
Macos 10.15.5 Catalina
I have a graphics application that occasionally displays incorrectly after a sleep / wake cycle.
I'm wondering if there is something I should do on the Sleep or Wake events. I'm capturing these events already, because I hide the cursor in the app, and when the app wakes the cursor appears and has to be re-hidden. I'm creating my images with [[NSBitmapImageRep alloc ]initWithBitmapDataPlanes:outplanes, doing lots of bit manipulation on multiple images. I display the image full screen. Xcode 7.1, OSX 10.10
The error I get is a shimmering on the display as if my merge routines are using the wrong data.
I was assuming the sleep took a snapshot of all my data, including whatever is on the stack? It's hard to reproduce the problem, but my App is going to be running every day in a public space and uses the scheduler to sleep each night and autowake in the morning.
Should I reinitialise all my variables on a wake?
I can't see anything on the apple docs about actions you should take on these events.
It should not be necessary to worry about this. If it is, that is likely to be either a bug in your app, or a bug in Apple's code. Indeed, the cursor issue you mention sounds like a bug to me, and you should log a bug in Apple's bug reporter about that. Sleep/wake should be entirely transparent for apps that don't have a specific reason to care. You will need to try to pin down the issue you are seeing, somehow, and diagnose it.
I created a small OSX app that takes a picture on the webcam every hour. However, as soon as the first webcam picture is taken, the app gets listed in the dreaded "Apps using significant energy" list under the MacBook battery menu. It then remains in this list until the app is closed.
However, when examined in Xcode, it is clear the app only consumes energy for the brief second that the photo is taken, as seen here:
Is there any way to tell OSX to re-audit energy usage? Or could I silently quit and restart my app after each photo to "clear its record"? How else can I get rid of this false bad-rap from the OS?
EDIT: Further research shows that simply accessing the camera is does not automatically put an app on this list. Apple's own Photo Booth app, for example, does not get listed even when it is filming video. I've edited the title and question to be more explicit about finding what it is that triggers this warning.
I'm using the popular ImageSnap code for taking the picture. The same issue happened with both the original and the new Mavericks-specific version.
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.