2020-10-21, 06:22
Does the time required for processing an XBMC.GetInfoLabels request differ depending upon the type of (audio) file being played back?
I ask since I have a "front panel" standalone Python script that, at least currently, has a polling loop in which it uses JSON-RPC requests to get track information and artwork. The artwork is only retrieved once, at the start of playback for a track. (I've verified that several times.) I also commented out a Player.GetProperties Request I was using to get percentage-done. The difference in time still persists, though.
mp3 playback
2020-10-20 22:07:49.763438 Elapsed time is 0:00:00.014268
2020-10-20 22:07:50.678853 Elapsed time is 0:00:00.014201
2020-10-20 22:07:51.593449 Elapsed time is 0:00:00.013398
2020-10-20 22:07:52.509022 Elapsed time is 0:00:00.014374
2020-10-20 22:07:53.423423 Elapsed time is 0:00:00.013982
flac playback
2020-10-20 22:07:12.490034 Elapsed time is 0:00:00.377940
2020-10-20 22:07:13.758048 Elapsed time is 0:00:00.366812
2020-10-20 22:07:15.041331 Elapsed time is 0:00:00.382096
2020-10-20 22:07:16.305848 Elapsed time is 0:00:00.363306
2020-10-20 22:07:17.573553 Elapsed time is 0:00:00.366486
2020-10-20 22:07:18.827768 Elapsed time is 0:00:00.353025
There's a >25x difference.
The update_display() loop is querying the active players, getting several MusicPlayer labels, and rendering a Pillow image for display on an LCD. A sleep statement tries to ensure that the polling occurs roughly once a second.
I'll get rid of everything put the JSON-RPC polling itself and see if the time difference persists.
I ask since I have a "front panel" standalone Python script that, at least currently, has a polling loop in which it uses JSON-RPC requests to get track information and artwork. The artwork is only retrieved once, at the start of playback for a track. (I've verified that several times.) I also commented out a Player.GetProperties Request I was using to get percentage-done. The difference in time still persists, though.
mp3 playback
2020-10-20 22:07:49.763438 Elapsed time is 0:00:00.014268
2020-10-20 22:07:50.678853 Elapsed time is 0:00:00.014201
2020-10-20 22:07:51.593449 Elapsed time is 0:00:00.013398
2020-10-20 22:07:52.509022 Elapsed time is 0:00:00.014374
2020-10-20 22:07:53.423423 Elapsed time is 0:00:00.013982
flac playback
2020-10-20 22:07:12.490034 Elapsed time is 0:00:00.377940
2020-10-20 22:07:13.758048 Elapsed time is 0:00:00.366812
2020-10-20 22:07:15.041331 Elapsed time is 0:00:00.382096
2020-10-20 22:07:16.305848 Elapsed time is 0:00:00.363306
2020-10-20 22:07:17.573553 Elapsed time is 0:00:00.366486
2020-10-20 22:07:18.827768 Elapsed time is 0:00:00.353025
There's a >25x difference.
The update_display() loop is querying the active players, getting several MusicPlayer labels, and rendering a Pillow image for display on an LCD. A sleep statement tries to ensure that the polling occurs roughly once a second.
I'll get rid of everything put the JSON-RPC polling itself and see if the time difference persists.
