Error: INTERNAL SERVER ERROR when running GET /api/v1/viewer_current_asset

Hi.

New here. I’m playing around with the APIs trying to use a Python script to interact with Anthias.

All other API endpoints seem to work other than the “GET ​/api​/v1​/viewer_current_asset” which gives me a 500 Internal Server error:

admin@anthias:~ $ curl -X GET "https://192.168.1.176/api/v1/viewer_current_asset" -H "accept: application/json"

returns the output:

{"error": ""}

When I check the API via http://192.168.1.176/api/docs/#/ and try to execute I see:

|Code|Details|
| --- | --- |
|500

*Undocumented*|Error: INTERNAL SERVER ERROR

##### Response body

{“error”: “”}

Every other API endpoint that I’ve tried gives me a 200 response.

I’m a bit of a noob so could be doing something stupid/obvious, apologies in advance if so.

Any help/advice would be appreciated.

@thedelph,

  • If the host machine where you’re running the curl command is connected to the same network where the Pi device is connected, you should be fine.
  • Tweak your curl command to use http. https is not functional at the moment.
  • Have you properly installed Anthias? If yes, I’d like to know how you installed it. (Were you able to upload and view assets.)
  • Are you able to view the web UI from the browser?
  • I tried running a similar command and got the following.
$ curl -X GET "http://raspberrypi4/api/v1/viewer_current_asset"
{
  "asset_id": "a80b41ec8c3a41c99c1c132f32812bd0",
  "name": "bbb_sunflower_1080p_30fps_normal.mp4",
  "uri": "/data/screenly_assets/a80b41ec8c3a41c99c1c132f32812bd0.mp4",
  "start_date": "2024-04-01T19:37:00+00:00",
  "end_date": "2024-05-01T19:37:00+00:00",
  "duration": "634",
  "mimetype": "video",
  "is_enabled": 1,
  "is_processing": 0,
  "nocache": 0,
  "play_order": 0,
  "skip_asset_check": 0,
  "is_active": 1
}
  • Don’t be afraid to ask questions, even if you think it’s obvious. We just need to keep the discussion going, so that the issue can be resolved.
  • Can you get the logs from the server by running: docker logs -f screenly-anthias-server-1. See this GitHub doc for details.

Hope to hear back from you.

I am having the same problem on version : production@d12df55

found this in syslog

Apr  9 14:58:03 copperclockwifi python[1015]: Traceback (most recent call last):
Apr  9 14:58:03 copperclockwifi python[1015]:   File "/home/pi/screenly/server.py", line 690, in api_view
Apr  9 14:58:03 copperclockwifi python[1015]:     return view(*args, **kwargs)
Apr  9 14:58:03 copperclockwifi python[1015]:   File "/usr/local/lib/python2.7/dist-packages/flask_restful_swagger_2/swagger.py", line 219, in inner
Apr  9 14:58:03 copperclockwifi python[1015]:     return f(self, *args, **kwargs)
Apr  9 14:58:03 copperclockwifi python[1015]:   File "/home/pi/screenly/server.py", line 1581, in get
Apr  9 14:58:03 copperclockwifi python[1015]:     collector_result = collector.recv_json(2000)
Apr  9 14:58:03 copperclockwifi python[1015]:   File "/home/pi/screenly/settings.py", line 216, in recv_json
Apr  9 14:58:03 copperclockwifi python[1015]:     raise ZmqCollectorTimeout
Apr  9 14:58:03 copperclockwifi python[1015]: ZmqCollectorTimeout

Changing to http does not help, and all other /v1/ requests return 200 just not the viewer_current_asset ?

It’s weird that it works on some devices and doesn’t on others. Glad you pointed this out, thanks.
Expect fixes in the near future (in a few days or weeks). Looks like 2000ms is not enough in some cases.
One way of getting around with it is to increase the timeout.

How the API docs is being served needs to be fixed as well.

Increasing the timeout to 50000 still does not resolve the issue

Apr 10 09:56:04 copperclockwifi python[965]: Traceback (most recent call last):
Apr 10 09:56:04 copperclockwifi python[965]:   File "/home/pi/screenly/server.py", line 690, in api_view
Apr 10 09:56:04 copperclockwifi python[965]:     return view(*args, **kwargs)
Apr 10 09:56:04 copperclockwifi python[965]:   File "/usr/local/lib/python2.7/dist-packages/flask_restful_swagger_2/swagger.py", line 219, in inner
Apr 10 09:56:04 copperclockwifi python[965]:     return f(self, *args, **kwargs)
Apr 10 09:56:04 copperclockwifi python[965]:   File "/home/pi/screenly/server.py", line 1581, in get
Apr 10 09:56:04 copperclockwifi python[965]:     collector_result = collector.recv_json(50000)
Apr 10 09:56:04 copperclockwifi python[965]:   File "/home/pi/screenly/settings.py", line 216, in recv_json
Apr 10 09:56:04 copperclockwifi python[965]:     raise ZmqCollectorTimeout
Apr 10 09:56:04 copperclockwifi python[965]: ZmqCollectorTimeout

I am having the same issue with HTTP as with HTTPS. It’s re-assuring to know that others are having the issue and it’s not just something I’m doing wrong!

Any fix in the pipeline?

@thedelph, I haven’t gone back to it yet. I still can’t reproduce the issue on my end.

Hi tyronemc2.

I don’t suppose you have found a workaround for this yet?

I’d be interested to hear about it.

Kind regards.

Hopefully one will come soon. This API endpoint is really the only one I’m interested in using and unfortunately it’s the only one that doesn’t work for me.