status plugin working, but odd slow refresh times for song info

Submitted by linux_user on Sun, 2019-04-14 09:31

Forums:

Running i3 on Manjaro with py3status and the moc plugin script. All working fine - machine boots up, loads moc etc.

I have created a simple module that just shows the artist and songtitle. Clicking on it toggles the play/pause state of moc, and logging in anew the status info shows the (correct) restored state on pause.

If I now click on the plugin the song resumes playing - as intended - but there's this odd delay of about ten seconds where the status block goes blank before refreshing the text. Ditto if I now toggle again i.e. pause - the song correctly pauses but again the lengthy delay with a blank module.

Is this something to do with refresh times? Or is it some process messaging between the plugin and the server? Is there any way to fix this?

Note that I installed mpd further to the Arch pages and thus it's running as a --user session. As such I'm not serving music anywhere else and there's just this computer connected.

Any help or suggestions appreciated :)

jcf

Sun, 2019-04-14 10:42

There are a number of components involved in what you describe, and I'm not familiar with all of them. It's the sort of problem which will probably require some instrumentation to narrow down possible causes.

However, the thing which springs to mind is that the delay may be due to having to read the audio file to get the artist and song title tags. Some decoders are faster at this than others, and the MP3 format in particular may have tags anywhere within the file so the whole file has to be read.

There are some reservations about that theory which would need to be explored further. If tags caching is in effect, then that should minimise the delay if the information is being requested from the same MOC instance which is doing the playing (as it will have already read the tags)... and assuming that the underlying database response time is not being compromised by some other hardware or software component, or being performed over a slow network. That the delay also happens on resuming playing from a paused state also casts some doubt on this theory.

One thing you could do is run the MOC server with debugging turned on (the -D option) and checking the time elapsed between the receipt of the tags request and the sending of the response.

Anyway, I hope that provides some clues for further investigation.

linux_user

Sun, 2019-04-14 11:29

thank you - a very helpful reply that helps me to think more clearly about the problem.

A few further observations/clarifications before I dig in, if you don't mind:

So that it's crystal clear to me, by 'server' do I take it that this does indeed refer to the server/client relationship within this - the same machine? Do I understand correctly that mpd is running as a daemon 'serving' the file information, and that moc (in fact mocp as the graphical interface) is the 'client'? I ask simply because as I tried to make clear in my initial post, it's just the music on my local disk that I'm playing - there are no external networks of any kind involved.

Next: I 'fixed' the problem temporarily by setting the `sleep_timeout=0` in the py3status module and now the status block refreshes within the `cache_timeout` period, which I set to 1. Again, I may be misunderstanding the intended use of these parameters.

Tag caching appears to be set within moc, as there's nothing in the mpd configs to suggest that. I erred on the side of cautious when setting up the config because there's a lot of stuff in that file about how it doesn't support UTF-8, and the various options to enforce or convert to/from Windows and ISO-8859-1. I understood that best I could, but since my ENTIRE music library lives on an ext4 disc, and I happen to like using diacritics and question marks etc. in my song titles, I've rather shied off those settings. To that extent, the option `read_tags=no` is set because when I did so, my song titles appear in the mopc window with the track number appended, and I didn't find a way to edit those out. So yes, instead of it simply reading {title} it reads {artist} - {songtitle} but that said, obviously I'm not certain why it should take many seconds to read information that's already on the disc.

FYI I have a system monitor running on my task bar. It barely ever creeps above 1% during normal use. This may be an old machine (2011) but it is a quad-core i7 running at 920gHZ with 12GB of DDR3 RAM... so I'm not expecting any significant overheads in hardware terms :)

If you still feel I need to turn on debugging I shall do so.

Thanks for your help.

tomaszg

Sun, 2019-04-14 14:57

How did you connect MOC and MPD? They are in principle not related. If I understand correctly, your plugin activates some MOC commands. Did you try issuing those commands manually to see if there is the same delay?

linux_user

Sun, 2019-04-14 15:28

Aha! I think you may have helped me chase this down. I think I've made a noob error...

I followed the instructions and got mpd set up correctly. It now runs every session no problems.

I thought I'd read somewhere that mocp is 'a front end for moc'... so, when I ran that in my terminal and out popped a lovely looking screen... a few tweaks later and I've bound a key to start mocp... and then with the plugin - well, I assumed that moc and mocp were pointing at the same thing! Errr... it seems not because when I tried to cmd the player (mocp) it came back with a COMPLETELY different song than the one showing in the status bar (but controlled by it!

Umm... Since the plugin is for moc, am I accidentally running two players?? And, when I ran the cmd, the output from my plugin disappeared. Now it's blank.

linux_user

Sun, 2019-04-14 15:49

just fyi: double checked everything. Checked my configs, reread the user manual. Now back to a regular outcome:

I have a SINGLE instance running. I have output shown in my status bar. If I use the i3 key bind, it launches mocp and points at the same track. Phew!

And so back to my original question: I've had to disable the "sleep_timeout" by setting it to zero in order for the module to update within the second. Otherwise it defaults to a 20 second blank output whenever there's a state change. Same if I control the player via cmd.

tomaszg

Sun, 2019-04-14 20:09

Binary name for player "MOC" is "mocp". Binary named "moc" is something completely separate, it is related to QT libraries. Moreover "mpd" is unrelated to any of those. You don't need to set it up to use MOC.

MOC itself has both client and server component but they are started by the same command: "mocp". With various command line switches you can make it start only the server, if you would need it.

jcf

Sun, 2019-04-14 20:30

It sounds like you're getting quite confused between several applications.

QT Metaobject Compiler has the executable name moc and is an unrelated application.

Music On Console (MOC - which is what we support) has the executable named mocp. This was done because the executable name moc was already in use by the QT Metaobject Compiler.

Music Playing Daemon (MPD) is another music player which is unrelated to MOC. (I did notice your use of 'mpd' in your initial post but had assumed it was a typo or as aside to the main topic.)

I suspect that some of the plugins you are using may not be designed to work with MOC, but we don't directly support them anyway.

The configuration options you mention (sleep_timeout and cache_timeout) are not MOC configuration options and you will have to address questions relating to their use to the py3status module maintainers.

ReadTags is a MOC configuration option, but read_tags is not.

I think with that understood you'll be able to work things out, but either way get back to us with an update.

linux_user

Tue, 2019-04-16 22:11

Well, sincere thanks everyone for helping clear up my confusion. Yes, probably far too many hours spent configuring a new install and all the sentences start blurring together! ;)

Anyway, extremely helpful to me to shed any confusion/overlap between terms. It's all very clear to me now thanks. Also very helpful to understand the my initial query that brought me here is in any case entirely under the remit of the folks developing the status bar and nothing directly to do with your player, so I can just let that go and either use or not use that plugin.

The only thing left now is to discover whether I can essentially structure the layout of mocp exactly as I wish. I've enabled the third of the three enclosed layouts, but none of them are satisfactory. The ONLY thing that even took me down the road of mpd/client (ncmpcpp) was the ability to structure the entire interface. Mocp seems to be only very basic. With about 5000 complete albums plus individual tracks, I need something less 'linear' than scrolling through a massive file list, despite there's a very efficient search function. That said though (and strictly speaking that's off topic) I'm happy to have arrived at sufficient understanding to progress from here :)

tomaszg

Tue, 2019-04-16 22:32

Glad we could help.

Considering layout - I suspect that you would like to something like a library with a way of filtering by tags? That indeed is not possible within MOC. Myself I just structure my data on disk in a hierarchical manner, so I can find anything I need reasonably fast. Adding symlinks to the mix makes it even better.