2013-10-29 21:38:29 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2013-10-29 21:38:29 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2013-10-29 21:38:29 +00:00
|
|
|
*/
|
|
|
|
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
#include <errno.h>
|
2013-10-29 21:38:29 +00:00
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <fcntl.h>
|
2024-05-01 22:44:59 +00:00
|
|
|
|
|
|
|
#ifdef _WIN32
|
|
|
|
#include <sys/utime.h>
|
|
|
|
#else
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
#include <utime.h>
|
2024-05-01 22:44:59 +00:00
|
|
|
#endif
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
#include <libavutil/md5.h>
|
|
|
|
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
#include "osdep/io.h"
|
|
|
|
|
2014-06-11 00:04:02 +00:00
|
|
|
#include "common/encode.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2014-07-01 21:10:38 +00:00
|
|
|
#include "misc/ctype.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/path.h"
|
|
|
|
#include "options/m_config.h"
|
2021-07-21 09:06:41 +00:00
|
|
|
#include "options/m_config_frontend.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/parse_configfile.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/playlist.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/options.h"
|
|
|
|
#include "options/m_property.h"
|
2024-10-30 01:30:07 +00:00
|
|
|
#include "input/input.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
#include "stream/stream.h"
|
|
|
|
|
2013-12-17 00:08:53 +00:00
|
|
|
#include "core.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "command.h"
|
|
|
|
|
2015-02-15 13:28:49 +00:00
|
|
|
static void load_all_cfgfiles(struct MPContext *mpctx, char *section,
|
|
|
|
char *filename)
|
2014-06-26 15:56:47 +00:00
|
|
|
{
|
2014-06-26 17:13:37 +00:00
|
|
|
char **cf = mp_find_all_config_files(NULL, mpctx->global, filename);
|
2015-02-15 13:28:49 +00:00
|
|
|
for (int i = 0; cf && cf[i]; i++)
|
2023-02-24 03:04:52 +00:00
|
|
|
m_config_parse_config_file(mpctx->mconfig, mpctx->global, cf[i], section, 0);
|
2014-06-26 17:13:37 +00:00
|
|
|
talloc_free(cf);
|
2014-06-26 15:56:47 +00:00
|
|
|
}
|
|
|
|
|
2017-06-26 09:46:36 +00:00
|
|
|
// This name is used in builtin.conf to force encoding defaults (like ao/vo).
|
2014-04-19 20:05:17 +00:00
|
|
|
#define SECT_ENCODE "encoding"
|
|
|
|
|
2014-06-26 15:56:47 +00:00
|
|
|
void mp_parse_cfgfiles(struct MPContext *mpctx)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2013-12-28 15:32:49 +00:00
|
|
|
|
2022-11-08 00:35:43 +00:00
|
|
|
mp_mk_user_dir(mpctx->global, "home", "");
|
2014-06-26 16:12:28 +00:00
|
|
|
|
2020-06-25 15:55:50 +00:00
|
|
|
char *p1 = mp_get_user_path(NULL, mpctx->global, "~~home/");
|
|
|
|
char *p2 = mp_get_user_path(NULL, mpctx->global, "~~old_home/");
|
|
|
|
if (strcmp(p1, p2) != 0 && mp_path_exists(p2)) {
|
|
|
|
MP_WARN(mpctx, "Warning, two config dirs found:\n %s (main)\n"
|
|
|
|
" %s (bogus)\nYou should merge or delete the second one.\n",
|
|
|
|
p1, p2);
|
|
|
|
}
|
|
|
|
talloc_free(p1);
|
|
|
|
talloc_free(p2);
|
|
|
|
|
2014-04-19 20:05:17 +00:00
|
|
|
char *section = NULL;
|
2024-10-30 01:29:17 +00:00
|
|
|
bool encoding = opts->encode_opts->file && opts->encode_opts->file[0];
|
2014-04-19 20:05:17 +00:00
|
|
|
// In encoding mode, we don't want to apply normal config options.
|
|
|
|
// So we "divert" normal options into a separate section, and the diverted
|
|
|
|
// section is never used - unless maybe it's explicitly referenced from an
|
|
|
|
// encoding profile.
|
2017-07-12 11:11:14 +00:00
|
|
|
if (encoding)
|
2014-04-19 20:05:17 +00:00
|
|
|
section = "playback-default";
|
2017-07-12 11:11:14 +00:00
|
|
|
|
|
|
|
load_all_cfgfiles(mpctx, NULL, "encoding-profiles.conf");
|
2014-01-01 18:25:52 +00:00
|
|
|
|
2015-02-15 13:28:49 +00:00
|
|
|
load_all_cfgfiles(mpctx, section, "mpv.conf|config");
|
2013-12-28 15:32:49 +00:00
|
|
|
|
2024-10-30 01:30:07 +00:00
|
|
|
if (encoding) {
|
2020-06-25 15:55:50 +00:00
|
|
|
m_config_set_profile(mpctx->mconfig, SECT_ENCODE, 0);
|
2024-10-30 01:30:07 +00:00
|
|
|
mp_input_enable_section(mpctx->input, "encode", MP_INPUT_EXCLUSIVE);
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
2018-01-11 22:50:44 +00:00
|
|
|
static int try_load_config(struct MPContext *mpctx, const char *file, int flags,
|
|
|
|
int msgl)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
if (!mp_path_exists(file))
|
|
|
|
return 0;
|
2018-01-11 22:50:44 +00:00
|
|
|
MP_MSG(mpctx, msgl, "Loading config '%s'\n", file);
|
2023-02-24 03:04:52 +00:00
|
|
|
m_config_parse_config_file(mpctx->mconfig, mpctx->global, file, NULL, flags);
|
2013-10-29 21:38:29 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-12-22 22:08:31 +00:00
|
|
|
// Set options file-local, and don't set them if the user set them via the
|
|
|
|
// command line.
|
2019-11-10 22:53:57 +00:00
|
|
|
#define FILE_LOCAL_FLAGS (M_SETOPT_BACKUP | M_SETOPT_PRESERVE_CMDLINE)
|
2013-12-22 22:08:31 +00:00
|
|
|
|
|
|
|
static void mp_load_per_file_config(struct MPContext *mpctx)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2013-12-21 19:45:19 +00:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2013-10-29 21:38:29 +00:00
|
|
|
char *confpath;
|
2013-12-22 22:13:59 +00:00
|
|
|
char cfg[512];
|
2013-12-21 19:45:19 +00:00
|
|
|
const char *file = mpctx->filename;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-10-17 00:55:31 +00:00
|
|
|
if (opts->use_filedir_conf) {
|
|
|
|
if (snprintf(cfg, sizeof(cfg), "%s.conf", file) >= sizeof(cfg)) {
|
|
|
|
MP_VERBOSE(mpctx, "Filename is too long, can not load file or "
|
|
|
|
"directory specific config files\n");
|
|
|
|
return;
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-10-17 00:55:31 +00:00
|
|
|
char *name = mp_basename(cfg);
|
2013-12-22 22:13:59 +00:00
|
|
|
|
|
|
|
bstr dir = mp_dirname(cfg);
|
2015-05-09 13:26:47 +00:00
|
|
|
char *dircfg = mp_path_join_bstr(NULL, dir, bstr0("mpv.conf"));
|
2018-01-11 22:50:44 +00:00
|
|
|
try_load_config(mpctx, dircfg, FILE_LOCAL_FLAGS, MSGL_INFO);
|
2013-12-22 22:13:59 +00:00
|
|
|
talloc_free(dircfg);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2018-01-11 22:50:44 +00:00
|
|
|
if (try_load_config(mpctx, cfg, FILE_LOCAL_FLAGS, MSGL_INFO))
|
2013-10-29 21:38:29 +00:00
|
|
|
return;
|
|
|
|
|
2014-10-17 00:55:31 +00:00
|
|
|
if ((confpath = mp_find_config_file(NULL, mpctx->global, name))) {
|
2018-01-11 22:50:44 +00:00
|
|
|
try_load_config(mpctx, confpath, FILE_LOCAL_FLAGS, MSGL_INFO);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-10-17 00:55:31 +00:00
|
|
|
talloc_free(confpath);
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-22 22:08:31 +00:00
|
|
|
static void mp_auto_load_profile(struct MPContext *mpctx, char *category,
|
|
|
|
bstr item)
|
|
|
|
{
|
|
|
|
if (!item.len)
|
|
|
|
return;
|
|
|
|
|
|
|
|
char t[512];
|
|
|
|
snprintf(t, sizeof(t), "%s.%.*s", category, BSTR_P(item));
|
|
|
|
m_profile_t *p = m_config_get_profile0(mpctx->mconfig, t);
|
|
|
|
if (p) {
|
|
|
|
MP_INFO(mpctx, "Auto-loading profile '%s'\n", t);
|
2015-05-07 19:03:14 +00:00
|
|
|
m_config_set_profile(mpctx->mconfig, t, FILE_LOCAL_FLAGS);
|
2013-12-22 22:08:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void mp_load_auto_profiles(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
mp_auto_load_profile(mpctx, "protocol",
|
|
|
|
mp_split_proto(bstr0(mpctx->filename), NULL));
|
|
|
|
mp_auto_load_profile(mpctx, "extension",
|
|
|
|
bstr0(mp_splitext(mpctx->filename, NULL)));
|
|
|
|
|
|
|
|
mp_load_per_file_config(mpctx);
|
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
#define MP_WATCH_LATER_CONF "watch_later"
|
|
|
|
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
static bool check_mtime(const char *f1, const char *f2)
|
|
|
|
{
|
|
|
|
struct stat st1, st2;
|
|
|
|
if (stat(f1, &st1) != 0 || stat(f2, &st2) != 0)
|
|
|
|
return false;
|
|
|
|
return st1.st_mtime == st2.st_mtime;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool copy_mtime(const char *f1, const char *f2)
|
|
|
|
{
|
|
|
|
struct stat st1, st2;
|
|
|
|
|
|
|
|
if (stat(f1, &st1) != 0 || stat(f2, &st2) != 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
struct utimbuf ut = {
|
|
|
|
.actime = st2.st_atime, // we want to pass this through intact
|
|
|
|
.modtime = st1.st_mtime,
|
|
|
|
};
|
|
|
|
|
2019-12-30 20:28:04 +00:00
|
|
|
if (utime(f2, &ut) != 0)
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2023-05-03 00:29:27 +00:00
|
|
|
static char *mp_get_playback_resume_dir(struct MPContext *mpctx)
|
|
|
|
{
|
2023-10-15 16:00:52 +00:00
|
|
|
char *wl_dir = mpctx->opts->watch_later_dir;
|
2023-05-03 00:29:27 +00:00
|
|
|
if (wl_dir && wl_dir[0]) {
|
|
|
|
wl_dir = mp_get_user_path(mpctx, mpctx->global, wl_dir);
|
|
|
|
} else {
|
|
|
|
wl_dir = mp_find_user_file(mpctx, mpctx->global, "state", MP_WATCH_LATER_CONF);
|
|
|
|
}
|
|
|
|
return wl_dir;
|
|
|
|
}
|
|
|
|
|
2015-05-09 14:21:44 +00:00
|
|
|
static char *mp_get_playback_resume_config_filename(struct MPContext *mpctx,
|
2013-12-21 19:45:19 +00:00
|
|
|
const char *fname)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2015-05-09 14:21:44 +00:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2013-10-29 21:38:29 +00:00
|
|
|
char *res = NULL;
|
|
|
|
void *tmp = talloc_new(NULL);
|
2024-05-05 16:11:00 +00:00
|
|
|
const char *path = NULL;
|
|
|
|
if (opts->ignore_path_in_watch_later_config && !mp_is_url(bstr0(path))) {
|
|
|
|
path = mp_basename(fname);
|
|
|
|
} else {
|
|
|
|
path = mp_normalize_path(tmp, fname);
|
|
|
|
if (!path)
|
|
|
|
goto exit;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
uint8_t md5[16];
|
2024-05-05 16:11:00 +00:00
|
|
|
av_md5_sum(md5, path, strlen(path));
|
2013-10-29 21:38:29 +00:00
|
|
|
char *conf = talloc_strdup(tmp, "");
|
|
|
|
for (int i = 0; i < 16; i++)
|
|
|
|
conf = talloc_asprintf_append(conf, "%02X", md5[i]);
|
|
|
|
|
2023-05-03 00:29:27 +00:00
|
|
|
char *wl_dir = mp_get_playback_resume_dir(mpctx);
|
|
|
|
if (wl_dir && wl_dir[0])
|
|
|
|
res = mp_path_join(NULL, wl_dir, conf);
|
2015-05-09 14:21:44 +00:00
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
exit:
|
|
|
|
talloc_free(tmp);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Should follow what parser-cfg.c does/needs
|
|
|
|
static bool needs_config_quoting(const char *s)
|
|
|
|
{
|
2014-10-16 13:40:19 +00:00
|
|
|
if (s[0] == '%')
|
|
|
|
return true;
|
2014-11-21 04:12:55 +00:00
|
|
|
for (int i = 0; s[i]; i++) {
|
2013-10-29 21:38:29 +00:00
|
|
|
unsigned char c = s[i];
|
2014-07-01 21:10:38 +00:00
|
|
|
if (!mp_isprint(c) || mp_isspace(c) || c == '#' || c == '\'' || c == '"')
|
2013-10-29 21:38:29 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-01-06 21:40:55 +00:00
|
|
|
static void write_filename(struct MPContext *mpctx, FILE *file, char *filename)
|
|
|
|
{
|
2024-02-13 23:10:42 +00:00
|
|
|
if (mpctx->opts->ignore_path_in_watch_later_config && !mp_is_url(bstr0(filename)))
|
|
|
|
filename = mp_basename(filename);
|
|
|
|
|
2016-01-06 21:40:55 +00:00
|
|
|
if (mpctx->opts->write_filename_in_watch_later_config) {
|
|
|
|
char write_name[1024] = {0};
|
|
|
|
for (int n = 0; filename[n] && n < sizeof(write_name) - 1; n++)
|
|
|
|
write_name[n] = (unsigned char)filename[n] < 32 ? '_' : filename[n];
|
|
|
|
fprintf(file, "# %s\n", write_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_redirect(struct MPContext *mpctx, char *path)
|
|
|
|
{
|
|
|
|
char *conffile = mp_get_playback_resume_config_filename(mpctx, path);
|
|
|
|
if (conffile) {
|
|
|
|
FILE *file = fopen(conffile, "wb");
|
|
|
|
if (file) {
|
|
|
|
fprintf(file, "# redirect entry\n");
|
|
|
|
write_filename(mpctx, file, path);
|
|
|
|
fclose(file);
|
|
|
|
}
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
|
2020-01-18 22:39:08 +00:00
|
|
|
if (mpctx->opts->position_check_mtime &&
|
|
|
|
!mp_is_url(bstr0(path)) && !copy_mtime(path, conffile))
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
MP_WARN(mpctx, "Can't copy mtime from %s to %s\n", path, conffile);
|
|
|
|
|
2016-01-06 21:40:55 +00:00
|
|
|
talloc_free(conffile);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
static void write_redirects_for_parent_dirs(struct MPContext *mpctx, char *path)
|
|
|
|
{
|
2024-02-13 23:10:42 +00:00
|
|
|
if (mp_is_url(bstr0(path)) || mpctx->opts->ignore_path_in_watch_later_config)
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Write redirect entries for the file's parent directories to allow
|
|
|
|
// resuming playback when playing parent directories whose entries are
|
|
|
|
// expanded only the first time they are "played". For example, if
|
|
|
|
// "/a/b/c.mkv" is the current entry, also create resume files for /a/b and
|
|
|
|
// /a, so that "mpv --directory-mode=lazy /a" resumes playback from
|
|
|
|
// /a/b/c.mkv even when b isn't the first directory in /a.
|
|
|
|
bstr dir = mp_dirname(path);
|
|
|
|
// There is no need to write a redirect entry for "/".
|
|
|
|
while (dir.len > 1 && dir.len < strlen(path)) {
|
|
|
|
path[dir.len] = '\0';
|
|
|
|
mp_path_strip_trailing_separator(path);
|
|
|
|
write_redirect(mpctx, path);
|
|
|
|
dir = mp_dirname(path);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
void mp_write_watch_later_conf(struct MPContext *mpctx)
|
|
|
|
{
|
2016-01-06 21:40:55 +00:00
|
|
|
struct playlist_entry *cur = mpctx->playing;
|
2014-06-26 17:13:37 +00:00
|
|
|
char *conffile = NULL;
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
void *ctx = talloc_new(NULL);
|
|
|
|
|
2016-01-06 21:40:55 +00:00
|
|
|
if (!cur)
|
2013-10-29 21:38:29 +00:00
|
|
|
goto exit;
|
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
char *path = mp_normalize_path(ctx, cur->filename);
|
2024-05-05 16:11:00 +00:00
|
|
|
if (!path)
|
|
|
|
goto exit;
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
|
2015-03-18 21:13:41 +00:00
|
|
|
struct demuxer *demux = mpctx->demuxer;
|
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
conffile = mp_get_playback_resume_config_filename(mpctx, path);
|
2013-10-29 21:38:29 +00:00
|
|
|
if (!conffile)
|
|
|
|
goto exit;
|
|
|
|
|
2023-05-03 00:29:27 +00:00
|
|
|
char *wl_dir = mp_get_playback_resume_dir(mpctx);
|
2023-05-21 12:03:01 +00:00
|
|
|
mp_mkdirp(wl_dir);
|
2016-09-08 14:50:39 +00:00
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
MP_INFO(mpctx, "Saving state.\n");
|
|
|
|
|
|
|
|
FILE *file = fopen(conffile, "wb");
|
2023-05-21 12:03:01 +00:00
|
|
|
if (!file) {
|
|
|
|
MP_WARN(mpctx, "Can't open %s for writing\n", conffile);
|
2013-10-29 21:38:29 +00:00
|
|
|
goto exit;
|
2023-05-21 12:03:01 +00:00
|
|
|
}
|
2016-01-06 21:40:55 +00:00
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
write_filename(mpctx, file, path);
|
2016-01-06 21:40:55 +00:00
|
|
|
|
2023-01-08 06:16:15 +00:00
|
|
|
bool write_start = true;
|
2024-05-25 19:46:54 +00:00
|
|
|
double pos = get_playback_time(mpctx);
|
2020-01-17 14:26:16 +00:00
|
|
|
|
|
|
|
if ((demux && (!demux->seekable || demux->partially_seekable)) ||
|
|
|
|
pos == MP_NOPTS_VALUE)
|
|
|
|
{
|
2023-01-08 06:16:15 +00:00
|
|
|
write_start = false;
|
2020-01-17 14:26:16 +00:00
|
|
|
MP_INFO(mpctx, "Not seekable, or time unknown - not saving position.\n");
|
|
|
|
}
|
2021-07-21 09:06:41 +00:00
|
|
|
char **watch_later_options = mpctx->opts->watch_later_options;
|
|
|
|
for (int i = 0; watch_later_options && watch_later_options[i]; i++) {
|
|
|
|
char *pname = watch_later_options[i];
|
2023-01-08 06:16:15 +00:00
|
|
|
// Always save start if we have it in the array.
|
|
|
|
if (write_start && strcmp(pname, "start") == 0) {
|
|
|
|
fprintf(file, "%s=%f\n", pname, pos);
|
|
|
|
continue;
|
|
|
|
}
|
2021-07-21 09:06:41 +00:00
|
|
|
// Only store it if it's different from the initial value.
|
|
|
|
if (m_config_watch_later_backup_opt_changed(mpctx->mconfig, pname)) {
|
|
|
|
char *val = NULL;
|
|
|
|
mp_property_do(pname, M_PROPERTY_GET_STRING, &val, mpctx);
|
|
|
|
if (needs_config_quoting(val)) {
|
|
|
|
// e.g. '%6%STRING'
|
|
|
|
fprintf(file, "%s=%%%d%%%s\n", pname, (int)strlen(val), val);
|
|
|
|
} else {
|
|
|
|
fprintf(file, "%s=%s\n", pname, val);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2021-07-21 09:06:41 +00:00
|
|
|
talloc_free(val);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
fclose(file);
|
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
if (mpctx->opts->position_check_mtime && !mp_is_url(bstr0(path)) &&
|
|
|
|
!copy_mtime(path, conffile))
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
{
|
|
|
|
MP_WARN(mpctx, "Can't copy mtime from %s to %s\n", cur->filename,
|
|
|
|
conffile);
|
|
|
|
}
|
|
|
|
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
write_redirects_for_parent_dirs(mpctx, path);
|
|
|
|
|
|
|
|
// Also write redirect entries for a playlist that mpv expanded if the
|
|
|
|
// current entry is a URL, this is mostly useful for playing multiple
|
|
|
|
// archives of images, e.g. with mpv 1.zip 2.zip and quit-watch-later
|
|
|
|
// on 2.zip, write redirect entries for 2.zip, not just for the archive://
|
|
|
|
// URL.
|
|
|
|
if (cur->playlist_path && mp_is_url(bstr0(path))) {
|
|
|
|
char *playlist_path = mp_normalize_path(ctx, cur->playlist_path);
|
|
|
|
write_redirect(mpctx, playlist_path);
|
|
|
|
write_redirects_for_parent_dirs(mpctx, playlist_path);
|
2016-01-06 21:40:55 +00:00
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
exit:
|
2014-06-26 17:13:37 +00:00
|
|
|
talloc_free(conffile);
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
talloc_free(ctx);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
command: add delete-watch-later-config
This introduces the delete-watch-later-config command, to complement
write-watch-later-config. This is an alternative to #8141.
The general problem that this change is attempting to help solve has
been described in #336, #3169 and #6574. Though persistent playback
position of a single file is generally a solved problem, this is not
the case for playlists, as described in #8138.
The motivation is facilitating intermittent playback of very large
playlists, consisting of hundreds of entries each many hours
long. Though the current "watch later" mechanism works well - provided
that the files each occur only once in that playlist, and are played
only via that playlist - the biggest issue is that the position is
lost completely should mpv exit uncleanly (e.g. due to a power
failure). Existing workarounds (in the form of Lua scripts which call
write-watch-later-config periodically) fail in the playlist case, due
to the mechanism used by mpv to determine where within a playlist to
resume playback from.
The missing puzzle piece needed to allow scripts to implement a
complete solution to this problem is simply a way to clean up the
watch-later configuration that the script asked mpv to write using
write-watch-later-config. With that in place, scripts can then
register an end-file event listener, check the stop playback reason,
and in the "eof" and "stop" case, invoke delete-watch-later-config to
delete any saved positions written by write-watch-later-config. The
script can then proceed to immediately write a new one when the next
file is loaded, which altogether allows mpv to resume from the correct
playlist and file position upon next startup.
Because events are delivered and executed asynchronously,
delete-watch-later-config takes an optional filename argument, to
allow scripts to clear watch-later configuration for files after mpv
had already moved on from playing them and proceeded to another file.
A Lua script which makes use of this change can be found here:
https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef
(A modification of the one written by @Hakkin, in that this one takes
advantage of the new command, and also saves the state immediately
when a new file is loaded.)
2020-10-22 16:25:20 +00:00
|
|
|
void mp_delete_watch_later_conf(struct MPContext *mpctx, const char *file)
|
|
|
|
{
|
2024-05-05 16:11:00 +00:00
|
|
|
void *ctx = talloc_new(NULL);
|
|
|
|
char *path = mp_normalize_path(ctx, file ? file : mpctx->filename);
|
|
|
|
if (!path)
|
|
|
|
goto exit;
|
command: add delete-watch-later-config
This introduces the delete-watch-later-config command, to complement
write-watch-later-config. This is an alternative to #8141.
The general problem that this change is attempting to help solve has
been described in #336, #3169 and #6574. Though persistent playback
position of a single file is generally a solved problem, this is not
the case for playlists, as described in #8138.
The motivation is facilitating intermittent playback of very large
playlists, consisting of hundreds of entries each many hours
long. Though the current "watch later" mechanism works well - provided
that the files each occur only once in that playlist, and are played
only via that playlist - the biggest issue is that the position is
lost completely should mpv exit uncleanly (e.g. due to a power
failure). Existing workarounds (in the form of Lua scripts which call
write-watch-later-config periodically) fail in the playlist case, due
to the mechanism used by mpv to determine where within a playlist to
resume playback from.
The missing puzzle piece needed to allow scripts to implement a
complete solution to this problem is simply a way to clean up the
watch-later configuration that the script asked mpv to write using
write-watch-later-config. With that in place, scripts can then
register an end-file event listener, check the stop playback reason,
and in the "eof" and "stop" case, invoke delete-watch-later-config to
delete any saved positions written by write-watch-later-config. The
script can then proceed to immediately write a new one when the next
file is loaded, which altogether allows mpv to resume from the correct
playlist and file position upon next startup.
Because events are delivered and executed asynchronously,
delete-watch-later-config takes an optional filename argument, to
allow scripts to clear watch-later configuration for files after mpv
had already moved on from playing them and proceeded to another file.
A Lua script which makes use of this change can be found here:
https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef
(A modification of the one written by @Hakkin, in that this one takes
advantage of the new command, and also saves the state immediately
when a new file is loaded.)
2020-10-22 16:25:20 +00:00
|
|
|
|
2024-05-05 16:11:00 +00:00
|
|
|
char *fname = mp_get_playback_resume_config_filename(mpctx, path);
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
if (fname) {
|
command: add delete-watch-later-config
This introduces the delete-watch-later-config command, to complement
write-watch-later-config. This is an alternative to #8141.
The general problem that this change is attempting to help solve has
been described in #336, #3169 and #6574. Though persistent playback
position of a single file is generally a solved problem, this is not
the case for playlists, as described in #8138.
The motivation is facilitating intermittent playback of very large
playlists, consisting of hundreds of entries each many hours
long. Though the current "watch later" mechanism works well - provided
that the files each occur only once in that playlist, and are played
only via that playlist - the biggest issue is that the position is
lost completely should mpv exit uncleanly (e.g. due to a power
failure). Existing workarounds (in the form of Lua scripts which call
write-watch-later-config periodically) fail in the playlist case, due
to the mechanism used by mpv to determine where within a playlist to
resume playback from.
The missing puzzle piece needed to allow scripts to implement a
complete solution to this problem is simply a way to clean up the
watch-later configuration that the script asked mpv to write using
write-watch-later-config. With that in place, scripts can then
register an end-file event listener, check the stop playback reason,
and in the "eof" and "stop" case, invoke delete-watch-later-config to
delete any saved positions written by write-watch-later-config. The
script can then proceed to immediately write a new one when the next
file is loaded, which altogether allows mpv to resume from the correct
playlist and file position upon next startup.
Because events are delivered and executed asynchronously,
delete-watch-later-config takes an optional filename argument, to
allow scripts to clear watch-later configuration for files after mpv
had already moved on from playing them and proceeded to another file.
A Lua script which makes use of this change can be found here:
https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef
(A modification of the one written by @Hakkin, in that this one takes
advantage of the new command, and also saves the state immediately
when a new file is loaded.)
2020-10-22 16:25:20 +00:00
|
|
|
unlink(fname);
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
talloc_free(fname);
|
|
|
|
}
|
|
|
|
|
2024-05-05 16:11:00 +00:00
|
|
|
if (mp_is_url(bstr0(path)) || mpctx->opts->ignore_path_in_watch_later_config)
|
|
|
|
goto exit;
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
|
|
|
|
bstr dir = mp_dirname(path);
|
|
|
|
while (dir.len > 1 && dir.len < strlen(path)) {
|
|
|
|
path[dir.len] = '\0';
|
|
|
|
mp_path_strip_trailing_separator(path);
|
|
|
|
fname = mp_get_playback_resume_config_filename(mpctx, path);
|
|
|
|
if (fname) {
|
|
|
|
unlink(fname);
|
|
|
|
talloc_free(fname);
|
|
|
|
}
|
|
|
|
dir = mp_dirname(path);
|
|
|
|
}
|
|
|
|
|
2024-05-05 16:11:00 +00:00
|
|
|
exit:
|
player: always write redirect entries for resuming playback
35f43dfacbe added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
2023-08-27 19:26:44 +00:00
|
|
|
talloc_free(ctx);
|
command: add delete-watch-later-config
This introduces the delete-watch-later-config command, to complement
write-watch-later-config. This is an alternative to #8141.
The general problem that this change is attempting to help solve has
been described in #336, #3169 and #6574. Though persistent playback
position of a single file is generally a solved problem, this is not
the case for playlists, as described in #8138.
The motivation is facilitating intermittent playback of very large
playlists, consisting of hundreds of entries each many hours
long. Though the current "watch later" mechanism works well - provided
that the files each occur only once in that playlist, and are played
only via that playlist - the biggest issue is that the position is
lost completely should mpv exit uncleanly (e.g. due to a power
failure). Existing workarounds (in the form of Lua scripts which call
write-watch-later-config periodically) fail in the playlist case, due
to the mechanism used by mpv to determine where within a playlist to
resume playback from.
The missing puzzle piece needed to allow scripts to implement a
complete solution to this problem is simply a way to clean up the
watch-later configuration that the script asked mpv to write using
write-watch-later-config. With that in place, scripts can then
register an end-file event listener, check the stop playback reason,
and in the "eof" and "stop" case, invoke delete-watch-later-config to
delete any saved positions written by write-watch-later-config. The
script can then proceed to immediately write a new one when the next
file is loaded, which altogether allows mpv to resume from the correct
playlist and file position upon next startup.
Because events are delivered and executed asynchronously,
delete-watch-later-config takes an optional filename argument, to
allow scripts to clear watch-later configuration for files after mpv
had already moved on from playing them and proceeded to another file.
A Lua script which makes use of this change can be found here:
https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef
(A modification of the one written by @Hakkin, in that this one takes
advantage of the new command, and also saves the state immediately
when a new file is loaded.)
2020-10-22 16:25:20 +00:00
|
|
|
}
|
|
|
|
|
2023-07-07 16:09:36 +00:00
|
|
|
bool mp_load_playback_resume(struct MPContext *mpctx, const char *file)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2023-07-07 16:09:36 +00:00
|
|
|
bool resume = false;
|
2015-05-09 14:21:44 +00:00
|
|
|
if (!mpctx->opts->position_resume)
|
2023-07-07 16:09:36 +00:00
|
|
|
return resume;
|
2015-05-09 14:21:44 +00:00
|
|
|
char *fname = mp_get_playback_resume_config_filename(mpctx, file);
|
2013-10-29 21:38:29 +00:00
|
|
|
if (fname && mp_path_exists(fname)) {
|
2020-01-18 22:39:08 +00:00
|
|
|
if (mpctx->opts->position_check_mtime &&
|
2020-01-26 13:29:48 +00:00
|
|
|
!mp_is_url(bstr0(file)) && !check_mtime(file, fname))
|
|
|
|
{
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
talloc_free(fname);
|
2023-07-07 16:09:36 +00:00
|
|
|
return resume;
|
player: Optionally validate st_mtime when restoring playback state
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
2019-11-09 18:24:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
// Never apply the saved start position to following files
|
2013-12-21 19:45:19 +00:00
|
|
|
m_config_backup_opt(mpctx->mconfig, "start");
|
|
|
|
MP_INFO(mpctx, "Resuming playback. This behavior can "
|
2013-10-29 21:38:29 +00:00
|
|
|
"be disabled with --no-resume-playback.\n");
|
2018-01-11 22:50:44 +00:00
|
|
|
try_load_config(mpctx, fname, M_SETOPT_PRESERVE_CMDLINE, MSGL_V);
|
2023-07-07 16:09:36 +00:00
|
|
|
resume = true;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
talloc_free(fname);
|
2023-07-07 16:09:36 +00:00
|
|
|
return resume;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Returns the first file that has a resume config.
|
|
|
|
// Compared to hashing the playlist file or contents and managing separate
|
|
|
|
// resume file for them, this is simpler, and also has the nice property
|
|
|
|
// that appending to a playlist doesn't interfere with resuming (especially
|
|
|
|
// if the playlist comes from the command line).
|
2013-12-21 19:45:19 +00:00
|
|
|
struct playlist_entry *mp_check_playlist_resume(struct MPContext *mpctx,
|
|
|
|
struct playlist *playlist)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2013-12-21 19:45:19 +00:00
|
|
|
if (!mpctx->opts->position_resume)
|
2013-10-29 21:38:29 +00:00
|
|
|
return NULL;
|
2019-12-28 20:12:02 +00:00
|
|
|
for (int n = 0; n < playlist->num_entries; n++) {
|
|
|
|
struct playlist_entry *e = playlist->entries[n];
|
2015-05-09 14:21:44 +00:00
|
|
|
char *conf = mp_get_playback_resume_config_filename(mpctx, e->filename);
|
2013-10-29 21:38:29 +00:00
|
|
|
bool exists = conf && mp_path_exists(conf);
|
|
|
|
talloc_free(conf);
|
|
|
|
if (exists)
|
|
|
|
return e;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|