atvscript cli

[nfreeze]

What feature would you like?

Hello, thank you for your excellent work on this project. It would be great if there was a "cli" mode for atvscript similar to atvremote so that calls were faster and could be interacted via another process. Currently running atvscript per-command is pretty slow. When you run atvremote cli calls are almost instant.

Describe the solution you'd like

atvscript cli

Any other information to share?

No

[postlund]

Can absolutely be implemented, should be quick and more out less code re-use from atvremote..

Edit: I'll look into it as time allows.

[postlund]

As atvscript implants very few commands, I would have to add support for the ones missing. Are there any commands in particular you are interested in?

[nfreeze]

I think mainly the ones that return data like playing, app and artwork.

[postlund]

Both playing and app are printed when using push_updates, I would recommend to use that. Current state is however not printed when starting the script, that's something that could be added. Is that good enough?

Artwork is tricker as an image is (relatively) large and would have to be printed in base64 format. An alternative would be to save it to file, but I'm not sure how you intend to use this?

[nfreeze]

Yes, perfect! Thank you! Currently I am spawning a child process from node.js and piping requests / reading responses from atvremote cli. This works pretty well but the text is unstructured and I am worried about the format changing and breaking my parser. When the process starts I query playing and app so if those were emitted automatically in atvscript push_updates I think that would work. The artwork is used to show a thumbnail of the currently playing media. I tried atvremote artwork but wasn't sure of the current format.

[postlund]

That I can fix quite easily. It should have been default behavior from start anyways.

I will have to think a bit regarding artwork as I suspect the output will be too big. An easy workaround is to use atvremote artwork. The API provides mimetype, which atvremote ignores (and just writes the file). Currently there are no other file formats used than PNG, so you will always get that. To ensure compatibility I would add flag to atvremote to keep original format, but by default convert to PNG if necessary. So that should be future proof for you as well. A tip is that you can look at the hash field in playing data and only fetch new artwork if that changes (and even cache based on that if you like). Also note that you can pass width and height like so atvremote ... artwork=100,200 to get a smaller image. Use -1 as one of the sizes to maintain aspect ratio. Output file will always be artwork.png.

[nfreeze]

When I do atvremote artwork_save it produces a 0 byte file on Ubuntu 22.04 (even though running atvremote artwork right before produces a large output which looks like image info)

I will give atvremote artwork another try. Thanks again!

[postlund]

It should work as long as artwork is available for what you are currently watching, but there can of course be bugs.

[postlund]

I believe I was wrong regarding not printing the initial state when starting atvscript: you should get what is currently playing printed at start. Is that good enough? Not sure what to do about artwork currently though. If you can reproduce the problem you are seeing (empty artwork file when using artwork_save) and provide some logs, I can take a look.

[nfreeze]

Yes, that works! I will see if I can track down the issue with the artwork or provide better detail.