mherger wrote:
> That user has reported on the LMS repo too. Some confusing statements.
> But its my understanding that the issue is not Qobuz, but tracks in the
> database vs. online only tracks. His LMS is spending a lot of time in
> the status querys database code, looking up contributors, album info
> etc. which does not apply if a track is online only, not in the
> database.
>
> Material doesnt poll, does it? Because what I understood is that hes
> seeing spikes in intervals. Can a low power Intel CPU be less powerful
> than a Pi3B+? Because I cant reproduce this on my LMS.
>
> Unfortunately the reporter isnt clear about his environment. I wouldnt
> be surprised if he had some other (polling) clients running somewhere in
> his environment.
Material does poll during playback as follows:
- Every second when "waitingToPlay:1"
- Every 1/2 second for the -last- 2.5 seconds of a track
- Every 5 seconds otherwise
This is due to the fact that the cometd events are not instantaneous,
and can be a few seconds late.
The user sent me some logs, and in these "waitingToPlay:1" and "time:0"
seem to be always set - even 19 seconds after initial play. They sent me
2 logs; one with the issue, one without. Both had the same Material
message count and behaviour - hence why I fail to see this as a Material
issue.
*Material debug:* 1. Launch via http: //SERVER:9000/material/?debug=json
(Use http: //SERVER:9000/material/?debug=json,cometd to also see update
messages, e.g. play queue) 2. Open browser's developer tools 3. Open
console tab in developer tools 4. REQ/RESP messages sent to/from LMS
will be logged here.
------------------------------------------------------------------------
cpd73's Profile: http://forums.slimdevices.com/member.php?userid=66686
View this thread: http://forums.slimdevices.com/showthread.php?t=109624
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
