mocd loads all modules, even if used as remote for moc

Submitted by lolren on Tue, 2020-07-21 14:25

Forums:

MOC version: 
2.6 alpha

It`s there a way to make "mocd -f " for example, to control a running session of moc , start faster? I want to create a car mp3 player using a raspberry pi zero, and moc is loading every decoder module even if i just use it for changing a song, for example. Maybe if i use the option -O to override module loading when for example i just wanna change song, but I cannot find this option. Please help

tomaszg

Tue, 2020-07-21 14:46

I think moc loads modules only once - when server starts. When you use mocp -f to change song, new instance of moc only connects to the existing client to ask it to do the work. How can you tell it is loading every decoder?

lolren

Tue, 2020-07-21 15:46

Simple. By using the debug switch ( mocp -D -f) . Deleting libffmpeg_decoder.so module file made it a bit faster, but not fast enough for the Zero. But, it should be an option to load only the remote part of mocp, or automatically do that when it detects a remote need only.

tomaszg

Tue, 2020-07-21 16:36

You're right. I didn't look at the code. Just tried a little experiment and it seems that it should be possible to optimize sending commands to moc server. You can try to apply this patch to source code and see if it solves your problem. I don't know though if it doesn't break something else. From my tests basic functions work, but adding files (-a -l -q) is broken. It is possible to hack it to work but by complicating the code a bit. Maybe the code should be reworked a bit to move processing of these options to the server...

This solution is only partial. It seems that each moc client maintains their separate instance of decoders. So, even with the simple setup of one interface, we have decoders getting initialized twice (for client and for server). They should probably share it.

diff --git a/main.c b/main.c index f7425e5..7ea205a 100644 --- a/main.c +++ b/main.c @@ -1256,21 +1256,22 @@ int main (int argc, const char *argv[]) check_moc_dir (); - io_init (); - rcc_init (); - decoder_init (params.debug); - srand (time(NULL)); - if (params.allow_iface) + if (params.allow_iface) { + io_init (); + rcc_init (); + decoder_init (params.debug); + srand (time(NULL)); start_moc (&params, args); + lists_strs_free (args); + decoder_cleanup (); + io_cleanup (); + rcc_cleanup (); + } else server_command (&params, args); - lists_strs_free (args); options_free (); - decoder_cleanup (); - io_cleanup (); - rcc_cleanup (); files_cleanup (); common_cleanup ();

lolren

Tue, 2020-07-21 17:10

I don`t have much experience with patching files. What I`ve did, was to change the code posted by you in a file .ptch and do a patch < file.patch .Sadly, I get the following error : " Hunk #1 FAILED at 1256". This is not the only patch I`m applying before the build, I`m also applying a alsa patch to see my hifiberry card , acording to this post "https://moc.daper.net/node/2224". I appreciate all your help. Thank you

tomaszg

Tue, 2020-07-21 17:25

It should be enough to add -p0 option to patch (the same thing was needed in the ALSA patch).

lolren

Tue, 2020-07-21 17:29

I did it manually, by editing the file "main.c" in a text editor and save it. I`m compiling it now. Hope it workd :D

lolren

Tue, 2020-07-21 17:49

Maybe I did something wrong. My section looks like this now:
[code]
check_moc_dir ();
if (params.allow_iface) {
io_init ();
rcc_init ();
decoder_init (params.debug);
srand (time(NULL));
start_moc (&params, args);
lists_strs_free (args);
decoder_cleanup ();
io_cleanup ();
rcc_cleanup ();
}
else
server_command (&params, args);

/*
io_init ();
rcc_init ();
decoder_init (params.debug);
srand (time(NULL));

if (!params.only_server && params.dont_run_iface)
server_command (&params, args);
else

start_moc (&params, args);

lists_strs_free (args);
options_free ();
decoder_cleanup ();
io_cleanup ();
rcc_cleanup ();
files_cleanup ();
common_cleanup ();
*/
return EXIT_SUCCESS;
}

lolren

Tue, 2020-07-21 18:26

Thank for the replies. I understand it more now. If i get any bugs , i will post them. I i cannot get it to work as it should, I will try to strip main.c , compile the whole thing, and use the binary as a remote for the full mocp. Thank you a lot:D

lolren

Tue, 2020-07-21 18:32

I know is a bit of a hack, but it`s working, I`ve compiled a stripped down of main.c, took the resulting binary, and use it only as a remote to a full existing mocp server. it works faster. I still believe that I can make it a bit faster by stripping down more code from it , but it`s a huge improvement. Thank you for everything, once again!

tomaszg

Tue, 2020-07-21 18:41

You should have removed the lines which started with "-". The relevant section should read:

if (params.allow_iface) { io_init (); rcc_init (); decoder_init (params.debug); srand (time(NULL)); start_moc (&params, args); lists_strs_free (args); decoder_cleanup (); io_cleanup (); rcc_cleanup (); } else server_command (&params, args); options_free (); files_cleanup (); common_cleanup (); return EXIT_SUCCESS;

lolren

Tue, 2020-07-21 18:58

At first i`ve commented out the lines with - in front. Now , Ive remove them. Now, I`m trying to undestand the code, to strip everything not related with the remote part. The Pi Zero is a slow machine, so every little helps. At the moment, without loading the decoder modules, I get about 500ms to execute a command, like changind a song. Doing that in the interface is instant.

tomaszg

Wed, 2020-07-22 06:21

That's surprisingly long. I'm running MOC on low-end TP-link router and it takes around 200-500ms on average to run mocp -f - even without changes to the code. I would think that RPi would be much faster.

Some tips: As to the binary size, you can try stripping the binary (and plugins as well). Smaller size might speed up things a bit. Did you use optimization -O2? Maybe some linking flags like -Wl,--as-needed would do some good? Also, maybe you don't need other plugins than ffmpeg, as it should handle almost everything (as long as it works...).

jcf

Tue, 2020-07-21 21:26

I had already identified this as an issue and it is on my internal TODO list.

lolren

Wed, 2020-07-22 00:50

The reason that most people use Moc is size and lightweight. It makes sense to run on small sbc. A smaller binary file just as remote makes sense. At the moment, i`m working on that, but stripping everything to the core. Hope this goes somewhere. The current binary for mocp has 1.4 and is a bit to much for something like the pi zero. Regards