Load playlist using loadfile, crash error ../player/loadfile.c:1920: void play_current_file(struct MPContext *): assertion "mpctx->stop_play" failed #13778
Labels
Comments
|
I am experiencing the same issue: bluecherrydvr/unity#215 This specially happens when a lot of players are loaded at the same time, probably indicating a memory allocation issue. This does not happen when there are three or less players loaded. This seems to happen more frequently on streams with higher quality. Logs |
|
@bdlukaa There is a very important point here. When playing many video streams, automatic switching to the next episode will occur. If you manually switch to the next episode, this problem will not occur. |
|
@bdlukaa really solved the problem this time. You can also try this PR |
Dudemanguy
added a commit
to Dudemanguy/mpv
that referenced
this issue
May 13, 2024
Normally if you seek during EOF, mpv will reset the value of mpctx->stop_play so it doesn't exit. There's at least a couple of exceptions where this *shouldn't* happen however. If the play direction changes right at the end of the file, we shouldn't touch the value to avoid an erronous assertion error. Additionally, it is apparently possible for the queue_seek call in VO reinit code to trigger the assertion issue. This is a seek of exactly zero and logically shouldn't be reset mpctx->stop_play anyways (i.e. AT_END_OF_FILE should stay the same). By moving this to queue_seek itself, most of the special handling in player/command.c can be dropped. The option still needs to be set though. Fixes mpv-player#13778.
Dudemanguy
added a commit
to Dudemanguy/mpv
that referenced
this issue
May 14, 2024
Normally if you seek during EOF, mpv will reset the value of mpctx->stop_play so it doesn't exit. There's at least a couple of exceptions where this *shouldn't* happen however. If the play direction changes right at the end of the file, we shouldn't touch the value to avoid an erronous assertion error. Additionally, it is apparently possible for the queue_seek call in VO reinit code to trigger the assertion issue. This is a seek of exactly zero and logically shouldn't be reset mpctx->stop_play anyways (i.e. AT_END_OF_FILE should stay the same). By moving this to queue_seek itself, most of the special handling in player/command.c can be dropped. The option still needs to be set though. Fixes mpv-player#13778.
Dudemanguy
added a commit
to Dudemanguy/mpv
that referenced
this issue
May 15, 2024
In various edge cases, this causes an assertion that was added later in 8816e11 to be hit. The actual purpose of the special case is not really clear. mp_seek already will change the mpctx->stop_play value, so there shouldn't be any need to do it in queue_seek. And it is known to cause problems so revert it. Also, remove the special play direction logic that works around this behavior. Fixes mpv-player#13778. This reverts commit dbdc46c.
Dudemanguy
added a commit
that referenced
this issue
May 16, 2024
In various edge cases, this causes an assertion that was added later in 8816e11 to be hit. The actual purpose of the special case is not really clear. mp_seek already will change the mpctx->stop_play value, so there shouldn't be any need to do it in queue_seek. And it is known to cause problems so revert it. Also, remove the special play direction logic that works around this behavior. Fixes #13778. This reverts commit dbdc46c.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Important Information
Provide following Information:
[f4a7931](https://github.com/mpv-player/mpv/commit/f4a7931c534158d254a4a36f289494c1de6a16b9)Android 13https://github.com/user1121114685/libmpv-android-video-build/releases/tag/20240327nolibmpvmtk and QualcommLoad playlist using loadfile, crash errorIf you're not using git master or the latest release, update.
Releases are listed here: https://github.com/mpv-player/mpv/releases
Reproduction steps
Try to reproduce your issue with --no-config first. If it isn't reproducible
with --no-config try to first find out which option or script causes your issue.
If the issue is performance-related, try to reproduce it with --no-config
--profile=fast, which is designed to work on lower-end mobile devices.
Additionally, enable hardware decoding with --hwdec=yes or the Ctrl+h shortcut.
Describe the reproduction steps as precise as possible. It's very likely that
the bug you experience wasn't reproduced by the developer because the workflow
differs from your own.
Expected behavior
Actual behavior
Log file
Make a log file
made with -v -v or --log-file=output.txt, attach it to
the issue, and replace this text with a link to it.
Without the log file, this issue will be closed for ignoring the issue template.
In the case of a crash, please provide a backtrace.
错误log.txt in line 671
Sample files
Sample files needed to reproduce this issue can be attached to the issue
(preferred), or be uploaded to https://0x0.st/ or similar sites.
(Only needed if the issue cannot be reproduced without it.)
Do not use garbage like "cloud storage", especially not Google Drive.
The text was updated successfully, but these errors were encountered: