Delay on startup #5478
Comments
|
You can try raising the log level (with |
|
Well, this gives me some more output but apparently I am still not seeing what's blocking with all=trace [ 0.361][v][vo/gpu] Resize: 1920x960 |
|
I have some suspicion that this is font related (libass font backend, number of installed fonts), but the log doesn't show anything interesting. |
|
Well I tried it with an mp4 file without and subtitles and get the same result. At first I thought that this is related to a stall when opening the file but as I can see this happens later on.. [ 6.451][i][cplayer] Playing: /Users/maru/Cuban Fury.mp4 and there is no delay there. |
|
Trying this from the CLI seems to be better. I was not yet able to reproduce it there. |
|
it would probably also help if you didn't ignore the issue template and post a full log instead of just a part of it. that way we wouldn't need to guess that you are on a mac or how exactly you reproduce the problem. |
|
You could try starting it from a debugger, and if it's frozen, abort manually and then look what the threads are doing. Also what Akemi said. |
|
What happens if you open the same file with a different application? |
|
VLC works fine without any issues. |
|
@Akemi I know I was just leaving office so I tried to keep it precise. To reproduce this issue I just opened a file in finder by double-clicking on it. Then I completely closed the file again. Doing this a few times on the same file and at least I see that the hangs. It can happen on the first try or on the 5-10. I just noticed it when I opened a file for the first time and then saw that it took very long to start. I am running the latest HEAD build on 10.12.6 with a macbook pro 2016. |
|
Here a log when it is happening.. I tried one of my mkv files but it is the same with an mp4 file when it happens. |
|
I had another stall where the log looks a little bit different. |
|
it's a bit weird that it apparently only happens with the bundle, since the only bundle specific routines happen before the log is even created. can you be a bit more specific about the 'delay'? i assume when the delay happens a window is already created but just black and playback doesn't start? at least that's what i would gather from the log. tbh the only thing that would come to mind that is completely different from the bundle and also has an effect after mpv was started is the redirection of the output. since you build mpv yourself you could try commenting out this line. i kinda doubt that it is the reason, but if above doesn't change anything you could also try commenting out this line. seem like that paste site only allows up to 1005 lines? the second log seems cut off at the bottom. |
|
Aw crap I replaced the wrong link, from the first pastebin and not the second. |
|
@Akemi Commenting out setup_bundle breaks it, it opens and closes. Commenting redirect_output seems to make some difference, I an still reproduce it but not to that extent. |
|
oh right, obviously that breaks. my bad. instead of commenting out setup_bundle just comment line 264-272. that leaves the needed parts in. |
|
This does not make a difference for the bundle, it is still hanging. I really tried to reproduce this via the cli but failed so far. You have a small delay every now and then but not even remotely that long. |
|
any differences when deleting the |
|
Then it does not start.. |
|
that's impossible. it just deactivates the pseudo-gui mode, eg if opened without a file it will close again. are you sure you reverted the previous changes? do you have any local configs? also try with |
|
Nope even after reverting it does not start. That said I have an older config, my config files are under ~/.mpv/config. Does this make a difference? |
|
Let'S try a different approach. What's the easiest way to start the app bundle in a debugger? |
|
Well I tried the debugger from the CLI. Of course I cannot reproduce the issue this way. |
|
indeed, my bad again about deleting the mpv.conf in the bundle. i made some changes to another branch which aren't merged in git master yet. those changes fix exactly that as a side effect. so yeah that was a bad suggestion on my side. i am not sure if your local config file makes a difference. though i wanted to suggest to deleted/move the whole folder so mpv won't load anything that could effect it. best chances are probably to start from the bundle and then attaching the debugger to the open app. |
|
I tested this, if I open the app and then drag and drop a file in there I cannot reproduce the hang. I tried with -vo null and could not reproduce it either, so I think it could be something with the vo init. |
|
then you could test this #4833. it has a completely different vo init routine. if the problem still persists it's most likely something else. just make sure you use |
|
Today is not my lucky day. This build fails with... ld: framework not found ColorSync for architecture x86_64 Which I do not understand at all |
|
Good Morning, I was able to get this to compile with 10.12 and XCode8, thank you Akemi for giving me the right pointers. While this version hangs during startup with the cocoa backend for me it does work with opengl-cb. @Akemi during my testing yesterday evening I forgot to change the vo to opengl-cb so apparently that why it was hanging during startup. |
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that can't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that can't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
|
even though the cocoa-cb fixed PR it for you i am still wondering if a build from this older commit has the same problem? |
|
I can reproduce the delay with this commit as well, although it seems that it happens less often. |
|
i am wondering if you could try some older releases (<=0.27) and see if it happens with them too? if it isn't present in one of them i would like to pinpoint the commit that caused it if possible. maybe it's related to some application code and not the backend itself and that could cause problems with cocoa-cb too. |
|
I tried the older releases, it seems a lot harder to trigger there. I think it really has to do with the change of the wrapper in some way. As for the cocoa-cb I really tried hard to reproduce this issue there but simply did not manage. I relaunched the app around 50 times and all I COULD see was that every now and then the initial size of the window was not the correct size of the video, but it did not stall and resized shortly later. |
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
ghost
mentioned this issue
Hello,
I just updated my mpv.app to the latest head version. Now I see some strange delays when opening a file. It does not happen all the time, but after opening several files always closing mpv.app in between I am seeing a delay during startup. The files are all local on an SSD so I doubt that this is the problem. Furthermore when I do not close mpv and open a new file via to open dialog I cannot reproduce this issue at all. I tried to capture the logs when this is happening but I there no error messages.
[ 0.231][d][cplayer] Run command: loadfile, flags=1, args=[/Users/maru/testfile.mkv, replace, ]
[ 0.361][v][vo/gpu] Resize: 1920x960
[ 0.361][v][vo/gpu] Window size: 1920x960
[ 0.361][v][vo/gpu] Video source: 960x480 (1:1)
[ 0.361][v][vo/gpu] Video display: (0, 0) 960x480 -> (0, 0) 1920x960
[ 0.361][v][vo/gpu] Video scale: 2.000000/2.000000
[ 0.361][v][vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[ 0.361][v][vo/gpu] Video borders: l=0 t=0 r=0 b=0
[ 6.449][i][cplayer] Playing: /Users/maru/testfile.mkv
[ 6.450][v][file] Opening /Users/maru/testfile.mkv
[ 6.451][d][file] Stream opened successfully.
[ 6.452][v][cache] Cache size set to 12048 KiB (10000 KiB backbuffer)
Retrying the same file then yields different results. either there is a delay or it starts playing immediatly.
I know that this will be pretty difficult to debug since it is not always reproducible, but maybe you can tell me how I can figure out what's taking almost 6 seconds here.
The text was updated successfully, but these errors were encountered: