[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No next track in playlist

From: Arthur Miller
Subject: Re: No next track in playlist
Date: Thu, 07 Jan 2021 08:02:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Mike Kazantsev <mk.fraggod@gmail.com> writes:

> On Wed, 06 Jan 2021 23:21:10 +0100
> Arthur Miller <arthur.miller@live.com> wrote:
>> Mike Kazantsev <mk.fraggod@gmail.com> writes:
>> > Try setting (setq emms-player-mpv-debug t) and checking what it says in
>> > the Messages buffer, maybe send it here, if it's unclear what's the
>> > problem there.  
>> I set emms-player-mpv-debug but I see nothing different in messages.
>> Does debug info goes elsewhere?
> ...
>> It plays fine; so I guess it is something to my emms mpv configuration.
> No, should be checked in emms-player-mpv-debug-msg calls, so enabling it
> anytime and doing anything mpv-related should produce some output there.
> As it does not, guess player backend from emms-player-mpv never runs,
> so guess it should be an issue elsewhere.
>> > You can customize binary/path and other startup parameters in
>> > emms-player-mpv customization group interactively, or via
>> > custom-set-variables for emms-player-mpv-command-name,
>> > emms-player-mpv-parameters, emms-player-mpv-environment, etc
>> > (all should be listed under that group, and at the top of .el file too).  
>> Ok, I have simplified the setup, removed all custom paths and
>> unnecessary stuff; now there is just "mpv" part to it.
>> Above start-process call plays fine, yet when I run setup
>> below I still get no-next-track message.
> ...
>>               (setq-default emms-player-list '(emms-player-mpv)
>>                             emms-player-mpv-ipc-method t
> emms-player-mpv-ipc-method should not be t, it is defined as:
>   (defcustom emms-player-mpv-ipc-method nil
>     "Switch for which IPC method to use with mpv.
>   Possible symbols: detect, ipc-server, unix-socket, file.
>   Defaults to nil value, which will cause `emms-player-mpv-ipc-detect'
>   to pick one based on mpv --version output.
>   Using JSON-IPC variants (ipc-server and unix-socket) enables
>   support for various feedback and metadata options from mpv."
>     :type '(choice
>       (const :tag "Auto-detect from mpv --version" nil)
>       (const :tag "Use --input-ipc-server JSON IPC (v0.17.0 2016-04-11)" 
> ipc-server)
>       (const :tag "Use --input-unix-socket JSON IPC (v0.7.0 2014-10-16)" 
> unix-socket)
>       (const :tag "Use --input-file FIFO (any mpv version)" file))
>     :group 'emms-player-mpv)
> And that's kinda why you might want to use custom-set-variables for
> anything defcustom - pretty sure it should give you an error for such
> invalid value.
> And furthermore, using setq for something like
> emms-player-mpv-update-metadata will not run the :set hooks there,
> and won't do anything, so again, shouldn't use setq for these.
>> Debug flag does not give me much: this is what I get from a freshly
>> started Emacs in *Messages* after running emms on a directory:
> ...
>> It shouldn't matter that I have my configuration in eval-after-load (or
>> rather with-eval-after-load macro), right?
> Yeah, don't think it should matter, and given that debug output is
> missing, I'd suspect that for some reason backend is just not used -
> maybe some issue with playlist and tracks there?
> Not sure what it might be, and I'd probably open emms-player-mpv.el
> at this point and try adding e.g. (error "is this working?") as first
> line in emms-player-mpv-start function, eval it like that, make sure
> it's not just an issue with debug logging, and maybe go check emms.el
> in a similar fashion from there.
> There probably are more efficient ways to debug code than such
> printf-lines, and that's just my go-to with an arbitrary code.

I have found the error; was elsewhere in my config.

Emms itsels work just fine with only:

              (setq-default emms-player-list '(emms-player-mpv))

I am generating some code for my init file, and I happened to stream one
extra funcall I shouldn't :-). That one was really annoying to find.

Anyway; thanks for the help!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]