Protocol specifications?

Submitted by fagga on Fri, 2008-08-22 21:25

Forums:

I'm currently learning Python and in this process, I'm re-writing mocstat (the Perl script that puts 'currently playing'-information on my desktop via Conky). I'm still getting information from MOC via `mocp --info`, which is either very cpu intensive or very inaccurate, depending on the delay. So I would like to ask the MOC server directly via the socket about playing information, just like the interface does.
Is there any information about the protocol anywhere? I couldn't find anything.
If the protocol isn't documented, could you provide some information about what to send and how to receive the answer, so I could get the same information from the socket as I get from `mocp --info`? I tried to read the sources, but my C skills are too weak, so any information would be appreciated.

fagga

Wed, 2008-08-27 14:18

After hours of trial and error I somehow managed to catch events like EV_CTIME and EV_STATE. Even requesting and reading the current file and state works fine.
But the most important thing, the tags of the currently playing song, doesn't work at all.
When I send CMD_GET_TAGS to the server, I get EV_DATA (as expected) followed by data. I expect this data to be some kind of string, but it's always the same bunch of nonsense: 12 times 0x0, 8 times 0xff and 4 times 0x0 again.
Maybe I'm reading it wrong? But wouldn't it have to change anyhow when I'm playing different songs? How does this represent tag data?
Any help would be greatly appreciated.

hiben

Wed, 2008-08-27 18:00

According to protocol.c (line 275ff, packet_buf_add_tags) that exactly describes the situation for 'no tags available'. Three empty strings preceded by their length (4 times 0 as a 32bit integer 0x00000000 makes 12 bytes 0x0). String of length zero is just nothing. Then you get two times -1 (0xFFFFFFFF) (no track, no time) plus one time zero (not filled flag, 0x00000000).

Is this helpful to you ?

fagga

Wed, 2008-08-27 22:59

First: Thank you. I was really stuck there.

This is helpful indeed. Now I know what moc tells me. Looking at what `mocp --info` does (line 3594; interface.c) might indicate that I'm using the wrong command, as CMD_GET_TAGS is only used when the file type of the currently playing file equals to F_URL. Does that mean, CMD_GET_TAGS is only used for internet streams?

That would mean that I have to use CMD_GET_FILE_TAGS. I tried that before and the server dumped me for my request. I think it's because I'm doing something wrong when sending the file name. Is a char in C one byte long? And how long is it in Python? How do I do byte crafting in Python anyhow?
I think I have to read some more documentation.

hiben

Thu, 2008-08-28 10:26

As far as I understand it, for files you have to use the CMD_GET_FILE_TAGS command. followed by the length of the string as a 32bit integer and then the character data (without terminating zero).
After that you need to specify the wanted tags (time and/or comment) (32bit).
If you sent the terminating zero (if there is such a thing in python, there is in C), the request would be illegal because this would result in a strange tags specification.
In C and Python, strings are composed of 8bit integers. Python also has unicode strings. They are formed by typing u'my string' (leading u).
If you don't use unicode strings you should be able to just write the string to the socket - maybe you need to check for that terminating zero...
I'm not sure how Python can do explicit type casting.

Good luck :-)

fagga

Thu, 2008-08-28 14:35

Thanks, again.

Byte crafting in Python is done via unpack() and pack(). Now the server never stops talking to me. (:

Next thing to do is putting everything in shape. I think, I'm putting this into a Python module. When it looks usable, I'm gonna post it here.

teto

Sun, 2014-01-26 01:31

Any news on that ? I was starting an implementation but maybe there is no need to if you already got sthg ?

fagga

Sun, 2014-01-26 12:14

You mean you want to implement a proper API?

I'm not particularly interested personally anymore (I still use MOC but the curses interface is enough), but I'm pretty sure others would use it. Conky, for example, provides moc_* variables by calling `mocp --info` every second.

An API could also encourage different user interfaces, which is always a good thing.

Just my 2 cents.

Thanks for getting back to me!

teto

Sun, 2014-01-26 20:26

Thanks for the answer.
I managed to retrieve the state of the server from python but there are problems I wish I could get a few hints (this is more addressed to the developer I guess). Here is my setup:
-I run mocp -F in a terminal (1)
-in another terminal (2) I run mocp (with curses GUI)
-in a third one (3) I run my python script (a real mess https://github.com/teto/mocpy/blob/master/test.py)

When I start playing a song via term 2, I would like to retrieve the event in the python script (term 3 ) but it looks as if it is not broadcasted. Also I noticed that if I launched some commands from the script, I could not do anything anymore in term 2 :/
Why is that ?

jcf

Sun, 2014-01-26 21:32

If your script remains connected and listening to the server in the same way that a client would, then it should receive events to indicate changes in the server's state. It seems to me that if neither your script nor the client you started in step 2 are behaving then that may be coming from a common cause. You should check the server log for any problems the server may have had in interpreting your script's requests.

However, MOC was not designed with the intention of it being used with clients other than the tightly-bound one provided. That's not an area I intend to look at until MOC 2.9 (if we ever get there).